Servicios separados, despliegues independientes, escalado por componente, colas, eventos y observabilidad: los microservicios parecen una arquitectura preparada para crecer. A veces lo son. También pueden convertir un sistema simple en varios sistemas difíciles de mantener antes de que exista un problema que justifique esa separación. Una arquitectura más distribuida no es automáticamente una arquitectura mejor.
Separar cosas tiene un costo
Cuando una aplicación vive dentro de un solo proyecto, muchas operaciones son directas. Una función llama a otra. Una transacción modifica varios datos. Un error puede seguirse dentro del mismo proceso.
Al separar servicios aparecen nuevas fronteras: red, autenticación entre sistemas, versiones de contratos, fallos parciales, reintentos, sincronización y logs distribuidos.
Deploys independientes. Todo eso puede ser necesario. Pero no es gratis.
El monolito no es el enemigo
"Monolito" suele usarse como sinónimo de software viejo y difícil de mantener, pero una aplicación monolítica puede estar bien organizada, con módulos claros, responsabilidades separadas, buenas pruebas, interfaces internas definidas y un despliegue simple. Para muchos productos, especialmente en sus primeras etapas, esa estructura permite avanzar más rápido sin cerrar la puerta a separar componentes después. El problema no es que todo viva en el mismo repositorio o proceso. El problema es que todo dependa de todo.
Hay una diferencia entre modular y distribuido
Muchas veces lo que un proyecto necesita no son microservicios. Necesita límites mejores. Facturación puede ser un módulo. Inventario puede ser otro.
Usuarios puede ser un tercer módulo. Cada uno puede tener responsabilidades claras sin convertirse inmediatamente en una aplicación separada con su propia infraestructura. Eso mantiene la arquitectura entendible y prepara el sistema para una separación futura si alguna parte realmente lo necesita: primero se separan los conceptos.
Después, si hace falta, separar procesos.
¿Cuándo empieza a tener sentido?
Hay casos donde dividir un sistema resuelve problemas reales. Un componente necesita escalar de manera muy distinta al resto. Distintos equipos trabajan sobre áreas independientes y necesitan desplegar sin bloquearse. Una parte del sistema requiere otra tecnología por una razón concreta.
Un proceso pesado necesita ejecutarse de forma aislada. Hay requisitos de disponibilidad o seguridad que justifican una separación fuerte. Ahí la complejidad adicional puede pagar su costo. La diferencia es que existe un problema concreto que estamos resolviendo.
No solamente una arquitectura que queremos usar.
Escalar usuarios no siempre significa escalar arquitectura
Es fácil pensar: "si esto crece, necesitamos microservicios". Pero un monolito bien desarrollado puede soportar muchísimo tráfico. Antes de dividirlo conviene revisar problemas bastante menos exóticos.
Antes suelen aparecer consultas lentas, índices faltantes, trabajo innecesario en cada petición, archivos mal servidos, procesos que deberían ejecutarse en segundo plano, falta de caché o servidores subdimensionados. Muchas veces el cuello de botella no es tener una sola aplicación.
Es lo que esa aplicación está haciendo.
La base de datos suele delatar la separación falsa
Hay sistemas que se presentan como microservicios pero todos leen y escriben directamente sobre las mismas tablas. Eso conserva buena parte del acoplamiento original y agrega comunicación por red encima. Si un servicio no puede cambiar sin conocer la estructura interna de otro, probablemente la separación sea más visual que real.
Dividir código es fácil. Dividir responsabilidades y datos es bastante más difícil.
La consistencia también cambia
Dentro de una aplicación y una base de datos podemos ejecutar varias operaciones dentro de una transacción. O sale todo bien o no se guarda nada. En sistemas distribuidos, esa garantía puede desaparecer. Un servicio actualiza correctamente.
Otro falla. Un tercero todavía no recibió el evento. Ahora el sistema puede estar temporalmente en estados diferentes según dónde miremos. Eso no significa que esté mal.
Significa que la arquitectura tiene que estar preparada para convivir con esa realidad. Y eso agrega trabajo.
Los fallos parciales son normales
Si una aplicación depende de cinco servicios y uno deja de responder, ¿qué pasa? ¿Todo deja de funcionar? ¿Solamente se desactiva una función? ¿Guardamos la operación para intentarla después?
¿Mostramos información incompleta? En un sistema distribuido no existe solamente "la aplicación está funcionando" o "la aplicación está caída". Puede haber partes funcionando y otras no. Diseñar esos estados forma parte de la arquitectura.
También hay que poder operar el sistema
Cuantos más componentes aparecen, más importante se vuelve entender qué está pasando mediante logs centralizados, métricas, trazas, alertas, versiones desplegadas, estado de colas y controles de salud.
Sin ese nivel de observabilidad, investigar un error puede convertirse en saltar entre servidores intentando reconstruir el recorrido de una petición. Una arquitectura que escala técnicamente pero que nadie puede diagnosticar no está preparada para crecer.
La organización también importa
A veces los microservicios aparecen porque funcionan bien en empresas con cientos de desarrolladores. Pero la arquitectura de una empresa grande también responde a su estructura humana. Muchos equipos necesitan independencia. Un equipo de tres personas tiene otro problema.
Si las mismas dos personas tienen que mantener doce servicios, pipelines, repositorios y bases de datos, la independencia empieza a ser ficticia. La arquitectura debería considerar quién va a operarla, no solamente qué puede hacer técnicamente.
Empezar simple no significa improvisar
Elegir una arquitectura más sencilla no significa meter todo en cualquier lugar. Desde el principio se pueden separar dominios y evitar dependencias innecesarias.
Usar colas donde realmente aportan valor. Diseñar contratos internos claros. Preparar componentes para poder extraerlos más adelante. La diferencia está en no pagar hoy una complejidad que quizá necesitemos dentro de tres años.
La arquitectura tiene que justificar sus piezas
Microservicios, monolitos, serverless, colas y funciones ejecutadas por cron son herramientas. La pregunta importante no es cuál parece más moderna. Es qué problema resuelve cada pieza y qué costo agrega. Si no podemos responder eso, probablemente estemos diseñando para una escala que todavía no existe.
La arquitectura adecuada es la que justifica cada una de sus piezas. El mismo criterio sirve al decidir cuándo WordPress deja de encajar con un producto: elegir por el problema, no por la herramienta.