Monolito modular o microservicios según la evidencia

Un producto SaaS con IA que espera crecer rápido casi siempre debería empezar como monolito modular, con una excepción deliberada: conviene aislar las cargas que demuestren que necesitan otro modelo de escalado, seguridad o fallos. Esperar crecimiento no demuestra que cada función de negocio necesite su propio proceso. Sí demuestra que el código necesita límites que puedan medirse y trasladarse más adelante.

He visto equipos dividir un dominio sin terminar en servicios porque una previsión mostraba una subida pronunciada. Seis meses después, cada función cruzaba cuatro API, las versiones seguían saliendo juntas y un solo ingeniero entendía la coreografía de mensajes. También he visto un único desplegable convertirse en freno porque un trabajador de inferencia consumía toda la capacidad y su ritmo de publicación no tenía relación con la facturación. La etiqueta de arquitectura no decidió ninguno de los resultados. Los decidieron la propiedad, el comportamiento en ejecución y la preparación operativa.

Una decisión útil compara el coste de coordinar dentro de un proceso con el de coordinar a través de una red. El primero aparece en revisiones de código, versiones compartidas y contención de la base de datos. El segundo aparece en contratos, colas, reintentos, trazas, respuesta a incidentes e infraestructura duplicada. Elige servicios solo cuando un límite identificado compense esa segunda factura.

El crecimiento rápido no es una sola carga

Un aumento rápido de clientes no indica qué parte del sistema sufrirá primero. Un SaaS puede sumar empresas deprisa mientras su API sigue siendo normal y los trabajos de IA en segundo plano consumen casi todo el cómputo. Puede tener un tráfico modesto y, a la vez, altas exigencias de aislamiento de datos durante la incorporación de grandes clientes. Puede captar usuarios rápido, pero cambiar el flujo de precios diez veces más que el resto. Son presiones distintas y cada una apunta a un límite diferente.

Empieza con un modelo de carga, aunque las cifras sean estimaciones. Separa solicitudes interactivas, tareas programadas, llamadas de inferencia, ingestión, indexación de búsqueda, notificaciones e informes. Para cada carga, anota su unidad de demanda, latencia aceptable, límite de concurrencia, forma de reintento, datos que toca y efecto de un fallo. Una solicitud medida en páginas vistas se comporta de manera distinta a un trabajo de documentos medido en tokens y minutos. Escalar ambos detrás del mismo proceso puede desperdiciar capacidad, pero eso tampoco obliga a dividir todo el dominio.

Los equipos suelen confundir modularidad lógica y distribución física. Un módulo posee un vocabulario de negocio y una API interna. Un servicio añade una red y un entorno de ejecución independiente a ese límite. Hace falta lo primero antes de lo segundo. Sin ello, los microservicios reproducen el mismo acoplamiento mediante llamadas más lentas y despliegues más difíciles.

La guía de Microsoft sobre arquitecturas habituales de aplicaciones web aporta una precisión sensata que se pierde en estos debates: si toda la aplicación puede escalar clonando una instancia, separar servicios quizá aporte poco. La misma guía señala que durante una fase temprana pueden no estar claros los límites funcionales naturales. Estoy de acuerdo, pero añadiría una prueba. La incertidumbre debería cambiar hoy la estructura del código, no obligar hoy a adoptar una topología distribuida. Coloca las funciones dudosas detrás de interfaces de módulo, deja explícito su acceso a datos y reúne la evidencia que podría justificar su extracción.

Un monolito modular no es una carpeta llamada modules que envuelve una masa de código compartido. Necesita reglas de importación que se hagan cumplir, propiedad sobre tablas o esquemas y ninguna puerta trasera hacia las partes internas de otro módulo. Si cualquier controlador puede consultar cualquier tabla, el despliegue es monolítico y el diseño carece de estructura. Dividirlo cuesta mucho porque las dependencias siguen ocultas hasta la migración.

La propiedad del equipo fija el límite práctico

