Cómo extraer un servicio de un monolito con seguridad

El primer servicio que extraigas debe demostrar que el monolito puede ceder una responsabilidad sin perder el control. Elígelo por la propiedad de los datos y el riesgo de despliegue, no por lo fácil que resulte dibujar un recuadro bonito alrededor de un módulo. Un paquete ordenado que comparte tablas, recibe llamadas síncronas y participa en una gran transacción sigue siendo parte del monolito en todo lo que importa.

He visto equipos extraer el código que parecía más aislado, celebrar un repositorio limpio y descubrir después que cada versión exigía un cambio coordinado de base de datos y una llamada nocturna con tres responsables. El servicio existía como proceso, pero no como unidad operativa. El primer fallo real en producción lo devolvió directamente al monolito.

Una buena primera extracción tiene una superficie de escritura pequeña, datos que pueden ganar un propietario claro, consumidores que toleran una frontera de red y una ruta de despliegue reversible sin reparar datos a mano. Puede parecer aburrida en el diagrama de arquitectura. Lo aburrido resulta útil mientras el equipo aprende cómo se comporta su sistema de verdad.

Empieza por la propiedad de los datos, no por un sustantivo de negocio

El mejor primer servicio posee un conjunto coherente de hechos y puede rechazar escrituras sin consultar a medio monolito. Ese criterio es más estricto que tener clases llamadas Billing, Customer o Inventory. Un sustantivo de negocio suele abarcar procesos, informes, permisos y tablas históricas que distintas rutas de código modifican por motivos diferentes.

Pregunta qué componente puede convertirse en la única autoridad sobre un grupo pequeño de registros. Ser propietario significa validar cambios, confirmarlos, asignar identificadores y publicar el resultado. Otro código puede guardar esos hechos en caché o copiarlos, pero ya no modifica las filas autoritativas. Si el monolito y el nuevo servicio siguen siendo escritores legítimos, has creado una carrera distribuida en vez de una frontera.

Rastrea las escrituras antes que las lecturas. Las lecturas suelen ser más fáciles de duplicar, almacenar en caché o servir mediante una vista de compatibilidad. Las escrituras muestran las reglas que mantienen válidos los datos. Busca en el código de aplicación, procedimientos almacenados, tareas programadas, disparadores de base de datos, scripts de importación, herramientas de soporte y comandos directos de operadores. Los sistemas antiguos suelen ocultar escrituras decisivas donde el repositorio principal no las muestra.

Un candidato útil podría poseer solicitudes de generación de documentos, preferencias de notificación, instantáneas de tipos de cambio o trabajos de exportación terminados. Estos ejemplos tienen una transición de estado acotada y suelen tolerar trabajo asíncrono. Un mal candidato suele llamarse cliente, pedido, cuenta o autorización cuando esos registros participan en todas las transacciones importantes. Esos dominios pueden ser servicios más adelante, pero elegirlos primero obliga a la migración a enseñar la lección más difícil al mayor coste.

No confundas un grupo de tablas con un dominio. Si una tabla tiene doce claves foráneas entrantes, dos disparadores que actualizan otros agregados y una tarea nocturna que la corrige, moverla no crea independencia. Solo desplaza el centro de una red de dependencias. La documentación de PostgreSQL describe las claves foráneas como dependencias entre filas que hacen referencia y filas referenciadas. Esa garantía es local a la transacción de base de datos. Cuando las tablas viven detrás de servicios separados, la aplicación debe sustituirla deliberadamente o aceptar una consistencia más débil.

Mide el acoplamiento con pruebas de ejecución

Los grafos de dependencias estáticos son un punto de partida, pero las pruebas de producción indican si un candidato soporta una frontera entre procesos. Instrumenta el monolito el tiempo suficiente para observar consumidores, formas de consulta, frecuencia de escritura, duración de transacciones, tamaño de cargas, sensibilidad a la latencia, reintentos y picos de tráfico. La unidad importante no es un archivo fuente. Es una solicitud o tarea que cruza el límite propuesto.

Crea un registro con una fila por cada servicio candidato. Anota las tablas que lee y escribe, todos los consumidores, si cada llamada ocurre dentro de una solicitud de usuario, si un fallo puede esperar y qué invariantes dependen ahora de una transacción única de base de datos. Añade el responsable del despliegue y la acción de reversión. Si una de esas casillas dice «por decidir», el candidato no está preparado.

