El sistema llevaba cinco días en producción cuando llegué
No hubo inducción. No hubo documentación. Hubo reuniones de crisis a puerta cerrada y un silencio incómodo cada vez que preguntaba qué estaba pasando.
Mi rol formal era líder de automatización de QA. Pero conforme me fui involucrando en el contexto, quedó claro que el problema no era de calidad de pruebas. Era de arquitectura.
El motor principal de base de datos era DynamoDB, una base de datos NoSQL de AWS diseñada para patrones de acceso por clave, alta escala y lecturas/escrituras predecibles. Nada de eso se había aprovechado. Había sido usada como si fuera una base de datos relacional: con relaciones entre entidades, consultas complejas, joins implícitos en código de aplicación y una cantidad notable de lógica que dependía de estructuras que DynamoDB simplemente no garantiza.
El sistema era técnicamente funcional. Pero estaba construido sobre una base que haría que cada nueva funcionalidad costara el doble de esfuerzo del necesario.
Por qué es difícil cuando el sistema ya está en producción
Aquí está el problema real: no era un prototipo. Había usuarios reales. Había operaciones financieras activas. No había opción de "apagar y rehacer".
Esto es lo que hace diferente rediseñar un backend en producción versus construir uno nuevo:
No puedes romper lo que ya funciona. Aunque lo que funciona sea frágil, es lo que está sosteniendo la operación. Cada cambio tiene un costo real, no solo técnico.
El conocimiento está disperso. El equipo original tomó decisiones bajo presión. Parte de la lógica de negocio estaba en la cabeza de personas que ya no estaban disponibles, o directamente en el comportamiento del sistema que nadie había documentado.
El tiempo no se detiene. Mientras el equipo de refactorización trabaja en el backend nuevo, los usuarios del sistema actual siguen operando. Cualquier inconsistencia entre ambos mundos se convierte en un problema de datos.
La decisión que se tomó desde dirección fue sensata en ese contexto: dividir en dos equipos. Uno mantendría el sistema actual operando. El otro construiría el backend nuevo desde cero. La empresa además hizo un freeze de nuevas altas para reducir la presión de crecimiento mientras se estabilizaba.
Me asignaron al equipo de soporte.
Lo que aprendí estando del lado que nadie quiere estar
Mantener un sistema que sabes que va a ser reemplazado es una experiencia particular. No es glamoroso. No es lo que uno imagina cuando piensa en "trabajo técnico interesante".
Pero fue donde aprendí las reglas de negocio reales.
Cada bug que se destraba en soporte es una historia: por qué ese flujo existe, qué caso borde representa, qué decisión de negocio hay detrás. Con el tiempo, esa acumulación de contexto se vuelve un activo valioso, aunque en el momento no se sienta así.
Cuando finalmente pude moverme al equipo de refactorización, mi jefe fue directo:
"Te tocará tomar el toro por los cuernos."
Y sí. Así fue.
La migración de DynamoDB a PostgreSQL
Lo más común en la industria es lo contrario: empresas que migran de bases de datos relacionales a soluciones NoSQL para escalar. Hacerlo al revés tiene sus propios retos.
El modelo mental es diferente. DynamoDB te obliga a pensar en patrones de acceso primero. PostgreSQL te da flexibilidad para consultar desde múltiples ángulos. Migrar el modelo de datos implicó entender qué estructura tenía el dato en Dynamo, cómo se estaba usando en realidad, y qué forma debería tener en un esquema relacional bien diseñado.
Los datos no se migran solos. Hubo que escribir scripts de transformación, validar integridad, manejar datos inconsistentes que el sistema anterior había aceptado sin queja. Los bordes del modelo de DynamoDB habían permitido guardar cosas que PostgreSQL rechazaría con una restricción de llave foránea o una constraint de unicidad.
El release fue nocturno. Obviamente. Los releases importantes siempre son nocturnos. Hubo problemas. Siempre hay problemas. Migramos datos, apagamos servidores, movimos el switch, prendimos el nuevo sistema, y empezamos a leer logs con la misma intensidad con la que se lee un mensaje importante que tardó en llegar.
Funcionó. No de forma perfecta en las primeras horas, pero funcionó.
Lecciones que me quedaron
1. El contexto de negocio no está en el código. Está en los tickets de soporte, en las conversaciones de emergencia, en los edge cases que nadie documentó. Si tienes la oportunidad de estar cerca de la operación antes de rediseñar algo, no la desperdicies.
2. DynamoDB no es una base de datos relacional. Parece obvio. No siempre lo es cuando hay presión de tiempo y el equipo no tiene experiencia previa con la tecnología. Antes de elegir una base de datos, la pregunta correcta no es "¿qué bases de datos conocemos?" sino "¿qué patrones de acceso tenemos?".
3. Dividir el equipo fue la decisión correcta. Intentar mantener la operación y construir el nuevo sistema con el mismo equipo y al mismo tiempo es una receta para hacer las dos cosas mal. La separación de responsabilidades aplica también a nivel organizacional.
4. La estabilidad no siempre se ve bien desde adentro. Hubo un momento donde el sistema estaba "estable". No era bonito. No era lo que queríamos. Pero estaba sosteniendo la operación. A veces eso es suficiente para avanzar al siguiente paso.
5. Los releases nocturnos tienen sus propios patrones de falla. Cansancio, presión, menor visibilidad del impacto real. Tener runbooks claros, criterios de rollback definidos de antemano y una comunicación fluida en el equipo vale más que cualquier optimismo previo al deploy.
Conclusión
Rediseñar un backend en producción no es solo un ejercicio técnico. Es una operación que requiere contexto de negocio, coordinación de equipos, gestión de datos sucios y tolerancia a la ambigüedad.
La tecnología en sí, migrar de DynamoDB a PostgreSQL en este caso, fue la parte más predecible del proceso. Lo que realmente definió el resultado fue haber entendido el sistema antes de cambiarlo.
La arquitectura no empieza en el diseño. Empieza en entender qué problema está resolviendo el sistema actual, aunque ese sistema esté mal construido.
Top comments (0)