La estructura del equipo suele fijar el primer límite útil para el número de servicios. Un grupo de producto pequeño no puede dar diez propietarios independientes a diez servicios. Entrega al mismo grupo diez repositorios, diez procesos de despliegue y diez fuentes de alertas. Las mismas personas siguen coordinando cada cambio, así que la supuesta autonomía solo existe en los diagramas.

Para un solo equipo de producto, un monolito modular mantiene corto el ciclo de respuesta. Un desarrollador puede cambiar una regla de dominio, su transacción y el comportamiento visible para el usuario en una rama y una ejecución de pruebas. La propiedad del código puede seguir siendo estricta. El módulo de facturación puede rechazar importaciones desde espacios de trabajo u orquestación de IA, y sus revisores pueden aprobar cambios en la interfaz pública. La independencia empieza por derechos de decisión y límites, no por repositorios.

Varios equipos estables cambian la ecuación. Un servicio resulta razonable cuando un equipo posee una función de negocio, puede operarla y rara vez necesita cambios sincronizados en el código de otro equipo. El servicio debe tener un responsable claro de guardia, su propia decisión de publicación y un contrato que consuman otros equipos. La propiedad compartida no es propiedad. Si cada incidente abre un chat con representantes de cinco equipos, el límite no ha reducido la coordinación.

Plantea tres preguntas durante la planificación. ¿Quién aprueba un cambio de contrato? ¿Quién recibe la alerta de madrugada? ¿Quién puede desplegar una corrección sin esperar a otro grupo? Si las respuestas nombran comités distintos o a nadie, mantén el límite dentro del proceso hasta que la organización pueda sostenerlo. Esto no prohíbe una extracción temprana. Un equipo de dos personas puede aislar un trabajador de inferencia porque su ejecución es radicalmente distinta, pero debe reconocer que aún opera un solo sistema de producto.

El desarrollo distribuido añade otro matiz. Los husos horarios pueden hacer útil la propiedad por módulos porque reducen los cambios conflictivos, pero los límites de red no resuelven por sí solos la comunicación. SaaS Production coordina ingenieros en Kazakhstan y Eastern Europe, además de California, por lo que tratamos los contratos escritos, la propiedad clara y las reglas de revisión como trabajo de ingeniería. Esa disciplina mejora enseguida un monolito modular y vuelve mucho menos brusca una extracción posterior.

Me opongo a la recomendación popular de crear un servicio por equipo pequeño. Suena ordenada porque el diagrama de arquitectura copia el organigrama. Falla cuando cambian los equipos, cuando una función necesita varias especialidades o cuando un servicio débil solo existe para justificar una caja. Deja que los límites estables de negocio influyan en la propiedad y que esa propiedad sostenga una operación independiente. No conviertas un plan temporal de personal en una red permanente.

El despliegue independiente debe compensar su coste

El despliegue independiente importa solo cuando los equipos publican de forma independiente. Si un cambio en el servicio A exige desplegar antes el servicio B, coordinar una migración de base de datos y compartir una ventana de aceptación, tienes un monolito distribuido. Conserva los fallos propios de una red sin obtener autonomía de publicación.

Mide la necesidad antes de extraer nada. Revisa los últimos veinte cambios en producción del módulo candidato. Cuenta cuántos afectaron solo a ese módulo, cuántos exigieron cambios coordinados en otro lugar, con qué frecuencia los retrasó la publicación de toda la aplicación y cuántas veces una reversión limitada al módulo habría reducido el daño. Un límite merece convertirse en servicio cuando los cambios independientes ocurren lo bastante a menudo como para que el despliegue compartido sea un freno repetido, no una molestia futura imaginaria.

La compatibilidad es la parte difícil. Un servicio desplegado por separado debe admitir consumidores con versiones anteriores y posteriores del contrato durante la publicación. Añade campos en vez de cambiar su significado. Acepta ambas formas mientras migran los consumidores. Mantén los cambios de base de datos compatibles con la versión anterior de la aplicación hasta que ya no haga falta revertir. Un proceso de despliegue por servicio no crea independencia si los contratos obligan a avanzar juntos.

