Apache Kafka es una plataforma distribuida de transmisión de eventos que permite publicar, almacenar, leer y procesar datos a medida que se producen. Se utiliza para conectar aplicaciones, crear pipelines de datos, sincronizar sistemas y reaccionar ante operaciones que suceden continuamente.
Un evento puede representar una compra, un clic, un pago, una modificación de inventario, una ubicación, una lectura de un sensor o un cambio realizado por un usuario. Kafka recibe esos eventos, los organiza y los conserva para que uno o varios sistemas puedan procesarlos.
La diferencia frente a una integración tradicional es importante. En lugar de conectar cada aplicación directamente con todas las demás, los productores publican eventos en Kafka y los consumidores leen únicamente los flujos que necesitan. Esto reduce parte del acoplamiento y permite añadir nuevos usos sin modificar constantemente el sistema que origina los datos.
Por ejemplo, cuando un ecommerce confirma un pedido puede publicar un evento. El sistema de inventario lo utiliza para reservar productos, la plataforma logística prepara el envío, el sistema de analítica actualiza sus métricas y el servicio de email envía la confirmación. Todos reaccionan al mismo hecho sin necesidad de que el componente de pedidos implemente cada proceso.
Kafka no es simplemente una cola de mensajes, una base de datos o una herramienta de Big Data. Comparte características con esas tecnologías, pero su modelo está orientado a mantener registros ordenados de eventos que pueden ser leídos por diferentes consumidores a velocidades distintas.
En Aula CM utilizamos este tipo de arquitectura para explicar una idea habitual en proyectos de datos: un evento no debería quedar limitado al sistema que lo produce. Si se modela, conserva y distribuye correctamente, puede alimentar operaciones, analítica, automatizaciones, alertas y modelos de inteligencia artificial.
Qué Es Kafka
Kafka es un sistema distribuido diseñado para trabajar con flujos continuos de eventos. Distribuido significa que puede ejecutarse en varias máquinas coordinadas, repartir los datos entre ellas y continuar funcionando cuando algunos componentes fallan, siempre que la arquitectura esté correctamente dimensionada y configurada.
Los eventos se almacenan dentro de categorías llamadas topics. Las aplicaciones que generan información se denominan productores. Las que la leen son consumidores. Los servidores que almacenan y entregan los eventos reciben el nombre de brokers.
Esta organización permite desacoplar origen y destino. El productor no necesita conocer todos los sistemas que utilizarán su información. Publica el evento en el topic correspondiente y continúa con su trabajo.
Los consumidores tampoco necesitan estar activos en el mismo instante en que se publica el evento. Kafka puede conservar la información durante el periodo definido para que sea leída posteriormente.
Esta persistencia permite repetir procesos. Si una empresa desarrolla un nuevo modelo analítico, puede volver a leer eventos ya almacenados en lugar de esperar a que vuelvan a producirse.
Aquí nos referimos exclusivamente a Apache Kafka como tecnología. No debe confundirse con Franz Kafka, el escritor autor de obras como La metamorfosis.
Qué Es Apache Kafka
Apache Kafka es el proyecto open source mantenido dentro de la Apache Software Foundation. Proporciona el servidor distribuido, protocolos, clientes y componentes necesarios para crear una plataforma de event streaming.
El nombre completo ayuda a diferenciar el proyecto de productos, servicios gestionados y plataformas comerciales construidas alrededor de él. Apache Kafka es la tecnología base; proveedores como Confluent, Amazon, Google, Microsoft y otras empresas ofrecen servicios o herramientas relacionadas.
Una instalación puede ejecutarse en infraestructura propia, máquinas virtuales, contenedores, Kubernetes o un servicio cloud. La elección no cambia sus conceptos fundamentales, pero sí las responsabilidades operativas del equipo.
En un entorno autogestionado, la organización debe configurar capacidad, almacenamiento, seguridad, actualizaciones, monitorización y recuperación. En un servicio administrado, parte de estas tareas se delega, aunque siguen siendo necesarias decisiones sobre topics, particiones, consumidores, esquemas y costes.
Apache Kafka se ejecuta sobre la máquina virtual de Java y dispone de clientes para distintos lenguajes. Kafka Streams, una de sus bibliotecas principales, está orientada especialmente a aplicaciones Java y Scala.
Para Qué Sirve Kafka
Kafka sirve para transportar y almacenar eventos entre sistemas de forma escalable. Resulta especialmente útil cuando varias aplicaciones necesitan reaccionar a datos que se generan continuamente.
Entre sus usos habituales se encuentran:
- Integración entre aplicaciones.
- Pipelines de datos en tiempo real.
- Arquitecturas de microservicios.
- Procesamiento de eventos.
- Sincronización de bases de datos.
- Analítica de comportamiento.
- Monitorización y observabilidad.
- Detección de fraude.
- Gestión de pedidos e inventario.
- Procesamiento de datos IoT.
- Actualización de buscadores.
- Alimentación de data lakes y warehouses.
- Creación de modelos y variables para inteligencia artificial.
Imaginemos una aplicación de movilidad que recibe ubicaciones de miles de vehículos. Kafka puede almacenar los eventos y distribuirlos a sistemas de seguimiento, cálculo de rutas, alertas, facturación y análisis histórico.
En una entidad financiera, cada operación puede convertirse en un evento. Un consumidor registra la transacción, otro actualiza el saldo disponible, otro aplica reglas antifraude y otro genera información agregada.
El sistema no resuelve automáticamente la lógica de cada proceso. Su función es ofrecer una infraestructura para que los eventos lleguen de forma ordenada y controlada a los componentes que los necesitan.
Qué Problema Resuelve Kafka
Kafka resuelve principalmente el problema de mover grandes volúmenes de eventos entre sistemas sin crear una red de integraciones directas difícil de mantener.
En una arquitectura punto a punto, una aplicación puede enviar datos directamente a un CRM, una plataforma de analítica, una base de datos y un sistema de notificaciones. Cuando aparece un nuevo destino, hay que modificar el origen o crear otra integración.
Con Kafka, la aplicación publica un evento una vez. Los destinos se suscriben y procesan el flujo según sus necesidades. Añadir un nuevo consumidor no obliga necesariamente a cambiar el productor.
También resuelve diferencias de velocidad. Un productor puede generar datos rápidamente mientras un consumidor procesa más despacio. Kafka conserva temporalmente los eventos y permite que el consumidor avance a su ritmo.
Otro problema es la repetición. En una integración que entrega el dato una sola vez, reconstruir un sistema puede resultar complicado. En Kafka, un consumidor puede reposicionar su offset y volver a procesar eventos todavía disponibles.
Esta capacidad exige planificación. Si la retención es demasiado corta, los datos necesarios pueden haber sido eliminados. Si se conserva todo sin límites, aumentan almacenamiento y costes.
Cómo Funciona Kafka
Kafka funciona mediante productores que envían eventos a topics alojados en un clúster de brokers. Los consumers se conectan al clúster y leen esos eventos.
El flujo básico es el siguiente:
- Una aplicación detecta un hecho relevante.
- Construye un evento con los datos necesarios.
- El productor lo envía a un topic.
- Kafka determina en qué partición debe almacenarlo.
- El broker líder de esa partición registra el evento.
- Las réplicas copian la información.
- Uno o varios consumidores leen el evento.
- Cada consumidor ejecuta su lógica.
- El progreso queda representado mediante offsets.
Supongamos que un usuario completa una compra. El productor puede enviar un evento denominado PedidoConfirmado con el identificador, el cliente, las líneas, el importe y la fecha.
El sistema de almacén lee el evento y reserva unidades. El de comunicación prepara un email. El de analítica registra una conversión. Cada consumidor mantiene su propio progreso y puede procesar el evento de manera independiente.
Kafka no obliga a utilizar un formato específico para el contenido, pero una organización debe establecer contratos claros. JSON puede resultar cómodo, mientras que Avro, Protocol Buffers u otros formatos ofrecen estructuras más controladas.
El funcionamiento real incluye confirmaciones, reintentos, replicación, rebalances y posibles errores. Diseñar únicamente el recorrido ideal produce sistemas que fallan ante interrupciones normales.
Arquitectura de Apache Kafka
La arquitectura de Kafka se apoya en varios conceptos que trabajan juntos: eventos, topics, particiones, brokers, productores, consumidores, grupos, offsets, réplicas y controladores.
Cada elemento resuelve una parte del problema. Los topics organizan los eventos. Las particiones aportan paralelismo. Los brokers almacenan datos. Los grupos reparten trabajo. Los offsets registran el progreso.
Comprender únicamente productores y consumidores no es suficiente para administrar una plataforma. Las decisiones sobre particionamiento, claves, retención y replicación afectan directamente a orden, capacidad y recuperación.
En una revisión profesional solemos empezar por el flujo de negocio. Identificamos qué produce cada evento, qué sistemas lo consumen, qué orden necesitan y qué ocurriría si se procesa dos veces.
Después traducimos esas necesidades a elementos técnicos. La arquitectura debería reflejar el negocio, no limitarse a crear topics con nombres genéricos y configuraciones idénticas.
Qué Es un Evento en Kafka
Un evento es un registro que representa algo que ha ocurrido. Puede incluir una clave, un valor, una marca temporal, cabeceras y metadatos técnicos.
La clave ayuda a decidir la partición y a relacionar eventos. Si los eventos de un mismo pedido utilizan el identificador como clave, pueden enviarse a la misma partición y mantener el orden relativo.
El valor contiene la información principal. No debería incluir datos innecesarios por comodidad, especialmente si existen datos personales o sensibles.
Las cabeceras permiten añadir contexto, como identificadores de correlación, versión, origen o información de trazabilidad.
Un buen evento describe un hecho pasado. PedidoConfirmado expresa algo ocurrido. ConfirmarPedido se parece más a una orden o comando. Diferenciar ambos conceptos evita confundir hechos con solicitudes.
Qué Es un Topic en Kafka
Un topic es una categoría lógica en la que se publican eventos relacionados. Puede compararse de forma simplificada con un registro o canal, aunque su comportamiento es distinto al de una carpeta o una tabla convencional.
Un topic podría contener pedidos confirmados, cambios de precios, clics, movimientos de inventario o eventos de facturación.
Los nombres deben comunicar significado y contexto. Un topic llamado datos o eventos no ayuda a saber qué contiene, quién lo produce ni qué contrato utiliza.
También conviene distinguir entre topics de negocio y técnicos. Un evento PedidoEnviado representa un hecho del dominio; un topic de reintentos o errores cumple una función operativa.
Crear un topic por cada pequeña acción puede generar una arquitectura difícil de administrar. Agrupar todos los eventos en uno solo también complica permisos, retención y consumo. La decisión necesita equilibrio.
Qué Es una Partición
Una partición es una división ordenada de un topic. Cada evento almacenado dentro de ella recibe una posición denominada offset.
Las particiones permiten distribuir los datos entre brokers y procesar varias secuencias en paralelo. Un topic con varias particiones puede ser consumido simultáneamente por varios miembros de un grupo.
El orden está garantizado dentro de cada partición, no entre todas las particiones del topic. Esta característica debe considerarse al diseñar la clave.
Si una cuenta bancaria necesita procesar sus movimientos en orden, los eventos de esa cuenta deberían utilizar una clave que los dirija a la misma partición.
Aumentar particiones mejora capacidad en determinados escenarios, pero también aumenta metadatos, archivos, réplicas y operaciones de coordinación. No conviene elegir un número arbitrariamente elevado.
Qué Es un Broker de Kafka
Un broker es un servidor de Kafka encargado de recibir, almacenar y entregar eventos. Un clúster normalmente contiene varios brokers para repartir datos y tolerar fallos.
Cada broker aloja particiones de diferentes topics. Para una partición concreta, uno de ellos actúa como líder y otros pueden mantener réplicas.
Los clientes se conectan inicialmente a uno o varios brokers conocidos como puntos de arranque. Después obtienen metadatos para saber dónde se encuentra cada partición.
Un broker no debe confundirse con todo el clúster. La plataforma completa puede continuar operando aunque un servidor falle, siempre que existan réplicas disponibles y la configuración lo permita.
El dimensionamiento de un broker depende de red, disco, memoria, número de particiones, volumen, retención y patrón de consumo. Analizar únicamente CPU ofrece una visión incompleta.
Qué Es un Clúster de Kafka
Un clúster es el conjunto de brokers y controladores que trabajan coordinadamente. Distribuye las particiones, mantiene metadatos y gestiona el funcionamiento global.
La arquitectura distribuida permite ampliar capacidad incorporando nodos, aunque la ampliación no redistribuye automáticamente todos los datos de la forma más conveniente sin planificación.
El clúster necesita una estrategia de disponibilidad. Colocar todos los brokers en la misma máquina física o zona elimina parte de la tolerancia que sugiere el número de réplicas.
En cloud, las réplicas pueden distribuirse entre zonas. Esta decisión mejora resiliencia, pero aumenta tráfico y costes.
Qué Es un Productor de Kafka
Un producer es la aplicación cliente que publica eventos. Decide el topic, construye el registro y puede proporcionar una clave.
El productor agrupa eventos, comprime lotes y envía peticiones a los brokers. Sus configuraciones afectan a latencia, rendimiento y garantías.
Puede esperar distintas confirmaciones antes de considerar completado el envío. Exigir mayor confirmación mejora durabilidad, aunque puede aumentar latencia.
También debe gestionar reintentos. Un fallo temporal no significa necesariamente que el evento no se haya almacenado. Sin idempotencia o identificadores adecuados, un reintento puede producir duplicados.
La aplicación productora debe validar su evento antes de publicarlo. Kafka no puede saber si un importe negativo o una dirección incompleta son válidos para el negocio.
Qué Es un Consumidor de Kafka
Un consumer es una aplicación que lee eventos de uno o varios topics. Kafka no ejecuta la lógica de negocio del consumidor; únicamente le proporciona los registros correspondientes.
El consumidor solicita datos mediante un modelo de lectura. Esto le permite controlar su ritmo, procesar lotes y gestionar el progreso.
Después de leer un evento puede actualizar una base de datos, llamar a un servicio, generar otro evento o realizar un cálculo.
Un consumidor debe estar preparado para reinicios, reintentos y duplicados. Su lógica necesita ser idempotente cuando la operación pueda ejecutarse más de una vez.
También debe decidir qué hacer ante un registro inválido. Bloquear indefinidamente toda la partición por un único evento puede detener el flujo completo.
Qué Es un Consumer Group
Un consumer group es un conjunto de consumidores que colaboran para procesar un topic. Dentro de un mismo grupo, cada partición activa se asigna a un único consumidor.
Si existen cuatro particiones y dos consumidores, cada uno puede procesar dos. Si se añaden dos consumidores más, el trabajo puede repartirse entre cuatro.
Si hay más consumidores que particiones, algunos quedan sin asignación. Por eso el número de particiones limita el paralelismo máximo de un grupo para ese topic.
Dos grupos diferentes pueden leer los mismos eventos de forma independiente. Un grupo de facturación y otro de analítica mantienen offsets separados.
Cuando entran o salen consumidores se produce un rebalanceo. Durante esta operación cambian las asignaciones y puede interrumpirse temporalmente el procesamiento.
Qué Es un Offset en Kafka
El offset es la posición de un evento dentro de una partición. Permite identificar el orden y registrar hasta dónde ha avanzado un consumidor.
Los offsets son independientes por partición. Un mismo número puede existir en distintas particiones sin referirse al mismo evento.
El consumidor puede confirmar su progreso automáticamente o de manera controlada. Confirmar antes de completar la operación puede provocar pérdida lógica si el proceso falla. Confirmar después puede generar reprocesamiento.
No existe una estrategia universal. La elección depende de las garantías, el coste de repetir y la naturaleza de la operación.
Reiniciar offsets permite volver a procesar datos. Esta capacidad resulta útil para reconstruir vistas, corregir lógica o alimentar un nuevo sistema.
Replicación y Tolerancia a Fallos en Kafka
Kafka replica las particiones entre brokers para reducir el impacto de la pérdida de un nodo. Cada partición tiene una réplica líder y puede disponer de réplicas seguidoras.
Los productores y consumidores trabajan normalmente con el líder. Las réplicas mantienen copias y pueden asumir el liderazgo cuando se produce un fallo.
El factor de replicación indica cuántas copias existen. Un valor de tres significa que la partición puede estar almacenada en tres brokers, siempre que el clúster disponga de nodos suficientes.
La replicación no sustituye todas las copias de seguridad. Un borrado accidental, una configuración incorrecta o un evento corrupto puede replicarse en todos los nodos.
También es necesario considerar la ubicación. Tres copias dentro de la misma máquina física no protegen ante una pérdida completa de ese equipo.
Líderes, Réplicas e ISR
El líder gestiona las operaciones de lectura y escritura de una partición. Las réplicas seguidoras copian los datos.
El conjunto ISR agrupa las réplicas que permanecen suficientemente sincronizadas. Si el líder falla, una réplica elegible puede asumir su función.
Un número creciente de réplicas fuera de sincronización puede indicar problemas de red, disco o capacidad. La plataforma puede seguir funcionando y estar perdiendo margen de seguridad.
Por eso la monitorización no debe limitarse a comprobar si el puerto responde. La salud incluye replicación, latencia, errores y almacenamiento.
Retención de Datos en Kafka
Kafka puede conservar eventos durante un tiempo o hasta alcanzar un tamaño determinado. El hecho de que un consumidor lea un registro no provoca automáticamente su eliminación.
Esta característica diferencia Kafka de muchas colas tradicionales. Varios consumidores pueden leer el mismo evento y un consumidor puede volver a procesarlo mientras siga disponible.
La política de retención debe considerar:
- Necesidad de reprocesamiento.
- Volumen diario.
- Capacidad de almacenamiento.
- Requisitos legales.
- Datos personales.
- Coste.
- Tiempo máximo de indisponibilidad de consumidores.
Si un consumidor permanece detenido más tiempo que la retención, puede perder los eventos que no llegó a procesar.
Conservar datos indefinidamente tampoco debería ser la opción por defecto. Puede incumplir políticas de privacidad o generar un crecimiento innecesario.
Log Compaction
La compactación conserva al menos el valor más reciente conocido para cada clave, en lugar de mantener únicamente una ventana temporal.
Resulta útil para representar estados actualizables. Un topic puede contener cambios de configuración o la última información de cada producto.
La compactación no elimina inmediatamente todos los valores anteriores ni convierte Kafka en una tabla convencional. Es un proceso que se ejecuta según sus propias condiciones.
Los registros especiales de borrado permiten indicar que una clave debe eliminarse durante la compactación.
Un diseño correcto necesita claves estables. Si la misma entidad utiliza claves diferentes, Kafka no puede relacionar sus versiones.
Orden de los Mensajes en Kafka
Kafka mantiene el orden dentro de una partición. No ofrece un orden total entre todas las particiones de un topic.
Esta distinción afecta a procesos donde la secuencia es importante. Si un pedido pasa por creado, pagado y cancelado, procesar los eventos fuera de orden puede generar un estado incorrecto.
Utilizar el identificador del pedido como clave ayuda a enviar sus eventos a la misma partición. Otros pedidos pueden procesarse en paralelo.
Exigir un orden global obligaría a utilizar una única partición o a introducir coordinación adicional, reduciendo el paralelismo. Por eso debemos definir el ámbito real del orden.
En muchos casos no necesitamos ordenar todos los eventos del negocio, sino únicamente los de una entidad concreta.
También pueden existir eventos retrasados por sistemas externos. El orden de llegada no siempre coincide con la hora real en que ocurrió el hecho. Las aplicaciones de procesamiento temporal deben distinguir ambos conceptos.
Garantías de Entrega en Kafka
Los sistemas de eventos suelen describir sus garantías como at-most-once, at-least-once o exactly-once. Estas expresiones deben interpretarse dentro de un alcance concreto.
At-Most-Once
Un evento se procesa como máximo una vez, pero puede perderse si ocurre un fallo antes de completar la operación.
Puede ser aceptable para métricas no críticas donde la velocidad importa más que una precisión absoluta.
At-Least-Once
El sistema intenta evitar pérdidas, aunque un evento puede procesarse más de una vez. Es una estrategia habitual porque los duplicados pueden controlarse mediante idempotencia.
Si una operación crea un pago, repetirla sin protección es peligroso. El consumidor necesita un identificador que permita reconocer que ya fue ejecutada.
Exactly-Once
Kafka ofrece mecanismos de productores idempotentes, transacciones y procesamiento exactamente una vez dentro de determinados flujos.
No debemos traducir esta capacidad como una garantía automática sobre cualquier base de datos, API o sistema externo. Cuando la operación sale de Kafka, se necesitan patrones adicionales.
Kafka Streams puede coordinar lecturas, estado y escrituras en Kafka con garantías avanzadas. Una llamada a un proveedor de pagos continúa requiriendo idempotencia propia.
Qué Es KRaft en Kafka
KRaft es el mecanismo utilizado por las versiones actuales de Apache Kafka para gestionar los metadatos y la coordinación del clúster mediante un quorum de controladores basado en Raft.
Los metadatos incluyen información sobre brokers, topics, particiones, réplicas, configuraciones y liderazgo. Sin ellos, los componentes no sabrían dónde se encuentran los datos ni cómo está organizada la plataforma.
Kafka 4.x utiliza KRaft y ya no depende de ZooKeeper. Esta evolución simplifica la arquitectura al eliminar un sistema externo que anteriormente era necesario para la coordinación.
Los controladores participan en un quorum. Uno actúa como líder y los demás mantienen el estado necesario para asumir la función ante un fallo.
El diseño de esta capa requiere alta disponibilidad. Utilizar un único controlador en producción elimina la tolerancia ante su pérdida.
Qué Es ZooKeeper en Kafka
ZooKeeper fue el sistema utilizado históricamente por Kafka para almacenar metadatos, coordinar brokers y participar en procesos como la elección del controlador.
Las arquitecturas antiguas necesitaban operar dos sistemas distribuidos: Kafka y el conjunto de ZooKeeper. Esto añadía configuración, monitorización y procedimientos de recuperación.
En las ramas actuales de Kafka, ZooKeeper ha sido sustituido por KRaft. Los clústeres heredados necesitan seguir un procedimiento de migración compatible antes de actualizar a versiones que ya no admiten el modo anterior.
No conviene eliminar ZooKeeper directamente de un clúster antiguo. La migración de metadatos debe seguir la documentación correspondiente a la versión de origen y a la versión puente.
En proyectos nuevos no tiene sentido diseñar la arquitectura alrededor de ZooKeeper. Su presencia suele indicar una instalación heredada o documentación desactualizada.
Qué Es Kafka Connect
Kafka Connect es el componente destinado a mover datos entre Kafka y sistemas externos mediante conectores reutilizables.
Un source connector introduce información en Kafka. Puede capturar cambios de una base de datos, leer archivos o recibir datos de otra plataforma.
Un sink connector extrae eventos y los envía a un destino, como un buscador, un almacén analítico, un data lake o una base de datos.
Kafka Connect evita desarrollar una aplicación específica para cada integración cuando ya existe un conector adecuado. También proporciona gestión de tareas, distribución, offsets y configuración.
Esto no significa que cualquier conector pueda instalarse sin revisión. Debemos comprobar mantenimiento, licencia, compatibilidad, seguridad y comportamiento ante errores.
En una integración profesional conviene definir:
- Sistema de origen y destino.
- Formato de los eventos.
- Frecuencia o modo de captura.
- Transformaciones necesarias.
- Tratamiento de errores.
- Reintentos.
- Credenciales.
- Monitorización.
Qué Es Schema Registry en Kafka
Un Schema Registry es un servicio utilizado para registrar, versionar y validar los esquemas de los eventos. No forma parte obligatoria del núcleo de Apache Kafka, pero se utiliza con frecuencia en arquitecturas profesionales.
El esquema define qué campos existen, qué tipos utilizan y cuáles son opcionales. Esto crea un contrato entre productores y consumidores.
Sin control de esquemas, un productor puede cambiar un campo y romper varios consumidores sin saberlo. Por ejemplo, sustituir un identificador numérico por un texto puede impedir deserializar eventos antiguos.
El registro puede aplicar reglas de compatibilidad. Una evolución backward compatible permite que nuevos consumidores continúen leyendo datos producidos con versiones anteriores, según el formato y la modificación realizada.
Entre las tecnologías habituales se encuentran soluciones asociadas a Confluent, Apicurio y otros proyectos. La elección debe considerar formato, integración y modelo de gobierno.
El esquema no sustituye la semántica. Un campo llamado total puede ser técnicamente decimal y continuar siendo ambiguo si no se indica moneda, impuestos o descuentos.
Qué Es Kafka Streams
Kafka Streams es una biblioteca para crear aplicaciones que consumen, transforman y producen datos almacenados en Kafka. Se integra dentro de aplicaciones Java o Scala sin necesitar un clúster de procesamiento independiente.
Permite realizar operaciones como:
- Filtrar eventos.
- Transformar valores.
- Agrupar por clave.
- Calcular agregaciones.
- Unir flujos.
- Trabajar con ventanas temporales.
- Mantener estado local.
- Generar nuevos topics.
Imaginemos un flujo de compras. Una aplicación Streams puede agrupar el importe por categoría durante ventanas de cinco minutos y publicar métricas actualizadas.
Otro proceso puede unir eventos de pedidos con información de clientes para enriquecerlos antes de enviarlos a un sistema analítico.
La biblioteca utiliza las particiones de Kafka para escalar. Varias instancias de la aplicación pueden formar un grupo y repartirse tareas.
Kafka Streams no es lo mismo que Kafka. Kafka es la plataforma de eventos; Streams es una biblioteca construida para procesar los datos almacenados en ella.
Procesamiento con Estado en Kafka Streams
Algunas operaciones pueden procesar cada evento de forma independiente. Otras necesitan recordar información anterior, como un total acumulado, una ventana o la última versión de una entidad.
Kafka Streams mantiene almacenes de estado locales y utiliza topics internos para reconstruirlos cuando una instancia falla o una tarea cambia de ubicación.
Este modelo permite realizar agregaciones y joins, pero introduce requisitos de almacenamiento, recuperación y monitorización.
Una aplicación puede parecer recuperada porque el proceso está activo y continuar reconstruyendo su estado durante un periodo significativo.
El dimensionamiento debe contemplar el volumen de estado, la tasa de cambios y el tiempo aceptable de restauración.
En proyectos relacionados con analítica e inteligencia artificial, los flujos con estado pueden calcular variables recientes, detectar patrones y preparar datos para decisiones automáticas. En el curso de Inteligencia Artificial avanzada insistimos en que la calidad de estos sistemas depende tanto del modelo como de la fiabilidad de los datos que lo alimentan.
Qué Es Kafka en Programación
En programación, Kafka es una infraestructura con la que se comunican aplicaciones productoras y consumidoras mediante clientes.
El desarrollador define los eventos, configura la conexión y decide cómo tratar confirmaciones, errores, serialización, reintentos y offsets.
Los clientes oficiales y comunitarios permiten trabajar desde Java, Scala, Python, Go, .NET, JavaScript y otros lenguajes. Las capacidades exactas pueden variar entre implementaciones.
Integrar Kafka no consiste únicamente en añadir una dependencia y publicar cadenas. El código debe resolver:
- Configuración de brokers.
- Seguridad.
- Serialización.
- Claves.
- Confirmaciones.
- Reintentos.
- Errores.
- Observabilidad.
- Cierre ordenado.
- Pruebas.
La arquitectura también necesita definir quién es responsable del contrato. Si varios equipos modifican eventos sin coordinación, la plataforma distribuye incompatibilidades con gran eficiencia.
Kafka con Java
Java es uno de los lenguajes más utilizados con Kafka. El proyecto ofrece APIs para producir, consumir, administrar y procesar eventos.
Una aplicación Java puede crear un producer compartido, construir registros y enviarlos de forma asíncrona. Los consumidores se ejecutan habitualmente dentro de un bucle de lectura controlado.
El consumer no es un objeto que deba compartirse libremente entre hilos. Su modelo de concurrencia necesita respetar las garantías del cliente utilizado.
En una aplicación empresarial también debemos gestionar el ciclo de vida. El proceso necesita dejar de aceptar trabajo, completar operaciones, confirmar progreso y cerrar conexiones durante un despliegue.
Una parada abrupta puede provocar reprocesamientos, aunque no debería causar pérdida si la estrategia de confirmación está correctamente diseñada.
Kafka con Spring Boot
Spring Boot puede integrarse con Kafka mediante proyectos del ecosistema Spring. Estas herramientas reducen código repetitivo relacionado con configuración, listeners, serialización y plantillas de envío.
Una anotación puede facilitar la creación de un consumidor, pero no decide la estrategia de negocio. El equipo continúa siendo responsable de concurrencia, idempotencia, errores y contratos.
En proyectos reales aparecen problemas cuando se confía demasiado en valores predeterminados. Una configuración válida para desarrollo puede no ser adecuada para producción.
Conviene revisar:
- Número de consumidores.
- Modo de confirmación.
- Deserialización.
- Reintentos.
- Dead-letter topics.
- Transacciones.
- Timeouts.
- Métricas.
También debemos comprobar la compatibilidad entre la versión del framework, los clientes y el clúster.
Qué Es Kafka en Big Data
En Big Data, Kafka funciona como una capa de ingestión y distribución de eventos. Recibe información de múltiples fuentes y la entrega a sistemas de procesamiento o almacenamiento.
Puede conectar aplicaciones con data lakes, warehouses, motores de streaming, buscadores y plataformas de machine learning.
Un pipeline podría funcionar así:
- Las aplicaciones publican actividad.
- Kafka conserva los eventos.
- Un proceso valida y transforma.
- Los datos se envían al almacén analítico.
- Otro consumidor calcula indicadores en tiempo real.
- Un tercer sistema genera alertas.
Kafka no sustituye necesariamente el almacenamiento analítico. Mantiene eventos y facilita su movimiento, mientras un warehouse está optimizado para consultas y agregaciones de negocio.
La arquitectura debe decidir qué información se conserva en Kafka, durante cuánto tiempo y qué sistema actúa como fuente histórica.
En proyectos de analítica digital, esta distinción resulta importante. Recoger eventos no garantiza disponer de métricas fiables. Se necesitan definiciones, calidad, identidad, consentimiento y modelos de datos consistentes.
Kafka en Arquitecturas de Microservicios
Kafka se utiliza para comunicar microservicios mediante eventos. Un servicio publica un hecho y otros reaccionan sin una llamada directa obligatoria.
Esta comunicación asíncrona reduce dependencias temporales. El productor no necesita esperar a que todos los consumidores terminen.
También introduce consistencia eventual. Los sistemas no actualizan necesariamente su estado al mismo tiempo, por lo que la experiencia debe tolerar pequeños retrasos.
Un error frecuente consiste en sustituir todas las llamadas síncronas por Kafka. Algunas operaciones necesitan una respuesta inmediata, como validar una credencial o calcular un precio antes de confirmar una compra.
Una arquitectura puede combinar APIs síncronas y eventos. La elección depende de si el origen necesita una respuesta para continuar.
Event-Driven Architecture
Una arquitectura orientada a eventos organiza la comunicación alrededor de hechos relevantes. Los servicios reaccionan cuando esos hechos se publican.
Este enfoque facilita extensibilidad, pero necesita una disciplina sólida sobre nombres, esquemas, versiones y responsabilidad.
También requiere observabilidad distribuida. Un proceso puede atravesar varios consumidores y topics antes de completarse.
Los identificadores de correlación ayudan a reconstruir el recorrido y localizar dónde se produjo un retraso.
Patrón Outbox
El patrón outbox evita el problema de actualizar una base de datos y publicar un evento como dos operaciones independientes.
La aplicación guarda el cambio de negocio y el evento pendiente dentro de la misma transacción local. Otro proceso publica posteriormente ese evento en Kafka.
Así se reduce el riesgo de confirmar el pedido sin publicar el evento o publicar el evento cuando la transacción terminó fallando.
La tabla outbox necesita limpieza, monitorización y una estrategia de identificadores. No es un mecanismo completamente automático.
Ejemplo de Kafka en un Ecommerce
Imaginemos un ecommerce con catálogo, pagos, inventario, logística, CRM y analítica. Sin una capa de eventos, el servicio de pedidos podría conectarse directamente con todos ellos.
Cuando una compra se confirma, el sistema publica PedidoConfirmado. El evento utiliza el identificador del pedido como clave para mantener su secuencia.
Los consumidores realizan tareas diferentes:
- Inventario reserva unidades.
- Logística prepara el envío.
- CRM actualiza el historial.
- Email envía la confirmación.
- Analítica registra la conversión.
- Fraude revisa patrones.
Si el sistema de email está temporalmente detenido, los demás continúan. Cuando vuelve a estar disponible, recupera los eventos pendientes.
La arquitectura también debe resolver errores. Si inventario no puede reservar una unidad, puede publicar ReservaRechazada. Otro proceso decide si cancela, divide el pedido o solicita una acción manual.
No conviene representar todas las decisiones mediante un único evento genérico. Los nombres y datos deben reflejar estados reales del proceso.
Ejemplo de Kafka en Marketing y Analítica
Una plataforma digital puede publicar eventos de navegación, búsquedas, registros, compras y uso de funcionalidades.
Kafka distribuye esos eventos a consumidores con finalidades distintas. Un proceso alimenta la analítica, otro actualiza segmentos y otro detecta comportamientos anómalos.
Una automatización puede reaccionar cuando un usuario completa una acción, siempre que exista base legal, consentimiento y una regla de negocio apropiada.
El principal riesgo consiste en convertir cualquier interacción en un evento sin una taxonomía. Aparecen nombres inconsistentes, propiedades duplicadas y métricas imposibles de comparar.
Antes de publicar conviene definir:
- Nombre del evento.
- Momento exacto.
- Propiedades.
- Identificadores.
- Fuente.
- Finalidad.
- Retención.
- Responsable.
Kafka puede mover millones de eventos y no corregir una definición incorrecta de conversión. La velocidad no sustituye el gobierno del dato.
Kafka vs Cola de Mensajes
Kafka comparte funciones con las colas, pero utiliza un registro persistente y particionado. Los eventos no se eliminan automáticamente porque un consumidor los haya leído.
En una cola tradicional, varios workers suelen competir por mensajes que se retiran después de procesarse. En Kafka, diferentes consumer groups pueden leer el mismo evento de manera independiente.
Kafka resulta adecuado cuando necesitamos:
- Reprocesamiento.
- Varios consumidores independientes.
- Alto volumen.
- Retención.
- Orden por clave.
- Procesamiento continuo.
Una cola convencional puede ser más sencilla para tareas puntuales donde un worker debe ejecutar un trabajo y retirar el mensaje.
No debemos elegir Kafka únicamente porque pueda actuar como cola. Su operación, particionamiento y modelo de consumo añaden complejidad que debe justificarse.
Kafka vs RabbitMQ
Kafka y RabbitMQ pueden transportar mensajes, pero tienen modelos y fortalezas diferentes.
RabbitMQ está orientado a mensajería mediante exchanges, colas, bindings y distintas estrategias de routing. Kafka se centra en logs distribuidos, particiones, retención y consumo por offsets.
Kafka suele encajar bien en pipelines, event streaming y reprocesamiento. RabbitMQ puede resultar adecuado para colas de trabajo, routing flexible y comunicación de mensajes donde la retención histórica no es prioritaria.
La elección debe considerar:
- Volumen.
- Latencia.
- Retención.
- Reprocesamiento.
- Routing.
- Orden.
- Operación.
- Experiencia del equipo.
No existe una tecnología universalmente superior. Algunas arquitecturas utilizan ambas para problemas diferentes.
Kafka vs Base de Datos
Kafka almacena eventos de forma persistente, pero no sustituye automáticamente una base de datos operacional.
Una base está diseñada para consultar y actualizar estados mediante índices, transacciones y modelos de acceso. Kafka está optimizado para escribir y leer secuencias por partición.
Buscar todos los clientes de una ciudad o actualizar una fila concreta no es el uso natural de un topic.
Kafka puede conservar el historial de cambios y una base mantener la vista actual. Un consumidor procesa eventos y actualiza tablas optimizadas para las consultas de la aplicación.
Este patrón separa el registro de hechos de los modelos de lectura, pero añade sincronización y consistencia eventual.
Qué Es Confluent Kafka
Confluent es una empresa y plataforma construida alrededor de Apache Kafka. Ofrece servicios gestionados, herramientas, conectores, gobierno de esquemas y otras capacidades empresariales.
Apache Kafka y Confluent no son exactamente lo mismo. El primero es el proyecto open source; el segundo ofrece productos y servicios que lo amplían o administran.
Una organización puede utilizar Apache Kafka sin contratar Confluent. También puede utilizar un servicio de Confluent para delegar parte de la infraestructura.
La decisión debe considerar coste, operación, funcionalidades, soporte, dependencia y portabilidad.
Cuando una documentación habla de una función de Confluent, no debemos asumir que forma parte del núcleo open source o que estará disponible de la misma manera en otro proveedor.
Cuándo Usar Kafka
Kafka resulta adecuado cuando existe un flujo continuo de eventos, varios consumidores, necesidad de escala o capacidad de reprocesamiento.
Casos razonables son:
- Integrar numerosos sistemas.
- Capturar actividad en tiempo real.
- Distribuir cambios de negocio.
- Construir pipelines de datos.
- Procesar eventos con estado.
- Alimentar varios destinos.
- Desacoplar microservicios.
- Mantener un historial temporal de eventos.
También debe existir un equipo capaz de administrar contratos, seguridad, observabilidad y capacidad. Instalar el software es solo una parte.
La decisión mejora cuando el número de consumidores puede crecer. Un mismo flujo de pedidos puede alimentar nuevas funciones sin modificar su origen.
Cuándo No Conviene Usar Kafka
Kafka puede ser excesivo cuando el proyecto necesita mover pocos mensajes, existe un único consumidor y una cola sencilla cubre el caso.
Tampoco es la herramienta natural para consultas transaccionales, almacenamiento de documentos o reemplazo directo de una API síncrona.
No suele compensar cuando:
- El volumen es reducido.
- No se necesita retención.
- No existe capacidad operativa.
- La respuesta debe ser inmediata y síncrona.
- Una base de datos resuelve el problema.
- La arquitectura añade más dependencias que valor.
Un sistema distribuido introduce fallos parciales, latencia, reintentos y coordinación. Si el beneficio no supera esa complejidad, una solución más sencilla será más mantenible.
En Aula CM recomendamos comenzar por el problema. Elegir Kafka porque aparece en arquitecturas de grandes empresas no convierte un proyecto pequeño en escalable; puede convertirlo en más difícil de operar.
Seguridad en Apache Kafka
La seguridad debe proteger conexiones, identidades, permisos, credenciales y datos almacenados. Un clúster sin controles puede exponer información crítica o permitir publicar eventos falsos.
Los principales ámbitos son:
- Cifrado en tránsito.
- Autenticación de clientes.
- Autorización por recursos.
- Protección de credenciales.
- Segmentación de red.
- Cifrado de almacenamiento.
- Auditoría.
- Actualizaciones.
Los permisos deben seguir el principio de mínimo privilegio. Un consumidor de analítica no necesita publicar en topics de pagos ni administrar el clúster.
También debemos revisar el contenido de los eventos. Cifrar la conexión no evita que datos personales se conserven durante más tiempo del permitido.
Las credenciales no deberían insertarse en repositorios o imágenes. Deben obtenerse mediante mecanismos seguros y rotarse.
Rendimiento y Escalabilidad de Kafka
El rendimiento depende de productores, consumidores, brokers, red, discos, particiones, réplicas y tamaño de eventos. No existe un ajuste único para todos los proyectos.
Kafka obtiene buena capacidad mediante escrituras secuenciales, batching, compresión y distribución. Estas ventajas pueden perderse si se envían eventos diminutos de uno en uno con confirmaciones muy estrictas y sin agrupación.
Los factores relevantes incluyen:
- Eventos por segundo.
- Bytes por segundo.
- Tamaño medio.
- Número de particiones.
- Factor de replicación.
- Retención.
- Número de consumidores.
- Latencia aceptable.
- Rendimiento del almacenamiento.
El número de eventos no es suficiente. Mil eventos de varios megabytes generan una carga distinta a miles de registros pequeños.
La capacidad debe probarse con patrones parecidos a producción. Un benchmark sintético puede ocultar serialización, lógica de consumidores y variaciones de tráfico.
Cómo Elegir el Número de Particiones
Las particiones determinan paralelismo y distribución. Deben permitir el rendimiento previsto sin crear una sobrecarga innecesaria.
La elección considera tasa por partición, consumidores previstos, crecimiento y necesidad de orden.
Aumentar particiones es posible, pero puede cambiar la asignación de claves. Si la aplicación depende de una distribución histórica concreta, el cambio necesita análisis.
Reducir particiones no es una operación directa equivalente. Por eso conviene planificar con margen razonable sin sobredimensionar.
Monitorización de Kafka
Monitorizar Kafka significa observar la salud del clúster, la replicación, los productores, los consumidores y la infraestructura.
Entre las señales importantes se encuentran:
- Particiones sin líder.
- Réplicas fuera de sincronización.
- Latencia de peticiones.
- Errores de producción.
- Uso de disco.
- Tráfico de red.
- Tiempo de recolección de memoria.
- Consumer lag.
- Rebalances.
- Errores de deserialización.
El consumer lag mide la distancia entre los últimos eventos disponibles y el progreso de un grupo. Un lag creciente indica que el consumidor no mantiene el ritmo.
Un lag de cero no siempre significa que todo funcione. El consumidor puede estar confirmando antes de completar su lógica o puede no estar recibiendo eventos esperados.
Las alertas deben combinar señales. El uso elevado de disco es urgente si la retención continúa creciendo y no existe capacidad para ampliar.
Kafka Autogestionado o Servicio Administrado
Una instalación autogestionada ofrece mayor control sobre infraestructura, configuración y costes directos. También obliga a asumir actualizaciones, disponibilidad, copias, seguridad y soporte.
Un servicio administrado delega parte de la operación en un proveedor. El equipo sigue siendo responsable del diseño de eventos, consumers, esquemas, permisos y gasto.
La comparación debe incluir:
- Experiencia interna.
- Disponibilidad necesaria.
- Regiones.
- Volumen.
- Seguridad.
- Integraciones.
- Soporte.
- Coste de transferencia.
- Dependencia del proveedor.
El coste de una plataforma propia no se limita a las máquinas. Incluye guardias, incidentes, pruebas, actualizaciones y tiempo de especialistas.
El servicio administrado tampoco elimina los incidentes. Puede existir una mala configuración de retención, particiones insuficientes o consumidores defectuosos.
Metodología para Implementar Apache Kafka
1. Identificar los Casos de Uso
Definimos qué eventos existen, quién los produce y quién los necesita. Evitamos comenzar creando infraestructura sin un flujo concreto.
2. Modelar los Eventos
Elegimos nombres, claves, campos, tiempos y responsabilidades. Diferenciamos hechos, comandos y estados.
3. Diseñar Topics y Particiones
Establecemos límites, orden, paralelismo, replicación y retención. Cada configuración necesita una razón.
4. Definir Contratos
Seleccionamos formato y compatibilidad. Los cambios deben seguir un proceso de versionado.
5. Diseñar los Consumidores
Planificamos idempotencia, confirmaciones, reintentos, errores y reconstrucción.
6. Preparar Seguridad
Configuramos autenticación, permisos, cifrado y protección de secretos antes de conectar datos reales.
7. Probar Fallos
Simulamos brokers no disponibles, consumers lentos, eventos inválidos y rebalances.
8. Medir Capacidad
Realizamos pruebas con volúmenes, tamaños y patrones representativos.
9. Implementar Observabilidad
Definimos métricas, logs, trazas, paneles y alertas antes del lanzamiento.
10. Establecer Gobierno
Asignamos responsables para topics, esquemas, retención, permisos y documentación.
Errores Frecuentes al Utilizar Kafka
Utilizar Kafka para Todo
No todas las integraciones necesitan event streaming. Una API o una cola simple puede resolver casos más pequeños.
Crear Topics sin Gobierno
Los nombres y contratos se vuelven inconsistentes. Después resulta difícil saber qué flujo es fiable.
No Diseñar las Claves
Una clave incorrecta distribuye mal los datos o rompe el orden necesario.
Confiar en el Orden Global
Kafka mantiene orden por partición, no en todo el topic.
Ignorar los Duplicados
Los reintentos y fallos pueden provocar reprocesamiento. Las operaciones críticas necesitan idempotencia.
Confirmar Demasiado Pronto
Si el offset se guarda antes de completar la operación, un fallo puede provocar pérdida lógica.
Bloquearse con un Evento Inválido
Un único registro no debería detener indefinidamente toda la partición. Se necesita una política de errores.
Crear Demasiadas Particiones
El exceso aumenta metadatos, archivos, replicación y complejidad operativa.
No Monitorizar el Lag
El consumidor puede acumular horas de retraso sin que el proceso esté técnicamente caído.
Confundir Replicación con Backup
Las réplicas también copian borrados y errores. Se necesitan procedimientos de recuperación adecuados.
Conservar Datos sin Política
La retención ilimitada puede aumentar costes e incumplir requisitos de privacidad.
Cambiar Esquemas sin Compatibilidad
Una modificación aparentemente pequeña puede romper consumidores de otros equipos.
No Documentar la Semántica
Un esquema puede ser técnicamente válido y no explicar qué significa cada valor.
Checklist para Revisar una Arquitectura Kafka
- Los casos de uso están definidos.
- Cada evento representa un hecho comprensible.
- Los productores tienen propietario.
- Los consumidores están identificados.
- Los topics siguen una convención.
- Las claves están diseñadas.
- El orden necesario está documentado.
- El número de particiones está justificado.
- La replicación coincide con la disponibilidad esperada.
- La retención responde a una necesidad.
- Los esquemas están versionados.
- La compatibilidad se valida.
- Los productores gestionan reintentos.
- Los consumidores son idempotentes cuando corresponde.
- Los offsets se confirman en el momento correcto.
- Los eventos inválidos tienen tratamiento.
- Existen dead-letter topics cuando aportan valor.
- El consumer lag se monitoriza.
- Las réplicas fuera de sincronización generan alertas.
- El uso de disco está controlado.
- Las conexiones utilizan autenticación.
- Los permisos aplican mínimo privilegio.
- Las credenciales están protegidas.
- Los datos sensibles tienen una política.
- La capacidad se ha probado.
- Los fallos se han simulado.
- Existe un procedimiento de recuperación.
- Las actualizaciones tienen plan.
- Los responsables están documentados.
- La arquitectura aporta más valor que complejidad.
Preguntas Frecuentes sobre Kafka
¿Qué Es Kafka?
Kafka es una plataforma distribuida para publicar, almacenar, procesar y consumir flujos de eventos.
¿Qué Es Apache Kafka?
Es el proyecto open source de la Apache Software Foundation que proporciona la tecnología de event streaming.
¿Para Qué Sirve Kafka?
Sirve para integrar aplicaciones, crear pipelines, procesar datos en tiempo real y distribuir eventos entre varios sistemas.
¿Kafka Es una Cola de Mensajes?
Puede cubrir algunos casos de mensajería, pero utiliza un log persistente y particionado que permite retención y varios consumidores independientes.
¿Kafka Es una Base de Datos?
Almacena eventos de forma persistente, pero no sustituye automáticamente una base diseñada para consultas y actualizaciones operacionales.
¿Qué Es un Topic en Kafka?
Es una categoría lógica donde se publican eventos relacionados.
¿Qué Es una Partición?
Es una división ordenada de un topic que permite distribuir almacenamiento y procesamiento.
¿Qué Es un Broker?
Es un servidor que almacena particiones y atiende a productores y consumidores.
¿Qué Es un Producer?
Es una aplicación cliente que publica eventos en topics.
¿Qué Es un Consumer?
Es una aplicación que lee y procesa eventos.
¿Qué Es un Consumer Group?
Es un grupo de consumidores que se reparten las particiones para trabajar en paralelo.
¿Qué Es un Offset?
Es la posición de un evento dentro de una partición y permite registrar el progreso del consumidor.
¿Kafka Garantiza el Orden?
Garantiza el orden dentro de cada partición, no entre todas las particiones de un topic.
¿Kafka Puede Duplicar Eventos?
Los reintentos y fallos pueden provocar reprocesamiento según la configuración. Los consumidores deben diseñarse para tolerarlo.
¿Qué Es Kafka Streams?
Es una biblioteca para crear aplicaciones Java o Scala que procesan y transforman datos almacenados en Kafka.
¿Qué Es Kafka Connect?
Es el componente utilizado para mover datos entre Kafka y sistemas externos mediante conectores.
¿Qué Es Schema Registry?
Es un servicio para registrar y controlar los esquemas de los eventos y su compatibilidad.
¿Qué Es ZooKeeper en Kafka?
Es el sistema que utilizaban históricamente las versiones antiguas para coordinar metadatos. Las versiones actuales utilizan KRaft.
¿Qué Es KRaft?
Es el mecanismo actual de Kafka para gestionar los metadatos mediante un quorum de controladores.
¿Kafka Funciona con Java?
Sí. Java es uno de sus principales ecosistemas y Kafka Streams está diseñado como biblioteca cliente para Java y Scala.
¿Kafka Funciona con Python?
Sí. Existen clientes que permiten producir y consumir eventos desde aplicaciones Python.
¿Kafka Se Puede Utilizar con Spring Boot?
Sí. Spring ofrece integraciones para productores, listeners, serialización y tratamiento de mensajes.
¿Kafka Es Big Data?
Es una tecnología utilizada dentro de arquitecturas Big Data para ingerir, distribuir y procesar eventos, pero no representa por sí sola toda la plataforma.
¿Kafka Es Gratis?
Apache Kafka es open source. Operarlo requiere infraestructura y trabajo, y los servicios gestionados aplican sus propios precios.
¿Qué Diferencia Hay entre Kafka y Confluent?
Apache Kafka es el proyecto open source. Confluent es una empresa que ofrece una plataforma, servicios y herramientas construidos alrededor de Kafka.
¿Cuándo Conviene Utilizar Kafka?
Cuando existen flujos continuos, múltiples consumidores, necesidad de escala, desacoplamiento o reprocesamiento.
¿Cuándo No Conviene Utilizar Kafka?
Cuando el caso es pequeño, no necesita retención o puede resolverse de forma más sencilla con una base de datos, una API o una cola convencional.
Conclusión: ¿Qué es Apache Kafka?
Apache Kafka es una plataforma distribuida de event streaming que permite publicar, almacenar y procesar eventos entre aplicaciones.
Su arquitectura utiliza topics para organizar los datos, particiones para distribuirlos, brokers para almacenarlos y consumers para procesarlos. Los offsets permiten registrar el progreso y los consumer groups reparten el trabajo.
Kafka destaca por conservar eventos después de su lectura, admitir varios consumidores independientes y permitir el reprocesamiento. Estas características lo convierten en una pieza habitual de pipelines, microservicios, analítica, ecommerce y sistemas de datos.
La tecnología no elimina la complejidad. La desplaza hacia decisiones sobre eventos, claves, particiones, esquemas, idempotencia, retención, seguridad y observabilidad.
En las versiones actuales, KRaft gestiona los metadatos del clúster y ZooKeeper queda asociado a instalaciones heredadas. Kafka Connect facilita integraciones y Kafka Streams permite crear aplicaciones de procesamiento.
La recomendación profesional es comenzar por un caso de negocio concreto. Después se modelan los eventos, se identifican productores y consumidores y se decide si las ventajas de Kafka justifican su operación.
Cuando la arquitectura está bien diseñada, un evento puede alimentar numerosos procesos sin crear conexiones directas entre todos los sistemas. Cuando se implementa sin contratos ni gobierno, la plataforma distribuye datos inconsistentes con la misma eficacia con la que distribuiría datos correctos.
Comprender Kafka no consiste únicamente en aprender comandos o crear un topic. Consiste en diseñar cómo una organización representa, conserva y utiliza los hechos que ocurren dentro de su negocio.
