Kafka en 2023: streaming de eventos en la empresa
Actualizado: 2026-06-20
Apache Kafka[1] ha pasado de ser “el sistema de mensajería en empresas grandes” a ser el backbone de eventos de las arquitecturas modernas. Ha cruzado varios umbrales importantes — entre ellos, la salida completa de ZooKeeper con KRaft[2] — que simplifican la operación y abren nuevos patrones de uso.
Puntos clave
- KRaft (Kafka Raft) integra el consenso dentro de Kafka y elimina la dependencia de ZooKeeper: un solo sistema a operar, arranque más rápido y soporte para millones de particiones por clúster.
- Los tres patrones más consolidados son CDC con Debezium, event sourcing y stream processing con Kafka Streams, ksqlDB o Flink.
- Redpanda (C++, sin JVM ni ZooKeeper) y Pulsar (storage/compute separados) son alternativas reales con momentos distintos.
- Schema evolution, exactly-once cross-topic y consumer rebalancing siguen siendo las áreas más problemáticas.
- La pregunta para proyectos nuevos no es “¿Kafka o no?” sino “¿Kafka, Pulsar, Redpanda o cloud-gestionado?”.
KRaft: adiós a ZooKeeper
Durante más de una década, Kafka dependía de ZooKeeper[3] para coordinar el clúster, gestionar metadata y elegir líderes. Esto significaba dos clústeres para operar, dos tipos de fallos a entender y dos sistemas de backup.
KRaft (Kafka Raft) integra el consenso dentro de Kafka. Las ventajas son:
- Un solo sistema a operar. Un clúster Kafka es, finalmente, un clúster Kafka.
- Startup más rápido. Sin sincronización con ZooKeeper al arrancar.
- Metadata escalable. Kafka en modo KRaft soporta millones de particiones por clúster, frente a ~200k con ZooKeeper.
- Menor huella. Un rol menos significa menos memoria, menos nodos y menos configuración.
En Kafka 3.5 (junio), KRaft es GA para nuevos clústeres. Para clústeres existentes en ZooKeeper, la migración in-place está en beta — aún no recomendada para producción crítica, pero la dirección es clara.
Patrones maduros de uso
Kafka se usa bien en varios patrones distintos. Los más consolidados son:
Change Data Capture (CDC)
Capturar cambios en bases de datos y publicarlos como eventos. Debezium[4] es el estándar de facto, con conectores para PostgreSQL, MySQL, MongoDB, Oracle y SQL Server.
Un patrón típico: replicar tablas de un monolito a servicios nuevos (dual-write pattern), habilitando migración incremental sin cambiar el monolito. La base de datos sigue siendo la fuente de verdad; Kafka distribuye sus cambios.
Event sourcing
Almacenar el historial completo de cambios como eventos inmutables. Cualquier consumidor puede replicar el estado partiendo de los eventos. Patrón poderoso pero exigente: requiere disciplina en el diseño de eventos y en la evolución del schema.
Funciona bien en dominios con trazabilidad obligatoria — auditoría financiera, compliance. Menos adecuado en CRUD general donde el coste cognitivo no se recupera.
Stream processing
Procesamiento continuo sobre flujos con Kafka Streams[5], ksqlDB[6] o Apache Flink[7]. Casos de uso típicos: detección de fraude en tiempo real, enriquecimiento de eventos con datos de referencia, agregaciones continuas para dashboards.
Flink gana cuando hay estado complejo o ventanas temporales sofisticadas. Kafka Streams encaja mejor cuando el pipeline vive “dentro” de Kafka y no se quiere un clúster adicional.
Alternativas que compiten
Tres proyectos que merecen conocerse:
- Apache Pulsar[8]: arquitectura storage/compute separada, multi-tenancy nativo, geo-replicación. Gana en operación a gran escala, pero ecosistema más pequeño.
- Redpanda[9]: reescritura en C++ del protocolo Kafka, sin JVM ni ZooKeeper. Afirma ~10x menor latencia con ~1/6 de hardware. Compatible con clientes Kafka existentes.
- Confluent Cloud[10] / AWS MSK[11]: Kafka gestionado para quien quiere pagar por no operar.
Elegir depende del contexto: para greenfield con requisitos de latencia, Redpanda es atractivo. Para ecosistema maduro y herramientas amplias, Apache Kafka sigue ganando. Para equipos sin cultura operativa de infraestructura, el cloud gestionado.
Qué sigue siendo difícil
Cuatro áreas donde Kafka todavía no ha resuelto bien:
- Schema evolution. Con Avro + Schema Registry funciona, pero los cambios incompatibles siguen requiriendo coordinación humana cuidadosa.
- Exactly-once semantics cross-topic. Los transactional producers funcionan, pero el rendimiento baja significativamente. Muchos equipos aceptan at-least-once + idempotencia en consumidores.
- Consumer rebalancing. En topics con muchas particiones y consumers dinámicos, los rebalances pueden tardar segundos o decenas de segundos.
- Retención fina. Retener datos per-tenant o per-evento es complejo con las políticas de retención de Kafka.
Ver también el análisis de RabbitMQ vs Kafka — decidir qué broker encaja con cada caso sigue siendo una de las decisiones arquitectónicas más importantes. Para la capa de observabilidad sobre Kafka, OpenTelemetry y el stack Grafana son los complementos naturales.
Conclusión
Kafka es infraestructura madura para streaming de eventos a escala empresarial. Con KRaft se simplifica operativamente; con el ecosistema de stream processing consolidado, los patrones de uso están bien documentados. Para proyectos nuevos, la pregunta ya no es “¿Kafka o no?” sino “¿Kafka, Pulsar, Redpanda o cloud-gestionado?”. Cada opción tiene su momento.