La búsqueda en el repositorio no encontrará SQL dinámico, reflexión, consultas generadas ni código desplegado fuera del repositorio. Los registros de sentencias y las trazas de la base capturan esas rutas. Muestrea durante suficiente tiempo para incluir trabajos programados como liquidación, facturación, conciliación, archivo y cierre de mes. El endpoint tranquilo del martes puede ser el centro del sistema el último día laborable del mes.

Cuenta operaciones que cruzan la frontera, no llamadas a métodos. Un método de repositorio muy conversador puede ejecutar veinte consultas y aun así moverse limpiamente junto con sus datos. Un getter aparentemente inocuo puede participar en una transacción que bloquea filas de cuatro dominios. La documentación de PostgreSQL sobre bloqueo explícito indica que SELECT FOR UPDATE bloquea actualizaciones y solicitudes de bloqueo incompatibles hasta que termina la transacción. Cambiar esa espera local por una llamada remota altera tiempos, tipos de fallo e interbloqueos aunque los campos devueltos sean idénticos.

Trata el tráfico desconocido como un riesgo, no como cero. Cuando los registros no permiten identificar quién actualiza una tabla, añade observación antes de extraerla. Un proxy, un disparador de auditoría temporal o una etiqueta de traza en la capa de acceso a datos pueden revelar al escritor. Adivinar solo es más rápido hasta que el escritor desconocido sobrescribe el estado del servicio nuevo.

Las pruebas deben responder cuatro preguntas incómodas: ¿puede el servicio estar caído sin bloquear la transacción principal? ¿Puede un consumidor reintentar sin duplicar trabajo? ¿Puede un operador explicar qué copia de un registro es autoritativa? ¿Puede el equipo desactivar la ruta manteniendo ambos almacenes internamente coherentes? Un primer servicio no necesita una respuesta perfecta para las cuatro, pero cada respuesta débil requiere un control probado.

Un diagrama limpio puede ocultar un primer corte terrible

Descarta candidatos cuyo atractivo dependa principalmente del orden organizativo. Los equipos suelen elegir un módulo porque ya pertenece a un solo grupo, porque su espacio de nombres está limpio o porque un diagrama de proveedor lo etiqueta como contexto delimitado. Ninguno de esos hechos demuestra que el código pueda desplegarse solo.

La autenticación es una trampa habitual. Parece horizontal y autónoma, pero cada solicitud depende de su latencia y disponibilidad. Sus datos también pueden mezclar credenciales, sesiones, roles, pertenencia a tenants, historial de auditoría y flujos de recuperación. Extraerla puede ser correcto, pero es un mal ensayo cuando un error de enrutamiento deja fuera a toda la empresa.

Los datos de referencia compartidos plantean otra trampa. Un módulo de códigos de país o categorías de producto parece de solo lectura hasta que los administradores lo editan, las cachés se actualizan en momentos distintos y las reglas de negocio esperan que un cambio se aplique dentro de la misma transacción. El volumen es pequeño, pero su alcance enorme. Poco tráfico no implica poco riesgo de despliegue.

El código de informes parece más seguro porque rara vez escribe registros centrales. El coste oculto es la propiedad de las consultas. Un informe que une treinta tablas del monolito no se vuelve independiente porque un endpoint HTTP envuelva el mismo SQL. Se convierte en un servicio remoto de consultas atado a todos los esquemas que lee. Extraer una proyección para informes puede funcionar después de definir su fuente y aceptar retrasos. Extraer las uniones existentes solo añade un salto de red.

Desaconsejo la recomendación «extrae primero el módulo más fácil». Es popular porque una separación rápida del repositorio produce progreso visible y da al equipo una nueva canalización de despliegue. Es incorrecta cuando la facilidad solo se refiere a mover código. Elige la responsabilidad más fácil de operar de forma independiente, incluidos datos, fallos, despliegue, observación y reversión. Esa definición produce menos teatro y más aprendizaje.

El riesgo de despliegue importa más que el tamaño del servicio

