Patrones de Sistemas Distribuidos y Kubernetes

El patrón Ambassador actúa como intermediario entre tu servicio y el mundo exterior. En lugar de que tu aplicación maneje logging, reintentos, rate limiting y monitoreo, un proxy dedicado se encarga de todo eso mientras tu código se enfoca exclusivamente en la lógica de negocio.

Es como tener un asistente personal que filtra todas tus comunicaciones: vos solo recibís lo que importa, ya procesado y en el formato correcto.

• Centraliza logging y tracing de requests sin tocar código de negocio
• Maneja TLS termination, retries y circuit breaking a nivel de infraestructura
• Permite cambiar políticas de red en caliente sin redesplegar servicios

El Sidecar viaja acoplado al contenedor principal dentro del mismo Pod, compartiendo red y filesystem. Se usa para tareas transversales: recolección de logs, exportación de métricas, sincronización de configuración, terminación TLS o service mesh.

La clave es la separación de responsabilidades: tu servicio principal se mantiene simple y enfocado, mientras los sidecars son componentes reutilizables entre distintos servicios.

• El contenedor sidecar comparte el ciclo de vida del Pod
• Equipos diferentes pueden desarrollar y versionar el sidecar de forma independiente
• Un mismo sidecar de logging sirve para servicios en Node, Python, Go o Java

Cuando una tubería de agua se rompe, lo primero que hacés es cerrar la llave principal. El Circuit Breaker funciona igual: cuando un servicio downstream deja de responder, el circuito se “abre” para detener las peticiones y evitar que el fallo se propague por todo el sistema.

Opera en tres estados: Cerrado (flujo normal), Abierto (requests bloqueados, se devuelve un fallback) y Semi-abierto (se permiten requests limitados para testear la recuperación del servicio).

• Previene que un servicio degradado consuma los recursos de todo el clúster
• El estado Semi-abierto permite recuperación automática sin intervención manual
• Combinado con Bulkhead Pattern, aísla compartimentos para mayor resiliencia

En la mayoría de aplicaciones, las lecturas superan ampliamente a las escrituras. Un e-commerce recibe miles de consultas de productos por cada compra. CQRS (Command Query Responsibility Segregation) separa ambas operaciones en servicios independientes, permitiendo que cada uno escale según su demanda real.

El servicio de lectura puede usar réplicas optimizadas y cachés agresivos; el de escritura se enfoca en consistencia transaccional. Cada lado evoluciona y escala sin afectar al otro.

• El servicio de queries puede usar bases de datos read-only optimizadas
• Permite adoptar tecnologías diferentes para cada lado (SQL para escrituras, Elasticsearch para lecturas)
• Se combina naturalmente con Event Sourcing para un flujo de datos reactivo completo

En lugar de guardar solo el estado actual de tus datos, Event Sourcing almacena cada cambio como un evento inmutable en una secuencia ordenada. El estado se reconstruye “reproduciendo” los eventos. Esto ofrece auditoría completa, capacidad de depuración temporal y una integración natural con arquitecturas event-driven.

• Auditoría completa: cada cambio queda registrado con timestamp y contexto
• Permite “time travel debugging” reproduciendo eventos hasta un punto específico
• Ideal para sistemas financieros, colaboración en tiempo real y compliance

Cuando múltiples nodos pueden ejecutar la misma tarea, necesitás un mecanismo para designar a uno como “líder” que coordine las operaciones. Si el líder cae, otro nodo asume automáticamente el rol. El patrón maneja la temida situación de split-brain (dos líderes activos simultáneos) mediante generation clocks o epoch numbers.

• Garantiza que una sola instancia ejecute tareas críticas como migraciones o cron jobs
• Failover automático: si el líder no renueva el lease, otro nodo asume en segundos
• Bases de datos como Cassandra y brokers como Kafka dependen de este patrón

En lugar de que los servicios se comuniquen directamente (acoplamiento fuerte), el patrón Publisher/Subscriber introduce un intermediario: los publicadores envían mensajes a topics y los suscriptores reciben solo los que les interesan. Productores y consumidores no se conocen entre sí.

• Los productores publican sin saber quién consume; los consumidores suscriben sin saber quién produce
• Resiliencia bajo carga: los mensajes se encolan si un consumidor está temporalmente caído
• Base de arquitecturas event-driven para notificaciones, pagos y analytics

Cuando los datos crecen más allá de lo que un solo nodo puede manejar, el Sharding particiona la información en subconjuntos distribuidos según criterios como rangos de claves o algoritmos de hashing. Cada shard opera de forma semi-independiente, escalando horizontalmente tanto capacidad como throughput.

• Escala horizontalmente: más datos = más shards, no servidores más caros
• Cada shard puede tener sus propias réplicas para alta disponibilidad
• Bases de datos como MongoDB, Cassandra y CockroachDB lo implementan nativamente