Arquitecturas modernas de sistemas distribuidos

📐 Fundamento

Cuándo migrar a microservicios:

El "monolito modular" es una alternativa frecuentemente ignorada: mantener un solo proceso pero con módulos bien separados. Antes de microservicios, verificar que:

• El equipo tiene > 50 ingenieros (microservicios requieren mucha infraestructura).
• Partes del sistema tienen requisitos de escala drásticamente diferentes.
• Partes del sistema necesitan desplegarse de forma independiente.
• El monolito tiene deuda técnica tan grande que refactorizar es más difícil que reescribir.

Arquitectura de La Esquina Cloud:

Cliente (App Móvil)
       │
       ▼
  [API Gateway]  ← enrutamiento, autenticación, rate limiting
       │
  ┌────┴────┬──────────┬──────────┐
  ▼         ▼          ▼          ▼
[Pedidos]  [Menú]  [Pagos]   [Delivery]
  │BD         │BD     │BD         │BD
  │           │       │           │
  └───────────┴───────┴─────┬─────┘
                             │
                        [Kafka]   ← event bus
                             │
                      [Notificaciones]
                      [Analíticas]
                      [Reportes]

Database per service: Cada microservicio tiene su propia base de datos, independiente de los demás. Garantiza el desacoplamiento pero complica las transacciones que cruzan servicios.

API Gateway: Punto único de entrada que:

• Enruta requests al servicio correcto.
• Gestiona autenticación y autorización.
• Implementa rate limiting.
• Agrega múltiples responses si es necesario (API composition).

# Configuración nginx como API Gateway básico
upstream pedidos_service {
    server pedidos:8001;
}
upstream menu_service {
    server menu:8002;
}

server {
    listen 80;
    
    location /api/pedidos {
        proxy_pass http://pedidos_service;
    }
    location /api/menu {
        proxy_pass http://menu_service;
    }
}

📐 Fundamento

Saga coreografiada (event-driven):

# Servicio de Pedidos
class PedidoService:
    def crear_pedido(self, pedido_data):
        # Transacción local
        pedido = db.create(pedido_data, estado='PENDIENTE')
        
        # Publicar evento → dispara el siguiente paso
        kafka.publish('pedido.creado', {
            'pedido_id': pedido.id,
            'items': pedido_data['items'],
            'monto': pedido_data['monto']
        })
        return pedido

# Servicio de Inventario — escucha 'pedido.creado'
class InventarioService:
    def on_pedido_creado(self, evento):
        try:
            # Reservar inventario
            for item in evento['items']:
                self.reservar(item['platillo_id'], item['cantidad'])
            
            kafka.publish('inventario.reservado', {'pedido_id': evento['pedido_id']})
        except StockInsuficiente:
            # Transacción compensatoria: cancelar el pedido
            kafka.publish('inventario.fallo', {
                'pedido_id': evento['pedido_id'],
                'motivo': 'Stock insuficiente'
            })

# Servicio de Pedidos — escucha 'inventario.fallo'
class PedidoService:
    def on_inventario_fallo(self, evento):
        # Transacción compensatoria: marcar pedido como cancelado
        db.update(evento['pedido_id'], estado='CANCELADO')
        notificar_cliente(evento['pedido_id'], 'Pedido cancelado por falta de stock')

# Flujo completo:
# pedido.creado → inventario.reservado → pago.procesado → pedido.confirmado
#                 → inventario.fallo → pedido.cancelado (compensación)

Saga orquestada (con orquestador central):

Un servicio orquestador coordina explícitamente los pasos:

class SagaCrearPedido:
    """Orquestador que coordina los pasos de crear un pedido."""
    
    def ejecutar(self, pedido_id):
        try:
            # Paso 1
            pedido = self.pedido_service.confirmar_pedido(pedido_id)
            
            # Paso 2
            try:
                self.inventario_service.reservar(pedido.items)
            except StockInsuficiente as e:
                self.pedido_service.cancelar(pedido_id, str(e))
                return {'exito': False, 'motivo': str(e)}
            
            # Paso 3
            try:
                self.pago_service.cobrar(pedido.monto, pedido.metodo_pago)
            except PagoFallido as e:
                self.inventario_service.liberar(pedido.items)  # compensación
                self.pedido_service.cancelar(pedido_id, str(e))
                return {'exito': False, 'motivo': str(e)}
            
            # Todo exitoso
            self.pedido_service.confirmar_listo(pedido_id)
            return {'exito': True}
        
        except Exception as e:
            # Error inesperado — ejecutar compensaciones en orden inverso
            self._compensar(pedido_id)
            raise

Coreografía vs Orquestación:

📐 Fundamento