Un servicio pequeño puede tener un radio de impacto enorme, mientras que un trabajador asíncrono mayor puede fallar en silencio y recuperar después su cola. Ordena la primera extracción según lo que suceda durante una mala versión. El volumen de código es una aproximación pobre. El porcentaje de solicitudes críticas que cruza la frontera dice mucho más.

Prefiere un candidato fuera de la ruta síncrona del inicio de sesión, pago, autorización o actualización principal de registros. El envío de notificaciones, la conversión de archivos, la generación de exportaciones y la indexación de documentos suelen ser mejores límites porque el monolito puede encolar trabajo y seguir. Eso no los vuelve prescindibles. Da tiempo al equipo para observar, reintentar y reparar sin convertir cada fallo del servicio en una caída total.

Comprueba también el acoplamiento de recursos. Un proceso nuevo puede sobrecargar la misma base con otro pool de conexiones, reintentar una consulta lenta con mayor agresividad o agotar una cola compartida. El aislamiento en un diagrama de despliegue no aísla CPU, bloqueos, conexiones ni cuotas de sistemas posteriores. Pon límites explícitos a concurrencia y reintentos antes de desviar tráfico de producción.

Valora cada candidato según consecuencias que los operadores puedan reconocer:

• Una caída de diez minutos tiene menos riesgo si el trabajo espera y se recupera; el fallo de solicitudes centrales es una alarma.
• Un componente debe escribir los datos autoritativos; varias aplicaciones y tareas son una alarma.
• Una clave de idempotencia estable hace más seguros los reintentos; repetir solicitudes a ciegas es una alarma.
• Un cambio de ruta o consumidor debe revertir una versión; fusionar datos y revertir el esquema es una alarma.
• Los resultados comparados y las métricas de negocio deben detectar fallos semánticos; la salud del proceso por sí sola es una alarma.

No conviertas la tabla en una fórmula numérica falsa. Una puntuación de 17 no anula una respuesta que diga «no podemos reconstruir las escrituras perdidas». Úsala para mostrar condiciones de veto y forzar una conversación explícita. En la primera extracción, una divergencia irreversible de datos es un veto. También lo es una dependencia que obliga a desplegar todos los consumidores en la misma ventana.

Define el contrato antes de mover la implementación

El contrato de extracción debe describir el comportamiento ante reintentos, entradas antiguas, duplicados, tiempos de espera y fallos parciales. Una lista de endpoints y campos no basta. Los consumidores deben saber qué identidad de solicitud se mantiene estable, qué transición de estado está permitida y qué respuesta indica que el servicio ha aceptado la responsabilidad de forma duradera.

Escribe el contrato según el comportamiento actual, incluido el que nadie aprecia. Si el monolito acepta envíos duplicados y devuelve el trabajo original, el servicio nuevo no puede empezar a devolver conflictos solo porque parezca más limpio. Moderniza después de hacer visible la paridad o detrás de un cambio con versión explícita. De otro modo, cada diferencia acaba en una discusión sobre si el resultado antiguo o el nuevo era el esperado.

Para un candidato de exportación, una solicitud mínima concreta el comportamiento de reintento:

{
  "request_id": "01JEXAMPLE8M4Q2",
  "account_id": "A1842",
  "report_type": "ledger",
  "cutoff": "2026-08-01T00:00:00Z"
}

El servicio guarda request_id bajo una restricción única antes de empezar el trabajo. Repetir la solicitud devuelve el trabajo existente y su estado actual. Un timeout después de la aceptación pasa a ser recuperable: el consumidor repite la misma identidad en vez de inventar otro trabajo. El contrato también necesita un estado de fallo terminal y una regla que indique si un operador puede reintentarlo con la misma identidad.

Especifica los errores según la acción del consumidor. «Fecha de corte no válida, no reintentar» es útil. «Dependencia no disponible, reintentar con espera limitada» es útil. Un error interno genérico empuja a todos los consumidores hacia la reacción más peligrosa, el reintento ciego e inmediato. Limita tamaños y plazos en el contrato; de lo contrario, la mayor entrada histórica descubrirá esos límites en producción.

Mantén la primera interfaz más pequeña que la API interna anterior. No expongas tablas mediante endpoints genéricos de creación, lectura, actualización y borrado. Ofrece operaciones que preserven invariantes, como request_export, cancel_pending_export y get_export_status. Una superficie de comandos reducida permite cambiar detalles internos sin volver a coordinar a todos los consumidores.

