Microservicios

Conjunto de servicios pequeños y autónomos, cada uno con su propio deploy y su propia base de datos, comunicados por red.

#Ejemplo

                ┌──────────┐  ┌──────────┐  ┌──────────┐
                │  Orders  │  │ Payments │  │ Shipping │
                │  + DB    │  │   + DB   │  │  + DB    │
                └────┬─────┘  └────┬─────┘  └────┬─────┘
                     └─────── Message Bus ───────┘

#Ventajas

• Equipos autónomos.
• Escalado por servicio.
• Aislamiento de fallos.
• Stacks heterogéneos.

#Coste real

• DevOps significativo: orquestación (K8s), service mesh, tracing, schema registry.
• Eventual consistency y compensaciones (Saga, Outbox).
• Latencia de red entre componentes que antes eran llamadas a función.
• Versionado de contratos.

#Cuándo sí tienen sentido

Los microservicios son una solución a problemas de escala organizacional y operativa (decenas de equipos, partes del sistema con carga muy distinta). No son un nivel superior de madurez: para la mayoría de los productos, un Modulith da el 80% del beneficio con una fracción del costo. Equipos como Amazon Prime Video han publicado que volvieron de servicios distribuidos a un monolito para una parte de su sistema por costo y complejidad.

Antes de partir en servicios, tenés que poder responder sí a casi todo esto:

1. ¿Tenemos equipos que se pisan en el deploy y no pueden coordinarse?
2. ¿Hay un cuello de botella medido que solo se resuelve escalando un componente por separado?
3. ¿Los bounded contexts están estables (los límites no cambian cada sprint)?
4. ¿Tenemos CI/CD, observabilidad y on-call maduros?
5. ¿El presupuesto cubre infraestructura y gente de plataforma?

Si la respuesta es no, empezá con el Modulith. Ver la comparativa.

#architecture #microservices #distributed