Arquitectura de service mesh con Istio/Envoy:

[Servicio Pedidos] ←→ [Envoy Proxy]  ←  mTLS  →  [Envoy Proxy] ←→ [Servicio Menú]
                           ↕                               ↕
                    [Control Plane (Istio)]  ←  configura  →  [Control Plane]

Lo que el sidecar maneja automáticamente:

# VirtualService: traffic management
apiVersion: networking.istio.io/v1alpha3
kind: VirtualService
metadata:
  name: pedidos-service
spec:
  hosts:
    - pedidos-service
  http:
    - route:
      - destination:
          host: pedidos-service
          subset: v1
        weight: 90           # 90% del tráfico a v1
      - destination:
          host: pedidos-service
          subset: v2
        weight: 10           # 10% a v2 (canary deployment)
      retries:
        attempts: 3
        perTryTimeout: 2s
      timeout: 10s

# DestinationRule: circuit breaker
apiVersion: networking.istio.io/v1alpha3
kind: DestinationRule
metadata:
  name: pedidos-cb
spec:
  host: pedidos-service
  trafficPolicy:
    outlierDetection:
      consecutiveErrors: 5   # 5 errores consecutivos → expulsar del pool
      interval: 10s
      baseEjectionTime: 30s

Kubernetes — orquestador de contenedores:

# Deployment de microservicio de pedidos
apiVersion: apps/v1
kind: Deployment
metadata:
  name: pedidos-service
spec:
  replicas: 3              # 3 instancias para alta disponibilidad
  selector:
    matchLabels:
      app: pedidos
  template:
    spec:
      containers:
        - name: pedidos
          image: esquina/pedidos:v2.1.0
          ports:
            - containerPort: 8001
          resources:
            requests:
              memory: "256Mi"
              cpu: "250m"
            limits:
              memory: "512Mi"
              cpu: "500m"
          livenessProbe:   # Kubernetes mata y reinicia si falla
            httpGet:
              path: /health
              port: 8001
            initialDelaySeconds: 30
            periodSeconds: 10
          readinessProbe:  # Kubernetes no envía tráfico hasta que esté listo
            httpGet:
              path: /ready
              port: 8001

📐 Fundamento

CQRS (Command Query Responsibility Segregation):

Separar el modelo de escritura (Command) del modelo de lectura (Query). Las escrituras van a la BD normalizada; las lecturas van a proyecciones desnormalizadas optimizadas para consultas.

[App] → [Command Handler] → [Write DB (PostgreSQL normalizado)]
                                      ↓
                               [Event Store] → [Projector]
                                                    ↓
                               [Read DB (Redis/ElasticSearch desnormalizado)]
                                      ↑
                              [Query Handler] ← [App]

Event Sourcing:

En lugar de guardar el estado actual, guardar todos los eventos que llevaron a ese estado. El estado se reconstruye reproduciendo los eventos.

# Event sourcing para pedidos
EVENTOS = [
    {'tipo': 'PedidoCreado',     'timestamp': '2026-05-05T12:00:00', 'mesa_id': 3},
    {'tipo': 'ItemAgregado',     'timestamp': '2026-05-05T12:01:00', 'platillo_id': 1, 'cantidad': 2},
    {'tipo': 'PedidoConfirmado', 'timestamp': '2026-05-05T12:01:30'},
    {'tipo': 'PedidoListo',      'timestamp': '2026-05-05T12:15:00'},
    {'tipo': 'PedidoCerrado',    'timestamp': '2026-05-05T12:30:00', 'total': 8.50},
]

def reconstruir_pedido(eventos: list) -> dict:
    estado = {}
    for evento in eventos:
        match evento['tipo']:
            case 'PedidoCreado':
                estado = {'mesa_id': evento['mesa_id'], 'items': [], 'estado': 'ABIERTO'}
            case 'ItemAgregado':
                estado['items'].append({'platillo_id': evento['platillo_id'], 
                                         'cantidad': evento['cantidad']})
            case 'PedidoConfirmado':
                estado['estado'] = 'CONFIRMADO'
            case 'PedidoListo':
                estado['estado'] = 'LISTO'
            case 'PedidoCerrado':
                estado['estado'] = 'CERRADO'
                estado['total'] = evento['total']
    return estado

pedido_actual = reconstruir_pedido(EVENTOS)

Ventajas del Event Sourcing:

• Auditoría completa — sabés exactamente qué pasó y cuándo.
• Reproducir el estado en cualquier punto del pasado.
• Fácil de agregar nuevas proyecciones (analytics, reportes) sin modificar el core.

Desventajas:

• Mayor complejidad.
• Las queries de estado actual requieren reproducir todos los eventos (mitigado con snapshots).