Un solo escritor evita datos con dos autoridades

La migración necesita un momento declarado en el que el servicio nuevo se convierta en el único escritor de sus registros. La escritura doble desde el código de aplicación no es un puente seguro. Una escritura puede tener éxito mientras la otra agota el tiempo, y el consumidor no puede saber si un reintento reparará o duplicará el estado.

Transfiere la propiedad por etapas. Primero, haz visibles los escritores ocultos y condúcelos por una interfaz única del monolito. Después, introduce identidades estables y registra el comportamiento antiguo. Deja que el nuevo servicio procese tráfico copiado sin publicar resultados. Cuando pasen las pruebas de paridad, dirige las escrituras autoritativas al servicio mientras el monolito lee mediante una ruta de compatibilidad. Retira el escritor antiguo tras cerrar la ventana de retorno. Es una secuencia de migración integrada, no cinco proyectos independientes.

Si el monolito debe reaccionar a un cambio confirmado por el servicio, publica un evento desde la misma transacción que registra el cambio. El mecanismo habitual es un buzón de salida transaccional: el servicio confirma a la vez el estado del dominio y una fila del buzón, y luego un relay publica esa fila. Los consumidores deben manejar duplicados porque el relay puede publicar y fallar antes de marcar la fila como completada.

Evita claves foráneas entre servicios. No pueden imponer integridad entre bases separadas, y mantener una base compartida conserva el acoplamiento del despliegue. Transporta el identificador de referencia, valídalo donde lo exija el flujo y decide cómo tratar borrados o copias antiguas. Algunas invariantes necesitan una comprobación síncrona ante la autoridad; otras toleran una proyección local. La decisión pertenece al contrato de dominio, no a una unión accidental.

La carga inicial de datos necesita una marca de agua y una consulta de conciliación. «Copiar la tabla y cambiar» deja una carrera entre la instantánea y las escrituras activas. Captura cambios después de una posición conocida, carga la instantánea, aplica los cambios en orden y compara recuentos junto con totales de dominio o hashes. Un recuento igual no detecta valores intercambiados, relaciones ausentes ni un valor por defecto cuyo significado haya cambiado.

El plan de corte debe nombrar a la autoridad antigua y a la nueva en cada fase. Si quien dirige el incidente tiene que deducir la propiedad mirando paneles mientras continúan las escrituras, el plan ya ha fallado antes del incidente.

El tráfico en sombra debe comparar significado

Un despliegue en sombra demuestra más cuando compara resultados de dominio en lugar de limitarse a códigos de estado. Envía una copia de solicitudes de producción válidas al servicio nuevo, aísla sus efectos y registra salidas normalizadas de ambas implementaciones. Después clasifica las diferencias por campo y regla de negocio.

Normaliza los valores no deterministas antes de comparar. Marcas de tiempo, identificadores generados, colecciones sin orden y formato pueden diferir sin cambiar el comportamiento. No normalices campos con significado, como redondeos monetarios, decisiones de permisos, orden prometido al consumidor o momento de una transición. Cada regla de normalización debe tener responsable y motivo.

El tráfico grabado de producción encuentra combinaciones que no aparecen en los datos de prueba, pero también lleva datos sensibles y accidentes históricos. Define conservación, acceso, enmascarado y controles de reproducción antes de recogerlo. En entornos regulados, mantener el arnés dentro del perímetro del cliente puede importar más que la comodidad de un sistema de pruebas alojado. Admitir ese entorno no concede una certificación de cumplimiento; son afirmaciones diferentes.

Compara los efectos mediante un receptor, no permitiendo que el servicio en sombra envíe correos reales, cobre una cuenta o publique eventos autoritativos. Sustituye esos adaptadores por registradores de intención. La comparación útil es «la implementación nueva habría emitido este evento con estos campos», no «el manejador devolvió 202».

Fija las puertas de promoción sobre comportamiento observado. Cubre volumen normal, cargas máximas, reintentos, entradas no válidas, tiempos de espera de dependencias y tareas programadas encontradas durante el análisis. Exige cero diferencias sin explicar en invariantes que afectan al dinero, permisos o estado duradero. Para diferencias cosméticas, documenta las aceptadas en vez de fingir que el objetivo es la igualdad byte a byte.

