Skip to content
IRC-CodingIRC-Coding
MicroservicesBounded ContextSagaOutboxObservabilityAPI Gateway

Microservices: Bounded Context, Saga y Observability

Guía completa de arquitectura Microservices: DDD, Bounded Context, patrones Saga, Outbox, Observability, seguridad y mejores prácticas.

S

schutzgeist

2 min read
Microservices: Bounded Context, Saga y Observability

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

  1. Bounded Context
  2. Diseño de API + Versionamiento
  3. Datos por servicio
  4. Messaging/Queues/Streams
  5. Service Discovery/Gateway
  6. Resiliencia (Timeouts, Retries, Circuit Breaker)
  7. Observability + Correlation IDs
  8. CI/CD + IaC
  9. Seguridad (AuthN/AuthZ, Secrets)
  10. 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)

  1. ¿Cómo se definen los límites de los microservicios? Siguiendo Bounded Context (DDD).
  2. ¿Cómo se coordinan transacciones distribuidas? Saga + Compensación + Outbox.
  3. ¿Por qué las cadenas sincrónicas son problemáticas? Latencia y fallos en cascada.
  4. ¿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

  1. Analizar una arquitectura de 3 servicios (APIs/Events/Propiedad de datos).
  2. Crear diagrama de secuencia Saga incluyendo rutas de error.
  3. Practicar ventajas/inconvenientes en formato tabla.
  4. 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)

Fuentes principales

  1. https://microservices.io
  2. https://martinfowler.com/microservices
Volver al blog
Share:

Nächster Artikel in Arquitectura de Software

Weiterlesen
Microservices: Bounded Context, Saga y Resiliencia

Entradas relacionadas