> For the complete documentation index, see [llms.txt](https://weekly-essay.mikey.wang/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://weekly-essay.mikey.wang/es/2025/w46-database-migration-case-study.md).

# W46-Caso de estudio sobre una migración de bases de datos

Leí un balance de una migración de bases de datos, [Cómo migramos 1000 millones de registros de DB1 a DB2 sin interrupciones](https://medium.com/@himanshusingour7/how-we-migrated-db-1-to-db-2-1-billion-records-without-downtime-c034ce85d889). Revisa una migración sin tiempo de inactividad de un clúster de bases de datos financieros con 1000 millones de registros.

Coincide en muchos aspectos con nuestras ideas centrales sobre prevención y control del riesgo técnico. Control gradual del riesgo, con cada paso verificable y reversible de forma independiente. Prioridad a la observabilidad: desde los registros WAL internos de la base de datos y la tasa de aciertos de caché hasta el volumen de pedidos y el flujo de ingresos en la capa de negocio. La monitorización de todo el proceso permite al equipo detectar anomalías a tiempo. También descubrí una técnica muy ingeniosa para migrar bases de datos o servicios de backend: las lecturas en sombra, o Shadow Reads.

La migración de datos es, en esencia, un problema complejo de diseño de sistemas. El autor presenta cinco decisiones de diseño importantes.

Primero, migrar en bloque los datos fríos mediante particionamiento, procesamiento en paralelo y desactivación de índices.

Segundo, introducir escritura doble junto con una cola de reintentos en Kafka para sincronizar el tráfico en tiempo real entre la base antigua y la nueva, manteniendo la idempotencia.

Tercero, realizar la validación en producción con Shadow Reads. Las peticiones de los usuarios siguen leyendo de la base antigua, pero cada consulta se ejecuta también, sin hacerse visible, contra la nueva base en segundo plano para comparar los resultados. El proceso duró varias semanas y permitió descubrir muchos problemas que jamás habrían detectado en un entorno de pruebas. Por ejemplo, diferencias en el tratamiento de zonas horarias, en el comportamiento predeterminado de los valores NULL o en las reglas de ordenación de caracteres. Después recordé que la migración de la arquitectura del backend de pagos del año pasado parecía haber usado algo parecido, aunque es difícil reproducirlo en el frontend.

Cuarto, hacer un cambio cuidadoso en una franja de poco tráfico, con precalentamiento de cachés, un plan de reversión y vigilancia estrecha para asegurar una transición fluida.

Por último, el autor destaca la importancia de una observabilidad sólida durante toda la migración.

Resulta difícil aplicar Shadow Reads al frontend porque cada usuario accede exclusivamente a una versión: si entra en la nueva, no puede acceder a la antigua. En una base de datos, Shadow Reads permite comparar conjuntos de resultados de forma invisible. La corrección del frontend es mucho más compleja que la consistencia de los datos. Abarca el comportamiento de las interacciones, la experiencia de rendimiento, la consistencia de la accesibilidad y la compatibilidad entre dispositivos. Para todo ello faltan medios de verificación de bajo costo. Los despliegues graduales por tráfico, el análisis del comportamiento de los usuarios, la monitorización de indicadores de negocio y las revisiones manuales siguen siendo las herramientas más eficaces.