La documentación de Kubernetes muestra cómo un Deployment puede hacer una actualización gradual, pero sustituir contenedores solo resuelve la ejecución. No vuelve segura una API incompatible. No coordina un productor de eventos con consumidores antiguos ni revierte un cambio destructivo de esquema. A veces un equipo compra un orquestador y confunde su controlador de despliegue con una arquitectura.

Un monolito también puede mejorar la independencia de las publicaciones sin distribuirse. Los indicadores de funciones separan la publicación de su exposición. Las pruebas específicas de módulo acortan la respuesta. Una interfaz interna clara limita el efecto de un cambio. Puedes empaquetar una imagen de aplicación, ejecutar varias instancias y usar un punto de entrada de trabajador desde el mismo repositorio. Son cambios baratos y reversibles.

Extrae cuando el historial muestre un conflicto repetido: una función cambia a menudo, conlleva un riesgo de reversión propio o debe ejecutar una versión que el resto no puede aceptar. Mantenla interna cuando las publicaciones sigan coordinadas por razones de negocio. Un solo proceso de despliegue suele ser una ventaja mientras el equipo todavía descubre cómo funciona el producto.

El aislamiento de clientes empieza en los datos

El aislamiento entre clientes es, ante todo, una propiedad del acceso a datos y la autorización, no del número de servicios. Cien servicios pueden filtrar datos si cada uno confía en un identificador de cliente sin validar. Un proceso puede ofrecer buen aislamiento lógico si todas las rutas aplican el contexto del cliente y prueban la denegación entre empresas.

Decide qué nivel de aislamiento exigen el producto y los contratos. Las tablas compartidas con una columna de cliente ofrecen buena densidad, pero requieren un filtrado constante. Los esquemas separados reducen uniones accidentales y simplifican algunas exportaciones, aunque aumentan el trabajo de migración. Las bases de datos separadas crean un límite operativo más fuerte y permiten restaurar o trasladar a un cliente, pero elevan el coste de conexiones, actualizaciones y gestión del conjunto. Los despliegues dedicados van más lejos cuando un cliente necesita cómputo o fechas de publicación aisladas. Ninguna opción exige convertir cada función de negocio en microservicio.

La documentación de seguridad por filas de PostgreSQL dice que las políticas pueden limitar las filas que las consultas normales devuelven o modifican. Cuando se activa esta seguridad y no hay una política aplicable, PostgreSQL deniega por defecto. Es una defensa útil, pero tiene una salvedad importante: los propietarios de tablas suelen eludirla. Una aplicación conectada como propietaria puede creer que una política la protege mientras todas sus consultas siguen viendo todas las filas.

Este fragmento muestra la forma de una configuración aplicable sobre tablas compartidas. La aplicación fija el contexto del cliente en el límite de la transacción, y la política comprueba lecturas y escrituras:

ALTER TABLE documents ENABLE ROW LEVEL SECURITY;
ALTER TABLE documents FORCE ROW LEVEL SECURITY;

CREATE POLICY tenant_documents ON documents
  USING (tenant_id = current_setting('app.tenant_id')::uuid)
  WITH CHECK (tenant_id = current_setting('app.tenant_id')::uuid);

BEGIN;
SET LOCAL app.tenant_id = '8bd3659e-64f6-4f0d-92c7-49e79ad86a2b';
SELECT id, status FROM documents;
COMMIT;

Ejecuta una prueba negativa de integración con dos clientes. Inserta un documento para cada uno, fija el contexto del primero y comprueba que seleccionar el documento del segundo devuelve cero filas. Después intenta actualizar el identificador de cliente del primer documento y confirma que la base de datos lo rechaza. Ejecuta la prueba con el mismo rol que se usa en producción. Una política probada como administrador demuestra muy poco.

Extraer un servicio se justifica cuando un límite de aislamiento necesita credenciales, almacenes, administración de cifrado, residencia, procedimientos de restauración o acceso de operadores separados. Por ejemplo, un subsistema sanitario puede necesitar su propio límite operativo porque sus controles de acceso y cambio difieren de un flujo público de marketing. Separar servicio de clientes, usuarios y preferencias no aísla por sí solo. Solo da a un fallo de contexto más lugares donde ocultarse.

