Kafka: mensajería asíncrona y patrones de integración

KafkaTemplate y @KafkaListener sobre el mismo contenedor didáctico: productores, consumidores, fan-out, Dead Letter Topic, y por qué particiones/offsets/consumer groups se enseñan por lectura.

13 aulas · 7 horas de práctica · en el navegador, sin instalar nada

Temario

  1. Por qué mensajería asíncrona: el problema que resuelve — Un PedidosService que llama directo a Inventario, Facturación y Notificaciones queda acoplado a las tres (agregar un paso nuevo obliga a editar este método) y encadenado en el tiempo (el cliente espera a que las tres terminen). Kafka resuelve ambas cosas — y la aclaración honesta de que este simulador solo puede mostrar UNA de las dos.
  2. Primer productor/consumidor: KafkaTemplate y @KafkaListener — kafkaTemplate.send(topico, mensaje) publica; @KafkaListener(topics = "mismo-topico") consume. Ninguno de los dos conoce al otro por clase, solo por el nombre del tópico — y en este motor, send() ejecuta el listener EN LA MISMA LLAMADA.
  3. Mensajes estructurados: un record como mensaje — El mensaje de un tópico no tiene por qué ser un String: un record se serializa del lado del productor y se deserializa automáticamente del lado del @KafkaListener, con el mismo límite ya conocido de @RequestBody (un nivel, tipos simples).
  4. Fan-out: dos listeners sobre el mismo tópico — Varios @KafkaListener pueden suscribirse al MISMO tópico: los dos reciben una copia del mismo mensaje, sin conocerse entre sí ni conocer al productor. Es el mismo patrón pub/sub que SNS→SQS en java-cloud, ahora con Kafka.
  5. Varios tópicos: cada tipo de evento, su propio canal — Un mismo productor puede publicar a distintos tópicos según el TIPO de evento (pedido creado, pago recibido, envío despachado) — cada tópico es completamente independiente: un mensaje a "pagos" nunca le llega a un listener de "pedidos".
  6. Manejo de errores: cuando un listener falla, y el Dead Letter Topic — Si un @KafkaListener lanza una excepción, el productor NUNCA se entera (send()/enviar() no explota) — el mensaje se redirige a <topico>.DLT, un tópico más, como cualquier otro, al que podés suscribir un listener para loggear o alertar.
  7. Taller — Sistema de pedidos: fan-out y Dead Letter Topic — Un sistema con dos tópicos: "pedidos" con fan-out (inventario y facturación reaccionan al mismo evento) y "pagos" con manejo de errores (un monto inválido se redirige a pagos.DLT en vez de romper nada).
  8. Particiones y orden (conceptual): qué garantiza Kafka real, y qué no — Un tópico de Kafka real se divide en particiones — logs ordenados independientes. Kafka garantiza orden DENTRO de una partición, nunca ENTRE particiones distintas; la partición de un mensaje se elige, típicamente, por una key. 100% conceptual: este simulador no tiene particiones reales.
  9. Consumer groups y offsets (conceptual): balancear carga y "retomar donde quedó" — Un consumer group reparte las particiones de un tópico entre varias instancias para balancear carga (a diferencia del fan-out, donde CADA listener recibe todo). Un offset marca hasta dónde leyó un grupo — y por qué, si se reprocesa un mensaje tras una falla, el consumidor tiene que ser idempotente. 100% conceptual, con un ejercicio ejecutable sobre esa última consecuencia.
  10. Patrones de integración (EIP) I: publish/subscribe contra point-to-point — Dos formas de usar un tópico: publish/subscribe (un evento, cualquier cantidad de interesados — el fan-out de la aula 4) contra point-to-point (un comando, UN responsable concreto que lo ejecuta). La diferencia es de DISEÑO e intención, no algo que el motor imponga.
  11. Patrones de integración (EIP) II: Saga por coreografía — Una Saga coordina una transacción de negocio que cruza varios servicios SIN un orquestador central: cada servicio reacciona al evento del anterior y publica el suyo. Un listener que también produce es la pieza clave — y en este simulador síncrono, la cadena entera corre en una sola llamada.
  12. Taller — Coreografía de un viaje, con compensación si falla — Una Saga por coreografía de punta a punta: vuelo reservado → hotel reservado → viaje confirmado. Si el hotel no tiene lugar, el fallo se redirige a su DLT, y desde ahí se publica una transacción de COMPENSACIÓN (cancelar el vuelo) — la pieza que la aula 10 dejó pendiente para este taller.
  13. Cierre: diseñar un sistema completo con eventos, DLT y cadenas — Un solo sistema que junta todo el curso: un evento (pedido creado) dispara una cadena de dos pasos (reservar stock, facturar), y si el primer paso falla (sin stock suficiente), la cadena se corta ahí, sin facturar nada, y el fallo se contiene en un DLT con su propia alerta.

Es parte de