Microservicios
Este artículo es una guía conceptual sobre arquitectura de microservicios, incluyendo preguntas de examen, componentes clave y referencias.
Resumen
Los microservicios son servicios pequeños y desplegables de forma independiente, cada uno con responsabilidades de negocio claramente definidas. Cada servicio encapsula sus datos y se comunica a través de interfaces bien establecidas.
Descripción técnica
El sistema se divide en servicios alineados con límites de negocio, frecuentemente siguiendo un Bounded Context (DDD). Cada servicio posee su propio modelo de datos y persistencia.
Comunicación:
- preferiblemente asincrónica mediante Events
- sincrónica de forma restrictiva vía REST/gRPC
La consistencia es generalmente eventual. Las transacciones distribuidas se coordinan mediante Sagas. Los efectos secundarios confiables se garantizan usando Outbox/Inbox e handlers idempotentes.
En operaciones, CI/CD, orquestación de contenedores (por ejemplo Kubernetes), Observability (logs/métricas/traces) y Security by Default (Zero Trust, mTLS, OAuth/OIDC, Secrets) son esenciales.
Anti-patrón: Monolito distribuido (cadenas sincrónicas demasiado fuertes o base de datos compartida).
Puntos clave para examen
- Corte de negocio: Bounded Context; datos por servicio; sin esquema compartido
- Preferir asincrónico, usar sincrónico con moderación (latencia/fallos en cascada)
- Sagas, Outbox/Inbox, Idempotencia
- IHK: Identificar objetivos de calidad/SLOs
- Seguridad: mTLS, OAuth/OIDC, Secrets, Rate Limiting
- Viabilidad económica: Autonomía vs. mayor complejidad operacional
- Documentación: C4 (L1-L3), ADRs, contratos de interfaz, plan operacional
Componentes principales
- Bounded Context
- Diseño de API + Versionamiento
- Datos por servicio
- Messaging/Queues/Streams
- Service Discovery/Gateway
- Resiliencia (Timeouts, Retries, Circuit Breaker)
- Observability + Correlation IDs
- CI/CD + IaC
- Seguridad (AuthN/AuthZ, Secrets)
- Tests (Contract/Chaos/Load)
Ejemplo práctico (Saga)
Order Service crea Order (pending) + Event (Outbox)
Orchestrator:
- invoca Payment Service (Idempotency Key)
- invoca Inventory Service (Reservation)
- confirma Order o compensa (Refund/Cancel)
Ejemplo práctico (Tienda online como microservicios)
Gestión de usuarios (ej. Java + PostgreSQL)
Catálogo de productos (ej. Node.js + MongoDB)
Procesamiento de pedidos (ej. Python + Message Broker)
Comunicación: REST + Events
Explicación: Cada servicio tiene su propia base de datos, puede escalarse y mantenerse independientemente. Los cambios en un servicio no deben romper directamente los otros (contratos limpios/versionamiento).
Ventajas e inconvenientes
Ventajas
- Despliegues independientes
- Escalado por servicio
- Mejor aislamiento de fallos
- Autonomía de equipos
Inconvenientes
- Mayor complejidad operacional y arquitectónica
- Depuración distribuida más difícil
- La consistencia de datos debe modelarse explícitamente
Preguntas típicas de examen (con respuesta breve)
- ¿Cómo se definen los límites de los microservicios? Siguiendo Bounded Context (DDD).
- ¿Cómo se coordinan transacciones distribuidas? Saga + Compensación + Outbox.
- ¿Por qué las cadenas sincrónicas son problemáticas? Latencia y fallos en cascada.
- ¿Qué significa “datos por servicio”? Cada base de datos pertenece a un servicio; acceso solo mediante APIs/Events.
Respuesta libre
Los microservicios tienen sentido solo si existen cortes de dominio claros, plataforma/DevOps sólida y Observability/Seguridad adecuada. De lo contrario, fácilmente se convierte en un monolito distribuido.
Estrategia de aprendizaje
- Analizar una arquitectura de 3 servicios (APIs/Events/Propiedad de datos).
- Crear diagrama de secuencia Saga incluyendo rutas de error.
- Practicar ventajas/inconvenientes en formato tabla.
- Evitar bases de datos compartidas.
Herramientas típicas (práctica)
- Docker / Kubernetes
- OpenAPI/Swagger para documentación de API
- Métricas/Monitoring (ej. Prometheus, Grafana)
- Tracing (ej. Zipkin/Jaeger)



