🟧 Apache Kafka — Guía esencial para arquitectura de eventos

Autor: @victormartingil
Enfoque: backend Kotlin + Spring Boot, arquitectura escalable con microservicios

---

🧠 Conceptos fundamentales

Término	Descripción breve
Topic	Canal lógico donde se publican los mensajes.
Partición	Subdivisión del topic para paralelismo. Cada partición mantiene orden interno.
Productor	Componente que publica eventos en un topic.
Consumidor	Componente que suscribe y procesa eventos desde uno o más topics.
Consumer Group	Grupo de consumidores que colaboran para procesar un topic. Cada partición se asigna a un solo miembro del grupo.
Broker	Nodo del clúster Kafka que almacena los mensajes y coordina los consumidores.

---

🧭 Flujo básico

Productor → Topic → Particiones → Consumidores (agrupados por grupo)

---

🧪 Ejemplo de flujo realista

// Evento de dominio
data class UserCreatedEvent(val userId: String, val email: String)

// Productor Spring Boot
kafkaTemplate.send("user.created", userId, event)

Kafka usará hash(userId) % n_particiones para decidir a qué partición enviar el mensaje.

---

👥 Uso de Consumer Groups

• Cada grupo de consumidores (definido por group.id) recibe todos los mensajes del topic una vez.
• Si despliegas múltiples instancias (pods) de un microservicio:
  • Kafka repartirá las particiones entre ellos.
  • Garantiza procesamiento sin duplicados y en paralelo.

Ejemplo:

Partición	Pod asignado
0	notifications-pod-1
1	notifications-pod-2
2	notifications-pod-3

---

🔑 ¿Por qué usar userId como clave de partición?

✅ Ventajas:

Ventaja	Explicación
Orden garantizado por usuario	Eventos del mismo usuario se procesan en orden.
Consistencia en múltiples pods	Todos los eventos de un usuario van al mismo pod (mientras no haya rebalanceo).
Evita condiciones de carrera	Ideal si tienes eventos tipo Create, Update, Notify, etc.

---

🧵 Escenario práctico

Evento: CreateUser(userId="1")
Evento: CreateUser(userId="2")
Evento: CreateUser(userId="3")

Kafka los enviará a particiones distintas (dependiendo del hash) y podrán procesarse en paralelo en diferentes pods del microservicio notifications.

---

☸️ ¿Y si tengo varios pods?

Usar el mismo group.id en todas las instancias del microservicio:

@KafkaListener(
    topics = ["user.created"],
    groupId = "notifications-group"
)
fun consume(event: UserCreatedEvent) {
    // lógica de notificación
}

Así Kafka reparte las particiones automáticamente entre los pods del grupo notifications-group.

---

🧰 Herramienta kafkacat (ahora kcat)

✅ ¿Para qué sirve?

Una herramienta ligera de CLI para:

• Consumir y producir mensajes
• Explorar topics y particiones
• Hacer pruebas sin escribir código

---

🔧 Instalación

# macOS o Linux
brew install kcat

# Debian/Ubuntu
sudo apt install kafkacat

---

📋 Ejemplos prácticos

🔍 Ver metadata del clúster

kcat -b localhost:9092 -L

📤 Producir un mensaje

echo '{"userId":"42","email":"[email protected]"}' \
  | kcat -b localhost:9092 -t user.created -k 42 -P

📥 Consumir mensajes

kcat -b localhost:9092 -t user.created -C -o beginning

🔁 Consumir desde una partición específica

kcat -b localhost:9092 -t user.created -p 0 -C -o beginning

📌 Ver el último mensaje de una partición

kcat -b localhost:9092 -t user.created -p 0 -C -o -1 -c 1

---

📦 Buenas prácticas

Práctica	Motivo
Usar clave de partición (userId)	Mantiene orden y coherencia.
Un topic por tipo de evento, no por consumidor	Desacopla productores y consumidores.
Consumer group por vertical o funcionalidad	Escalabilidad y responsabilidad separada.
Mantener pocos temas, bien definidos	Facilita mantenimiento y documentación.
No compartir consumidores entre microservicios	Separación clara de responsabilidades.

---

📘 Conclusión

Kafka es una herramienta poderosa para sistemas basados en eventos. Usar correctamente los topics, consumer groups, partitions y claves como userId te permite construir una arquitectura escalable, ordenada y resiliente.

Además, kafkacat te permite inspeccionar y probar fácilmente tus topics sin escribir una línea de código.

---

¿Tienes más microservicios que interactúan entre sí mediante eventos? Considera aplicar patrones como Event Sourcing, Outbox, o Choreography con Kafka.