Lección 170: Principales desafíos de los microservicios: consistencia de datos, complejidad de la monitorización, tolerancia a fallos

Hoy nos vamos a meter más a fondo y vamos a hablar de los principales desafíos de la arquitectura de microservicios: cómo lidiar con problemas de consistencia de datos, monitorización y tolerancia a fallos.

Consistencia de datos en microservicios

Ah, la consistencia de datos... Los que vienen de monolitos suelen darla por sentada: hay una sola base de datos, los cambios se hacen dentro de una única transacción — todo tiene sentido y es transparente. Pero con los microservicios esa "ilusión de simplicidad" se pierde.

¿Por qué surge el problema? Porque en una arquitectura de microservicios cada servicio suele tener su propia base de datos (sí, el aislamiento de datos es lo más). Pero eso hace que las operaciones que afectan a varios servicios a la vez se vuelvan "complicadas". Por ejemplo, ¿qué pasa si tienes un servicio de pedidos y otro de pagos, y necesitas asegurarte de que tanto el pedido como el pago se realizaron con éxito?

Ahí ya no puedes simplemente decir: "vale, lo hago todo en una transacción". No, colega, en un sistema distribuido necesitas un enfoque más sofisticado.

Cómo solucionarlo

Las transacciones distribuidas se pueden manejar con el patrón Sagas (Sagas). La idea es: cada servicio hace su parte y notifica al resto cuando termina con éxito. Si algo falla, se lanza una operación compensatoria (rollback).

Diagrama del trabajo de una Saga:

+-------------------+             +-------------------+
| Order Service     |  -------->  | Payment Service   |
+-------------------+             +-------------------+
        |                               |
        |        [Success]              |       [Success]
        |                               |
+-------------------+          +-------------------+
| Inventory Service |  <-------| Notification Svc |
+-------------------+          +-------------------+

En la práctica:

1. Orquestación — un componente principal controla el proceso (por ejemplo, un Saga Orchestrator).
2. Coreografía — los propios servicios intercambian eventos y reaccionan al éxito/error de los demás.

Ejemplo de implementación:

// Ejemplo de orquestación de saga en Spring
public class OrderService {
    @Autowired
    private EventPublisher eventPublisher;

    public void createOrder(Order order) {
        eventPublisher.publishEvent(new OrderCreatedEvent(order));
    }

    @EventListener
    public void onPaymentSuccessful(PaymentCompletedEvent e) {
        eventPublisher.publishEvent(new InventoryReservedEvent(e.getOrderId()));
    }

    @EventListener
    public void onInventoryFailure(InventoryFailureEvent e) {
        // Compensación: cancelamos el pedido
        eventPublisher.publishEvent(new OrderCancelledEvent(e.getOrderId()));
    }
}

Otro enfoque para la consistencia es el principio de Eventual Consistency. Funciona así: los cambios se propagan por el sistema mediante eventos, y al final todo converge a un estado consistente (más o menos "casi instantáneo").

Puedes usar brokers de mensajería como Kafka para pasar esos eventos entre microservicios.

Complejidad de la monitorización

Si pensabas que monitorizar una app monolítica ya era complicado, escucha esto: en un sistema con decenas (¡o cientos!) de microservicios la cosa se pone mucho peor. Encontrar dónde "duele" puede ser un rompecabezas.

¿Por qué la monitorización es compleja?

1. Muchas superficies de fallo. En un monolito suele haber una base de datos, un servidor. En una arquitectura de microservicios hay cientos de puntos de fallo.
2. Arquitectura distribuida. Los servicios se comunican por la red, y depurar errores es más difícil: "¿es problema del servicio o de la red?".
3. Asincronía. Pueden aparecer latencias en el procesamiento de eventos y comportamientos impredecibles.

Cómo solucionarlo

Usa herramientas como Spring Cloud Sleuth y Zipkin para trazar las cadenas de llamadas entre microservicios. Añaden un identificador único a cada request y lo propagan por todos los eslabones.

Configuración de Sleuth y Zipkin:

spring:
  sleuth:
    sampler:
      probability: 1.0
zipkin:
  base-url: http://localhost:9411

Ese enfoque te permite ver qué servicios están "frenando" la cadena y detectar cuellos de botella.

Herramientas como Prometheus y Grafana te ayudan a seguir métricas (por ejemplo, rendimiento, uso de memoria) en tiempo real. También puedes añadir métricas personalizadas vía Spring Actuator.

Ejemplo de métrica personalizada:

@Component
public class CustomMetrics {
    private final Counter myCounter;

    public CustomMetrics(MeterRegistry registry) {
        this.myCounter = Counter.builder("custom.metric")
            .description("Example custom metric")
            .register(registry);
    }

    public void increment() {
        myCounter.increment();
    }
}

Tolerancia a fallos en microservicios

Si estás desarrollando un sistema distribuido, guarda en la cabeza una verdad de la vida: todo se va a romper. La red puede caer, un servidor puede colgarse, la base de datos puede dejar de responder. La cuestión no es si, sino cuándo. El objetivo es simple: minimizar el impacto de los fallos.

Problemas relacionados con fallos

1. Reacciones en cadena. Un servicio cae y arrastra al resto del sistema.
2. Respuestas lentas. Si un servicio va lento, puede ralentizar toda la cadena.

Cómo solucionarlo

El patrón Circuit Breaker previene las reacciones en cadena. Si un servicio deja de responder correctamente, el Circuit Breaker corta la comunicación y devuelve una respuesta predefinida (o nada). Después de un tiempo prueba otra vez si el servicio está bien.

Implementación con Resilience4j:

@Retry(name = "myService", fallbackMethod = "fallback")
public String callExternalService() {
    // Lógica de llamada al servicio externo
}

public String fallback(Exception e) {
    return "Fallback response";
}

Otro truco es el Fallback: si un servicio no está disponible, devuelve una respuesta precacheada. También limita los timeouts (tiempos de espera) de las peticiones.

Spring Cloud Retry:

spring:
  cloud:
    loadbalancer:
      retry:
        enabled: true

En la vida real

Todo lo que hemos visto hoy es vital para el desarrollo real. Los problemas de consistencia aparecen cuando quieres guardar al mismo tiempo el pedido y el pago, y la monitorización con trazas distribuidas se convierte en tu mejor aliada cuando algo se rompe. Circuit Breaker te salva de las reacciones en cadena, y los Fallbacks y Retry evitan desastres mayores.