Un servicio o muchos: cuándo dividir
Por qué un monolito no es una palabrota
Un sistema es más fácil de desplegar, depurar y cambiar entre dominios. La mayoría de los proyectos divididos pronto recibieron todo el coste de dividir — red, versiones, monitorización distribuida, consistencia — antes de recibir ningún beneficio.
Señales de que es hora
Una publicación bloqueada porque los equipos se esperan; un componente con necesidades de recursos del todo distintas; una parte que exige un nivel de disponibilidad o una regulación aparte; un ritmo de cambio muy distinto entre zonas.
La señal que no basta: “porque así se construye hoy”.
Cómo dividir bien
Por una frontera de negocio y no por una capa técnica. Cada servicio guarda sus propios datos y no llama a la base de datos de otro. Comunicación por un contrato explícito, y eventos en vez de llamadas síncronas donde se pueda.
Antes de dividir, comprueba que las fronteras funcionan dentro del propio monolito: módulos bien separados son un ensayo general barato.
En profundidad
Dividir exige infraestructura: trazado distribuido, monitorización por servicio, gestión de configuración, y un estándar compartido de errores y reintentos. Si esa infraestructura no existe, la división no resolverá un problema de ritmo sino que lo reemplazará por un problema de operación.