La ejecución de IA suele merecer la primera división

La ejecución de IA suele ser el primer límite útil porque sus recursos y fallos difieren del núcleo transaccional del SaaS. Las llamadas a modelos pueden durar mucho más que las consultas normales, los proveedores imponen límites de concurrencia y frecuencia, el tamaño de las entradas varía mucho y un cliente puede abandonar un trabajo mientras el cómputo continúa. Mantener ese trabajo dentro de una solicitud web liga la latencia del usuario a una dependencia externa y complica la planificación de capacidad.

La primera división no tiene que crear una flota de microservicios de negocio. Una aplicación web puede validar el acceso, crear un registro de trabajo y confirmar un evento de bandeja de salida en una transacción. Un proceso trabajador puede reclamar el trabajo, llamar al proveedor del modelo, guardar el avance y publicar su finalización. Al principio, el trabajador puede usar el mismo repositorio y artefacto. La cola crea un límite de ejecución, mientras los módulos conservan la propiedad del dominio.

Diseña el protocolo del trabajo antes de elegir la topología. Cada trabajo necesita un identificador inmutable de cliente, actor, referencia de entrada, política de modelo, número de intento y clave de idempotencia. Guarda documentos o instrucciones grandes en almacenamiento controlado en vez de meterlos en mensajes de cola. El trabajador debe verificar de nuevo el alcance del cliente; no debe suponer que un mensaje está autorizado por venir de una cola interna.

Los reintentos necesitan reglas explícitas. Reintenta tiempos de espera, errores temporales del proveedor y límites de frecuencia con pausas acotadas. No repitas sin criterio instrucciones inválidas, fallos de autorización ni trabajos que superen un límite definido. Marca cada intento para que un operador distinga una primera ejecución lenta de la quinta ejecución de la misma solicitud cara. Si el proveedor deja de responder después de aceptar el trabajo, la estrategia de idempotencia debe decidir si repetir puede duplicar efectos.

La revisión humana es un estado del flujo, no un comentario unido al resultado del modelo. Guarda la propuesta generada, la decisión, la identidad del revisor, las marcas de tiempo y la versión aprobada. El revisor debe aprobar un artefacto estable, no un valor que el sistema pueda regenerar en silencio después. Así, el enfoque Human-in-a-Loop se puede probar y los equipos obtienen un límite claro alrededor de acciones de alto impacto.

Extrae el trabajador de IA como servicio cuando necesite escalado separado, otro lenguaje o conjunto de dependencias, salida de red más estricta, credenciales propias del proveedor o un ritmo independiente de versiones. Mantén las reglas de orquestación en el dominio del producto salvo que otro equipo las posea de verdad. De lo contrario, el trabajador se convierte en una utilidad remota que sabe demasiado sobre cada función y forma otro monolito al otro lado de la red.

La observabilidad crece en cada límite

Los microservicios no crean observabilidad. Crean más sucesos que hay que correlacionar. En un proceso, una traza de pila y el registro de una solicitud pueden mostrar el recorrido completo. Entre una API, una cola, un trabajador y una devolución, el mismo fallo puede aparecer como cuatro éxitos parciales si el sistema no lleva contexto por cada salto.

OpenTelemetry define trazas, métricas, registros y equipaje como señales distintas. La diferencia importa. Las métricas pueden mostrar que aumentó la latencia de los trabajos. Las trazas pueden indicar dónde pasó el tiempo una muestra de solicitudes. Los registros pueden guardar una respuesta concreta del proveedor o una transición de estado. Ninguna sustituye a las demás, y recogerlas todas sin una pregunta produce una pila cara.

