Lección 209: Errores principales al usar EDA y cómo evitarlos

Hablemos de las trampas que te puedes encontrar al diseñar una arquitectura orientada a eventos. Como dicen, "el listo aprende de los errores ajenos", así que veamos qué fallos son más comunes y cómo evitarlos.

Error №1: Acoplamiento excesivo entre servicios

Si tu sistema de eventos parece una telaraña donde cada servicio depende de decenas de otros, algo va mal. La idea principal de EDA es desacoplar servicios y hacerlos independientes. Sin embargo, si cada servicio depende de otros en el esquema de "yo espero a que ellos hagan algo", entonces eso ya no es un acoplamiento suave, es un nudo infernal.

¿Por qué pasa esto?

• Diseño incorrecto de eventos, donde un evento desencadena una cascada de otros eventos.
• Uso de un único topic para distintos tipos de datos, lo que obliga a los servicios a analizar datos "que no son suyos".
• Eventos "delgados" que no contienen suficiente contexto, forzando a los suscriptores a consultar otros servicios para obtener información adicional.

¿Cómo evitarlo?

• Diseña los eventos teniendo en cuenta el contexto. Cada evento debe ser autosuficiente y contener toda la información necesaria.
• Minimiza el número de suscriptores. Un servicio debe suscribirse solo a los eventos que realmente necesita.
• Usa topics distintos para diferentes tipos de eventos. Esto reducirá la probabilidad de "contaminación cruzada".

Ejemplo de la vida real: si el microservicio "Pedidos" publica el evento OrderCreated, el microservicio "Almacén" no debería depender de la respuesta del servicio "Pago". Que trabajen de forma independiente.

Error №2: Manejo deficiente de errores y entrega no garantizada

Imagínate la situación: enviaste un evento y nadie lo procesó. O peor: el servicio que debía procesarlo se cayó. Y tus datos se perdieron. Este es un problema clásico ligado a la falta de un buen manejo de errores.

¿Por qué pasa esto?

• Uso de delivery "at most once" en escenarios críticos.
• Configuración incorrecta de los brokers de mensajes (por ejemplo, un retention period pequeño en Kafka).
• Ignorar la reentrega de mensajes (retries).

¿Cómo evitarlo?

• Usa el enfoque "at least once". Deja que los mensajes se entreguen al menos una vez, aunque exista el riesgo de procesamiento repetido.
• Implementa idempotencia. Si el mismo evento se procesa varias veces, no debería dañar el sistema. Por ejemplo, procesa una transacción solo si su estado aún no está "finalizado".
• Monitorea el ciclo de vida de los mensajes. Configura alertas para los casos en que un evento no llegue al suscriptor en un tiempo razonable.

Ejemplo de código para procesamiento idempotente:

@Service
public class PaymentEventProcessor {

    @Autowired
    private PaymentRepository paymentRepository;

    public void processPaymentEvent(PaymentEvent event) {
        // Comprobamos si el evento ya fue procesado antes
        if (paymentRepository.existsByTransactionId(event.getTransactionId())) {
            // Simplemente lo registramos y salimos
            log.info("El evento con ID {} ya fue procesado", event.getTransactionId());
            return;
        }

        // Procesamos el evento
        Payment payment = new Payment(event.getTransactionId(), event.getAmount());
        paymentRepository.save(payment);
    }
}

Error №3: Detalle excesivo de eventos

En lugar de un solo evento OrderCreated, que contiene toda la info del pedido, generas un montón de eventos pequeños: OrderItemAdded, OrderItemRemoved, OrderAddressChanged y así sucesivamente. Esto puede llevar a un "caos de eventos", donde los suscriptores se ahogan en una miríada de eventos diminutos.

¿Por qué pasa esto?

• Exceso de celo intentando hacer el sistema muy flexible.
• Inexperiencia en diseño de arquitecturas de eventos.

¿Cómo evitarlo?

• Los eventos deben ser de grano grueso. Que cada evento describa una acción completa.
• Refactoriza los eventos. Si ves que tus eventos son demasiado pequeños, únelos en otros más grandes que contengan contexto.

Antipatrón:

class OrderEvents {
    class OrderItemAdded { /* ... */ }
    class OrderItemRemoved { /* ... */ }
    class OrderAddressChanged { /* ... */ }
}

Mejor enfoque:

class OrderCreatedEvent {
    private String orderId;
    private List<OrderItem> items;
    private Address shippingAddress;
    // ¡Toda la información aquí!
}

Error №4: Descuidar la monitorización y el registro de logs

Si no sabes qué pasa con tus eventos, pierdes el control del sistema. Un evento puede atascarse, no llegar al suscriptor o causar un error, y ni siquiera enterarte.

¿Por qué pasa esto?

• Falta de logging centralizado.
• Nivel de monitorización desajustado respecto a la complejidad del sistema.

¿Cómo evitarlo?

• Herramientas para monitorización: el stack ELK (Elasticsearch, Logstash, Kibana), Prometheus, Grafana.
• Trazado distribuido: Usa Spring Sleuth y Zipkin para seguir la ruta de los eventos en el sistema.
• Alertas: Configura alertas para enterarte de problemas en tiempo real.

Ejemplo de configuración de monitorización con Grafana:

1. Configura las métricas en Prometheus.
2. Crea un dashboard en Grafana para métricas como latencia de mensajes, número de eventos por hora, etc.

Error №5: Falta de estrategias para el aumento de carga

El sistema funciona bien con 100 eventos por minuto. ¿Y si pasa a 10 000? ¿O a un millón? Si no consideras el crecimiento de la carga, tu arquitectura puede colapsar bajo su propio peso.

¿Por qué pasa esto?

• Elección incorrecta de herramientas (por ejemplo, usar RabbitMQ en lugar de Kafka para sistemas de alta carga).
• Falta de escalado horizontal.

¿Cómo evitarlo?

• Usa brokers de mensajes adecuados para tus cargas. Kafka maneja millones de mensajes, pero no es ideal para casos que requieren latencias muy bajas.
• Añade particiones. Kafka permite escalar horizontalmente el rendimiento mediante particiones.
• Realiza pruebas de carga. Usa herramientas como Apache JMeter para validar tu arquitectura.

Error №6: Gestión incorrecta del ciclo de vida de los eventos

Tus eventos no deberían quedarse en el sistema para siempre. Si olvidas limpiar mensajes obsoletos o no configuras una policy de retención, podrías encontrarte con un broker lleno.

¿Por qué pasa esto?

• Falta de una política del ciclo de vida de los eventos.
• Configuraciones incorrectas del broker de mensajes.

¿Cómo evitarlo?

• Limpia datos antiguos. Usa la configuración retention.ms en Kafka para eliminar mensajes obsoletos.
• Automatiza procesos. Configura scripts para gestionar el ciclo de vida y la limpieza de datos.

Hemos repasado seis errores principales que pueden surgir al diseñar sistemas orientados a eventos. A pesar de la complejidad del tema, si sigues las recomendaciones propuestas, podrás diseñar sistemas no solo fiables sino también fáciles de escalar.