CodeHero usa un arnés de paridad contra tráfico de producción grabado cuando reescribe un sistema antiguo, y yo exigiría esa parte aunque otro equipo construyera el sustituto. La salud del proceso indica que el código nuevo funciona. Las pruebas de paridad indican si sigue haciendo su trabajo.

La reversión debe cambiar el enrutamiento, no reparar el historial

Una reversión segura evita que llegue tráfico nuevo al servicio extraído sin pedir a los operadores que fusionen dos historiales incompatibles. Esa propiedad debe diseñarse antes del corte. Si revertir exige transformar datos hacia atrás, restaurar una tabla compartida o volver a desplegar todos los consumidores, será demasiado lento cuando el fallo sea ambiguo.

Mantén disponible la ruta antigua de lectura durante la ventana de observación, pero no dos escritores sin restricciones. Cuando el servicio nuevo posee las escrituras, devuelve sus cambios confirmados al almacén de compatibilidad del monolito o haz que el monolito lea a través del servicio. La primera opción permite recuperar lecturas con rapidez si el retraso de réplica es visible. La segunda conserva una única verdad, pero convierte la disponibilidad del servicio en parte de la ruta antigua. Elige según la interrupción que puedas tolerar.

Usa un control de ruta que cambie sin desplegar la aplicación. Puede estar en una puerta de enlace, en una asignación de consumidores o detrás de una configuración del servidor. Protégelo con control de acceso y registro de auditoría. Prueba la reversión exacta bajo carga antes del corte, incluidas solicitudes en curso y mensajes en cola.

Define disparadores de reversión en términos observables. Una tasa de errores creciente no detecta corrupción semántica. Incluye diferencias de paridad, edad de cola, tasa de duplicados, transiciones rechazadas y totales de dominio. Asigna quién puede ordenar la reversión y quién diagnostica después de mover el tráfico. Una reunión de emergencia no es un plano de control.

Los cambios de esquema deben seguir siendo compatibles durante la ventana de reversión. Añade campos antes de exigirlos, tolera representaciones antiguas y nuevas mientras ambas versiones funcionen y elimina los campos anteriores después. Los scripts de reversión de base de datos tranquilizan sobre el papel, pero revertir una migración destructiva después de recibir escrituras suele ser imposible. Los cambios compatibles hacia delante mantienen real la opción de enrutamiento.

No llames fracaso a toda retirada. Si el cambio de ruta funciona, las pruebas permanecen intactas y el equipo encuentra una diferencia semántica antes de que los clientes dependan de ella, el mecanismo de extracción ha cumplido. El fracaso consiste en descubrir que la única vuelta atrás exige editar datos de forma improvisada.

La promoción necesita responsables, umbrales y un reloj

Un corte está preparado cuando personas concretas pueden decidir, con pruebas actuales, si continuar, pausar o revertir. Una invitación de calendario y un panel no dan esa capacidad. El equipo necesita un registro operativo que conecte cada señal con una acción y cada acción con un rol responsable.

Escribe una hoja de promoción antes de iniciar el tráfico en sombra. Nombra la versión candidata, el control de ruta, la marca de agua, el modo de compatibilidad, la profundidad esperada de cola, el cambio de latencia permitido, las reglas de paridad y la persona autorizada a mover tráfico. Registra los comandos o acciones exactos para cada incremento y reversión. Si el procedimiento depende de que un ingeniero recuerde un indicador sin documentar, ensáyalo hasta eliminar esa dependencia.

Mueve el tráfico por incrementos que revelen efectos de carga sin crear otra autoridad de datos en cada fase. Para lecturas sin estado puede bastar el reparto porcentual. Para trabajo con estado, enruta por una partición estable como identificador de cuenta, tipo de tarea o tenant, para que una unidad no salte entre implementaciones. Conserva la asignación. El porcentaje aleatorio para escrituras relacionadas puede dividir un flujo entre dos propietarios y hacer que el fallo parezca intermitente.