Instrumenta el monolito modular antes de extraer servicios. Da a cada módulo un nombre estable en trazas y registros. Guarda identificadores de solicitud, referencias seguras de cliente, trabajos, versiones desplegadas, estados finales y duraciones. Nunca pongas instrucciones, datos sanitarios, tokens de acceso o resultados completos del modelo en la telemetría. La especificación W3C Trace Context normaliza las cabeceras traceparent y tracestate para transportar la identidad de una traza, y advierte expresamente que no deben contener información personal ni sensible.

Una prueba práctica consiste en seguir una acción del usuario durante todo su ciclo. Empieza en la solicitud HTTP que crea un trabajo de IA, sigue la confirmación en base de datos y la publicación de la bandeja de salida, continúa por el intento del trabajador y termina en el resultado guardado. Un operador debe responder cuatro preguntas sin buscar a mano en consolas inconexas: qué acción inició el trabajo, qué versión gestionó cada etapa, dónde se acumuló tiempo y desde qué estado se puede reanudar con seguridad.

Las colas añaden una trampa frecuente. Que una traza del productor termine bien solo significa que el mensaje fue aceptado. No significa que el trabajo terminara. Lleva el contexto en los metadatos, crea una traza de consumidor para cada intento y enlaza los reintentos sin fingir que son una llamada de red continua. Mide la espera en cola aparte del tiempo de ejecución. Si no, un panel puede culpar al modelo por diez minutos que el trabajo pasó esperando capacidad.

El coste operativo de un servicio nuevo incluye alertas, paneles, objetivos de nivel de servicio, manuales de operación, reglas de retención de registros, política de muestreo y un propietario que sepa interpretarlo. Si el límite candidato no puede expresar su medida de éxito visible para el usuario, no está listo para ser servicio. La distribución amplía la ambigüedad.

La propiedad de los datos revela la factura oculta

Un microservicio real posee sus datos y no permite que otros servicios consulten sus tablas. La guía de Microsoft llama soberanía de datos a este principio y explica la consecuencia: un proceso de negocio entre servicios no puede depender de una sola transacción de base de datos, por lo que el equipo debe gestionar la consistencia eventual. Es la parte que omiten muchos diagramas.

Piensa en la activación de una suscripción. En una transacción, la aplicación podría crear la suscripción, asignar permisos, registrar una factura y encolar la incorporación mediante una bandeja de salida. Si divides esas funciones, puede agotarse el tiempo después de que facturación acepte la solicitud pero antes de que permisos la confirme. El consumidor no sabe si repetir, compensar o esperar salvo que el protocolo defina idempotencia y consulta de estado.

Una cola no decide la semántica de negocio. El equipo debe decidir qué estado manda, cómo tratar duplicados, cuánto pueden durar los estados intermedios, qué fallos activan compensación y qué puede reparar un operador. Cada esquema de evento se convierte en promesa de compatibilidad. Cada campo replicado puede quedar obsoleto. Se puede hacer bien y puede compensar, pero no es escalado gratuito.

Compartir base de datos entre servicios es una transición, no independencia completa. Puede reducir el riesgo migratorio, pero un cambio de esquema aún coordina versiones y un servicio puede saltarse las reglas de otro. Si dos componentes necesitan consistencia transaccional en casi todas sus escrituras, quizá pertenezcan al mismo límite. No sustituyas una transacción local fiable por un flujo distribuido solo para satisfacer un diagrama.

El patrón de bandeja de salida es un puente útil. Escribe el cambio de dominio y un registro de evento en la misma transacción local, y deja que un publicador entregue el evento con reintentos. Los consumidores necesitan idempotencia porque la entrega puede repetirse. El patrón cierra la separación entre confirmación y publicación, pero no garantiza que todas las acciones posteriores terminen ni que cada evento llegue una sola vez.

Antes de extraer, escribe la tabla de fallos. Para cada paso remoto, anota qué ocurre si la solicitud agota el tiempo antes de aceptarse, después de aceptarse, durante la respuesta y durante el reintento. Nombra la acción de conciliación y a la persona o proceso automático que la ejecuta. Si la tabla parece desproporcionada para la función, probablemente también lo sea el límite de red.

El coste de migración depende de los límites actuales

