Microservicios

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

Contexto

Una organización con muchos equipos, bounded contexts claros y madurez operativa (CI/CD, observabilidad, on-call), que quiere desplegar de forma independiente y escalar partes específicas.

Problema

Un monolito acopla equipos, ciclos de release y escalado.

Solución

Servicios pequeños, alineados a un bounded context, con su propia BD, comunicándose por mensajes o HTTP.

#Ejemplo

CSHARP 
                ┌──────────┐  ┌──────────┐  ┌──────────┐
                │  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 NO aplicarlo
  • Equipo pequeño (menos de 20 personas) o producto todavía buscando product-market fit: el coste operativo te aplasta.
  • Sin observabilidad madura ni equipo de plataforma: vas a sufrir.
  • Si los servicios necesitan compartir mucha data en transacciones: estás dividiendo el dominio mal.
Tradeoffs
Pro Contra
Equipos autónomos, deploy independiente Operativa compleja y cara (orquestación, observabilidad)
Escalado granular Latencia y fallos de red por todas partes
Aísla fallos Eventual consistency
Stacks heterogéneos posibles Sistemas distribuidos: más bugs y más superficie a defender

#architecture #microservices #distributed