Necesitas sacar una capacidad de un monolito grande a su propio servicio. ¿Cómo lo harías sin una release de golpe?

Usa el patrón strangler: pon una fachada delante de la capacidad, construye el servicio nuevo detrás y mueve el tráfico de forma incremental con un feature flag mientras el monolito sigue siendo el respaldo. Divide los datos al final, normalmente con escritura doble y relleno histórico hasta que el nuevo almacén sea la fuente de verdad, y mantén una fase de verificación donde ambos caminos corren y se comparan los resultados antes de borrar el código antiguo.

Lo primero sería crear una costura. Incluso dentro del monolito, todos los que llaman a esa capacidad pasan por una única interfaz, lo que muchas veces es un refactor que merece la pena por sí solo porque deja ver lo enredada que está de verdad la frontera. Después el servicio nuevo implementa el mismo contrato, y la fachada enruta un pequeño porcentaje de tráfico hacia él detrás de un flag, empezando por llamadas de solo lectura donde una respuesta equivocada sale barata. Lo dejo un tiempo en modo sombra, mandando la misma petición a los dos y comparando respuestas, porque eso pilla los casos límite que nadie documentó. Los datos son la parte difícil: escribo en los dos sitios, relleno el histórico, reconcilio y solo entonces hago que el nuevo almacén sea la fuente de verdad, con el monolito leyendo del servicio en vez de de las tablas compartidas. Cada paso tiene una vuelta atrás que es cambiar un flag. Y la migración no está terminada hasta que el código antiguo y sus tablas están borrados; he visto migraciones strangler atascarse al noventa por ciento y dejar dos sistemas que mantener durante años, que es peor que cualquiera de las dos opciones por separado.