El tiempo importa de dos formas. El servicio nuevo necesita exposición suficiente para encontrar trabajo representativo, y cada fase necesita una duración máxima antes de elegir expresamente el siguiente paso. Un despliegue parcial sin final puede convertirse en arquitectura permanente, con dos paneles, dos manuales y sin propietario claro. Decide el tiempo según los patrones de tráfico, no la paciencia directiva. Un servicio con un lote diario importante debe verlo antes de avanzar; una ruta de fin de trimestre requiere reproducción grabada si esperar al evento real no resulta razonable.

Separa umbrales de infraestructura y semánticos. Saturación de CPU, agotamiento de conexiones, crecimiento de cola y tiempos de espera dicen si el servicio soporta la carga. Totales de estado, recuentos de transiciones, redondeos, decisiones de permiso y efectos previstos dicen si conserva el comportamiento correcto. Una versión rápida y equivocada debe detenerse antes que una temporalmente lenta y correcta.

Usa un registro de decisión breve durante el despliegue:

1. El responsable de la versión registra la partición de tráfico y la marca de agua antes de cambiar la ruta.
2. El observador confirma señales de infraestructura y resultados de paridad para esa partición.
3. El responsable del dominio clasifica cada diferencia semántica nueva como explicada, bloqueante o aceptada con una razón escrita.
4. El responsable de incidentes confirma que la reversión sigue siendo posible con el esquema actual y el trabajo en cola.
5. El responsable de la versión promueve, mantiene o revierte y registra las pruebas utilizadas.

No es ceremonia vacía. Evita un patrón conocido: la infraestructura parece sana, el despliegue avanza y una diferencia de negocio sin explicar queda para el siguiente turno porque nadie puede detener la promoción. El registro muestra la incertidumbre mientras revertir todavía resulta barato.

Mantén un reloj para la recuperación técnica y otro para la de datos. Volver a enrutar puede llevar segundos, mientras que reproducir eventos perdidos o reconstruir una proyección tarda más. Declara ambos objetivos. Dar la reversión por terminada cuando las solicitudes vuelven al monolito oculta reparaciones pendientes y anima a borrar pruebas demasiado pronto.

La promoción solo termina después de limpiar la propiedad. Elimina rutas temporales de doble lectura, revoca permisos de base obsoletos, archiva los resultados de comparación según la política acordada y actualiza el catálogo de servicios y las guardias. Dejar permisos de migración convierte un puente controlado en una interfaz permanente no oficial. La siguiente extracción debe empezar con menos rutas ocultas.

La primera extracción pone a prueba el sistema de migración

El primer servicio tiene éxito cuando la organización puede repetir el método con mejores pruebas y menos coordinación. Su valor de negocio importa, pero su segundo resultado es un sistema de migración probado: descubrimiento de dependencias, captura del contrato, reproducción de tráfico, transferencia de datos, puertas de promoción y enrutamiento reversible.

Registra dónde discrepó el plan de la producción. Tal vez un procedimiento almacenado poseía una escritura que no apareció en la búsqueda. Quizá los reintentos no reutilizaban ningún identificador. Puede que la mayor carga viniera de una tarea trimestral. Convierte cada sorpresa en consulta automatizada, traza o puerta para el siguiente candidato. Una retrospectiva sin un control modificado solo conserva la historia.

Mantén el servicio nuevo operativamente independiente después del lanzamiento. Dale su propio artefacto desplegable, señales técnicas y de dominio, límites de recursos, responsable de guardia y manual para trabajo atascado. No exijas una versión del monolito para cambiar su implementación. No dejes que su base se convierta en un esquema cómodo para nuevos informes. Cada lector directo crea otro problema futuro de extracción.

La modernización de la arquitectura debe seguir el comportamiento observado en vez de trasladar literalmente módulos antiguos a procesos nuevos. Analizar todo el código ayuda porque el comportamiento heredado suele cruzar lenguajes, procedimientos almacenados, archivos de lotes y clientes. CodeHero lee esas fuentes juntas y entrega reescrituras en menos de 30 días, pero la velocidad no elimina la necesidad de nombrar un propietario de datos y probar la reversión.

Elige el candidato cuyo fallo pueda contenerse, cuyas escrituras admitan un solo propietario y cuyos consumidores soporten una frontera de red sin unirse a una transacción distribuida. Demuéstralo con tráfico grabado y devuelve la ruta una vez antes del corte real. Un equipo que nunca ha ejecutado la reversión tiene un documento de reversión, no una capacidad de reversión.