La migración más barata empieza antes de extraer servicios. Un monolito modular puede hacer visibles las dependencias, asignar propiedad de datos y definir contratos mientras las llamadas aún son locales. Esos límites permiten probar el dominio sin depurar a la vez redes, despliegues y consistencia.

Empieza por hacer cumplir las dependencias. Cada módulo expone una interfaz pública pequeña, y las reglas de compilación rechazan importaciones de sus paquetes internos. Da a cada tabla un módulo propietario. Los demás piden comportamiento por la interfaz en vez de unir sus tablas. Publica eventos de dominio dentro del proceso cuando varios módulos necesiten un hecho, pero mantén el contrato explícito y versionado. Estas reglas dibujan el acoplamiento.

Después reúne evidencia. Un candidato gana fuerza si cambia a menudo, escala de forma distinta, tiene otra postura de seguridad, un propietario separado o conflictos repetidos de publicación. La pierde si casi todas las funciones exigen cambios sincronizados, sus datos participan en transacciones constantes entre módulos o su interfaz copia operaciones CRUD. Un servicio con forma de CRUD suele mover registros sin poseer una decisión de negocio.

AWS Prescriptive Guidance describe el patrón strangler fig como sustitución incremental mediante enrutamiento y una capa anticorrupción. Es más seguro que reescribir, pero el proxy no es lo difícil. Lo es la autoridad sobre los datos. Durante la extracción, elige un solo escritor para cada tipo de registro, evita la escritura doble cuando sea posible y haz que el módulo antiguo llame a un adaptador capaz de alternar implementaciones locales y remotas.

Una extracción controlada sigue esta secuencia:

1. Congela el contrato público del módulo y añade pruebas de consumidores sobre el comportamiento real.
2. Coloca su acceso a datos detrás de la interfaz y elimina consultas directas desde otros módulos.
3. Ejecuta la implementación nueva en modo sombra para comparaciones de solo lectura y excluye campos sensibles de los registros.
4. Dirige una parte pequeña y reversible por el adaptador y mantén un único sistema como autoridad de escritura.
5. Retira la implementación local solo después de probar en producción la reversión, la conciliación y la guardia.

No empieces con identidad, autorización compartida o un flujo que toque todos los módulos. Elige un límite con entradas claras, resultados observables e inconsistencia temporal aceptable. El procesamiento de documentos con IA, la conversión de medios, las notificaciones y la indexación suelen encajar. La facturación quizá encaje cuando se estabilice el producto. La primera extracción debe enseñar a operar un servicio sin poner toda la empresa detrás de la lección.

El coste de migración incluye más que tiempo de ingeniería. Cuenta el periodo de infraestructura duplicada, soporte de contratos, conciliación de datos, pruebas extra, formación y avance más lento de funciones. Cuenta también el coste de no migrar: publicaciones retrasadas, escalado desperdiciado, contención repetida y alcance de incidentes. Una decisión creíble compara ambos totales durante un periodo definido en vez de tratar los microservicios como destino inevitable.

Un límite de servicio necesita cinco pruebas

Elige por defecto el monolito modular y exige evidencia para cada división física. No es arquitectura conservadora. Es una forma de gastar complejidad donde cambia un resultado.

Evalúa un candidato con cinco pruebas. Primero, un equipo puede poseer contrato, despliegue, alertas e incidentes. Segundo, necesita publicaciones que en la práctica sean independientes con frecuencia. Tercero, su carga o ejecución difiere lo suficiente para que el escalado separado ahorre capacidad o proteja la latencia. Cuarto, sus datos y fallos soportan un límite de red sin transacciones distribuidas constantes. Quinto, la organización puede observar y recuperar el flujo resultante.

Trata el aislamiento de clientes como un eje aparte. Un servicio puede merecer base de datos o despliegue propio por exigencias contractuales aunque su tráfico sea bajo. Otro componente de alto tráfico puede quedarse dentro porque escala horizontalmente y sus datos pertenecen a la transacción principal. El crecimiento no da la misma respuesta a todo.

