Microservicios en Go: lecciones desde producción

Los microservicios no son un objetivo, sino una herramienta

Fragmentar un sistema en servicios por moda es un camino seguro hacia un monolito distribuido más difícil que el original. Los microservicios se justifican cuando hay que escalar partes del sistema de forma independiente y dar autonomía a los equipos.

Dónde trazar los límites

Trazamos los límites de los servicios por dominios, apoyándonos en los contextos delimitados del DDD. Cada servicio es dueño de sus datos: una base de datos compartida entre servicios es un antipatrón que conduce a un acoplamiento oculto.

Principios que se han demostrado

• Un almacenamiento separado para cada servicio.
• Intercambio asíncrono de eventos en lugar de cadenas de llamadas síncronas.
• Contratos explícitos y versionados entre servicios.

Consistencia de los datos

En un sistema distribuido no hay transacciones globales. Usamos el patrón saga para las operaciones de negocio de larga duración y el transactional outbox para la publicación fiable de eventos sin pérdidas ni duplicados.

Tolerancia a fallos y observabilidad

Los tiempos de espera, los reintentos con backoff, un circuit breaker y los manejadores idempotentes protegen frente a los fallos en cascada. Los identificadores de correlación, las métricas y el trazado distribuido hacen visible el recorrido de una solicitud a través de decenas de servicios.

Conclusiones

Los microservicios ofrecen una enorme flexibilidad, pero requieren una cultura de ingeniería madura. Empieza con un monolito bien estructurado y extrae servicios cuando haya razones reales para ello.