Define condiciones de revisión en vez de predecir una arquitectura final. Revisa un módulo cuando la coordinación retrase sus publicaciones de forma repetida, cuando diverja su curva de recursos, cuando otro equipo asuma una propiedad estable, cuando cambien las obligaciones de clientes o cuando los incidentes demuestren que un proceso compartido amplía el daño. Lleva a esa revisión historial de despliegues, trazas, datos de capacidad e informes de fallos.

La decisión también puede retroceder. Si dos servicios siempre se despliegan juntos, comparten propietario y pasan casi todas las solicitudes llamándose, unirlos puede eliminar fallos sin perder autonomía. La arquitectura debe responder a la evidencia en ambas direcciones.

Para un SaaS joven con IA, publicaría un núcleo muy modular, una cola duradera y una ejecución de trabajadores separada donde las cargas de IA lo exijan. Invertiría pronto en contexto de cliente, bandeja de salida, propagación de trazas y pruebas de dependencias. No crearía un servicio por cada sustantivo del producto.

El crecimiento rápido recompensa un sistema capaz de cambiar de forma. Los límites limpios dentro del proceso conservan esa opción a bajo coste. Cuando un límite demuestre propiedad, despliegue, escalado, datos y recuperación distintos, pásalo a la red con confianza. Hasta entonces, la red es un coste que todavía no has justificado.

Preguntas Frecuentes

¿Sirve un monolito modular para un SaaS que crece rápido?

Sí, si la aplicación escala horizontalmente y los límites de sus módulos se hacen cumplir. El crecimiento por sí solo no exige microservicios; una diferencia medida en propiedad, despliegue, ejecución o aislamiento sí puede hacerlo.

¿Qué tamaño debe tener un equipo antes de adoptar microservicios?

No hay una cifra mágica. Adopta un servicio cuando un equipo estable pueda poseer su contrato, versiones, alertas e incidentes sin coordinarse de forma habitual con el resto.

¿Puede un monolito modular desplegar módulos por separado?

No como unidades de ejecución, pero los indicadores de funciones y las pruebas específicas pueden separar la publicación de la exposición. Si un módulo necesita a menudo su propia reversión y cadencia, ese historial respalda extraerlo.

¿Los microservicios aíslan mejor a los clientes?

Solo cuando el límite incluye credenciales, datos, cómputo o acceso de operadores separados. Dividir código no corrige una aplicación que acepta identificadores de cliente sin validar o se salta la autorización.

¿Debe ejecutarse la inferencia de IA dentro de la aplicación principal?

Las llamadas cortas y previsibles pueden empezar allí, pero el trabajo largo o variable debe pasar a una cola duradera. Un trabajador separado protege la latencia web y permite escalar cómputo sin dividir todo el producto.

¿Qué observabilidad hace falta antes de dividir un servicio?

Sigue una acción por solicitudes, colas, trabajadores y resultados guardados. Los operadores necesitan versiones, contexto seguro de cliente, estado del trabajo, tiempos y reintentos antes de que una red multiplique los fallos.

¿Es aceptable compartir una base de datos entre microservicios?

Puede ser un paso temporal, pero limita los cambios independientes de esquema y permite eludir reglas. La autonomía a largo plazo exige propiedad explícita de datos, aunque varios almacenes usen el mismo servidor.

¿Cuál es el primer servicio más seguro para extraer?

Elige una función con entradas claras, salidas observables, escalado distinto e inconsistencia temporal tolerable. El procesamiento de IA, conversión de medios, notificaciones o indexación suelen ofrecer una lección operativa con menor riesgo transaccional.

¿Cómo se evita construir un monolito distribuido?

Exige contratos compatibles, decisiones de publicación independientes y un propietario por servicio. Si los cambios normales requieren despliegues sincronizados o acceso cruzado a datos, corrige el límite o vuelve a unirlo.

¿Puede una empresa volver de microservicios a un monolito?

Sí, y a veces debe hacerlo. Los servicios que siempre se publican juntos, comparten propietario y se llaman constantemente pueden ser más simples y seguros como un único desplegable bien estructurado.