Última actualización: 2026-11-14

Contenido de esta página

• ¿Qué es Apache Kafka?
• ¿Para qué sirve Kafka? El problema que resuelve
• ¿Cómo funciona Kafka? Tópicos, particiones y offsets
• Síncrono o asíncrono: la diferencia práctica
• ¿Qué garantiza Kafka y qué no?
• Su primer productor y consumidor: un ejemplo ejecutado
• Buenas prácticas que recomienda la documentación
• KRaft y ZooKeeper: ¿qué cambió?
• ¿Cuándo usar Kafka y cuándo no?

En junio de 2011, en un taller académico celebrado en Atenas, tres ingenieros de LinkedIn, la red social profesional, presentaron un artículo sobre un sistema que ya tenían funcionando [1]. Eran Jay Kreps, Neha Narkhede y Jun Rao. El sistema se llamaba Kafka. Llevaba más de seis meses en producción y ya lo habían liberado como código abierto, es decir, con el código a la vista para que cualquiera lo use [1].

Su problema eran los datos de log, el registro automático de lo que pasa en un sitio: clics, búsquedas, páginas vistas, métricas de las máquinas [1]. Su volumen, escribieron, era órdenes de magnitud mayor, es decir, muchísimas veces mayor, que el de los datos «reales» [1]. Y la mayoría de sus aplicaciones en tiempo real debía recibirlo con un retraso de no más de unos segundos [1].

Para lograrlo, los autores renunciaron a algo. Las herramientas de mensajería de las empresas ofrecían garantías de entrega muy finas, que según ellos a menudo sobraban para registrar actividad [1]. Lo dijeron sin rodeos: «perder de vez en cuando unos pocos eventos de páginas vistas ciertamente no es el fin del mundo» [1]. Las citas de esta página son traducción propia.

Seis años después, la versión 0.11.0.0, publicada en junio de 2017, añadió un modo del productor que no duplica mensajes al reintentar [2][3]. También trajo transacciones: varios mensajes se escriben todos o ninguno [2].

Kafka es hoy un registro compartido de hechos: cada aplicación anota lo que pasó al final de la lista, y cada lector avanza por ella a su propio paso.

¿Qué es Apache Kafka?

Apache Kafka es un sistema que recibe eventos de muchas aplicaciones, los guarda en orden y se los entrega a otras, con el trabajo repartido entre varios servidores. Un evento es la constancia de que algo pasó: un pago, un pedido, la lectura de un sensor [4]. La documentación oficial llama a Kafka una plataforma de transmisión de eventos, y compara esa transmisión con el sistema nervioso central del cuerpo humano [4].

Kafka hace tres cosas [4]:

1. Deja publicar (escribir) eventos y suscribirse a ellos (leerlos).
2. Guarda esos eventos de forma duradera, el tiempo que usted quiera.
3. Permite procesarlos a medida que ocurren o después, mirando hacia atrás.

Por dentro, Kafka es un clúster, es decir, un grupo de servidores que trabajan como uno solo [4]. A esos servidores les hablan por la red unos programas cliente [4]. Los servidores que guardan los datos se llaman brokers [4]. Si uno falla, los demás toman su trabajo [4].

Kafka es un proyecto de la Fundación Apache, que publica su software con la licencia Apache 2.0 [15]. La versión más reciente es la 4.4.0, del 22 de octubre de 2026 [3]. Al día siguiente salió la 4.3.2, una versión de corrección de la rama anterior, que sigue con soporte [3].

¿Para qué sirve Kafka? El problema que resuelve

Kafka sirve para que los sistemas de una organización se pasen datos sin depender unos de otros. Quien produce un evento no necesita saber quién lo va a leer, ni esperar a que lo lean [4]. La documentación lo pone así: los productores y los consumidores están completamente desacoplados, es decir, no dependen entre sí [4].

Piense en una tienda en línea. Cuando entra un pedido, lo necesitan la facturación, la bodega, el correo de confirmación y el reporte de ventas. Sin un intermediario, el sistema de pedidos tendría que llamar a los cuatro, uno por uno, y quedar pendiente de cada respuesta. Con Kafka escribe el pedido una vez, y cada uno de los otros lo lee cuando le toca.

La guía oficial de usos reúne varios casos [13]:

Uso	Qué hace Kafka ahí
Seguimiento de actividad en un sitio web	Publica cada acción del usuario, como páginas vistas o búsquedas, en temas centrales llamados tópicos; fue el caso de uso original [13]
Métricas	Junta estadísticas de operación de aplicaciones repartidas en muchos servidores [13]
Agregación de logs	Reemplaza la recolección de los logs, los archivos de registro de los servidores, por un flujo de eventos [13]
Procesamiento en etapas	Unas aplicaciones leen datos crudos de un tópico y publican en otro una versión limpia o enriquecida [13]
Mensajería	Sirve como reemplazo de un intermediario de mensajes tradicional [13]

Esos datos pueden terminar en otro lugar para analizarse. La documentación menciona cargas periódicas hacia un data warehouse relacional o hacia Hadoop, un sistema para guardar y procesar datos en muchas máquinas [2]. Los eventos también pueden quedar guardados en bruto en un data lake. Dentro del oficio de la ingeniería de datos, Kafka es la pieza del dato en movimiento.

¿Cómo funciona Kafka? Tópicos, particiones y offsets

Kafka funciona como un log distribuido: una lista de eventos a la que solo se le agrega al final, partida en pedazos que viven en distintos servidores. Cada evento tiene una clave, un valor, una marca de tiempo y, si se quiere, unas etiquetas adicionales [4]. La documentación pone este ejemplo: clave «Alice», valor «hizo un pago de 200 dólares a Bob» [4].

Los eventos se guardan en tópicos. La documentación lo explica con una imagen sencilla: un tópico se parece a una carpeta, y los eventos son los archivos que contiene [4]. Un tópico puede tener cero, uno o muchos productores, y cero, uno o muchos consumidores [4].

Cada tópico se parte en particiones, que son pedazos repartidos entre varios brokers [4]. Un evento nuevo se agrega al final de una sola partición [4]. Dentro de ella, cada evento tiene un número de posición llamado offset. La posición de un consumidor en esa partición es un solo número: el offset del siguiente evento que va a leer [2].

Este es el vocabulario que usa la documentación oficial:

Concepto	Qué es	Para qué sirve
Evento	La constancia de que algo pasó; la documentación también lo llama registro o mensaje [4]	Es la unidad que se escribe y se lee
Tópico	El lugar donde se organizan y se guardan los eventos [4]	Separar los datos por tema, por ejemplo «pagos»
Partición	Cada pedazo de un tópico, ubicado en un broker [4]	Que muchos clientes lean y escriban a la vez en varios servidores [4]
Offset	La posición de un evento dentro de su partición [2]	Que cada consumidor sepa por dónde va
Productor	La aplicación cliente que publica eventos [4]	Escribir sin esperar a los lectores [4]
Consumidor	La aplicación cliente que se suscribe a eventos y los procesa [4]	Leer al ritmo que pueda sostener [1]
Grupo de consumidores	Un conjunto de consumidores que se reparten las particiones; en cada grupo, cada partición la lee un solo consumidor a la vez [2]	Repartir el trabajo sin que dos lean lo mismo
Broker	Cada servidor que forma la capa de almacenamiento [4]	Guardar las particiones y atender a los clientes
Réplica	Cada copia de una partición en otro broker; una es la líder y recibe todas las escrituras [2]	Que los datos sobrevivan si un servidor falla [2]

El número de particiones pone el techo del trabajo en paralelo de los consumidores, y cada partición tiene que caber completa en un servidor [8].

Mensaje, evento y stream: tres palabras, una idea

La documentación de Kafka usa evento, registro y mensaje como sinónimos [4]. Cuando habla de stream, o flujo, se refiere a la secuencia continua de eventos [4]. El artículo de 2011 ya lo planteaba así: un tópico define un flujo de mensajes de un mismo tipo [1].

La diferencia de fondo no está en la palabra, sino en qué pasa después de leer. En los sistemas de mensajería tradicionales, el mensaje se borra cuando alguien lo consume. En Kafka no: un evento se puede leer tantas veces como haga falta, y se descarta solo cuando vence el plazo de retención del tópico [4]. La documentación reconoce que poder devolver a un consumidor a un offset viejo rompe el contrato habitual de una cola [2].

Eso tiene un uso muy práctico. Si un consumidor tenía un error de código, se corrige el error y se vuelven a leer los mismos eventos [2].

Síncrono o asíncrono: la diferencia práctica

En una llamada síncrona, quien pide se queda esperando la respuesta antes de seguir; en una comunicación asíncrona, deja el encargo con un intermediario y sigue con lo suyo. Kafka es ese intermediario. Los productores nunca necesitan esperar a los consumidores [4].

La diferencia se nota cuando algo falla. Si el sistema de pedidos llama directamente a la facturación y esta se cae, el pedido se queda atascado. Si lo escribe en Kafka, la facturación lo leerá cuando vuelva, desde el último offset que había confirmado.

Hay un costo. El productor ya no sabe, en el momento, si la facturación procesó el pedido. Lo único que puede confirmar es que Kafka lo guardó. Y hasta eso se configura: puede esperar la confirmación de todas las réplicas sincronizadas, solo la de la líder o ninguna [7].

Los autores de 2011 añadieron otra decisión: el consumidor jala los datos del broker, en vez de que el broker se los empuje [1]. Así cada consumidor pide al ritmo máximo que aguanta y no lo inundan con más de lo que puede procesar [1].

¿Qué garantiza Kafka y qué no?

Kafka garantiza el orden dentro de una partición, no en el tópico completo. Cualquier consumidor de una partición lee sus eventos exactamente en el orden en que se escribieron [4]. Entre particiones distintas no hay garantía de orden; el artículo de 2011 ya lo advertía [1].

Por eso importa la clave. Los eventos con la misma clave, por ejemplo el mismo número de cliente, van a la misma partición [4]. Si no hay clave, el productor elige la partición con su propia estrategia de reparto [7].

Sobre la entrega, la documentación distingue tres promesas [2]:

1. Como máximo una vez. Un mensaje se puede perder, pero nunca se entrega dos veces.
2. Al menos una vez. Nunca se pierde, pero puede llegar repetido.
3. Exactamente una vez. Cada mensaje se procesa una sola vez.

Lo que trae por defecto está escrito en una frase: «Kafka garantiza por defecto la entrega al menos una vez» [2]. Si un consumidor procesa un lote y se cae antes de guardar su posición, quien lo reemplace recibirá de nuevo algunos eventos ya procesados [2].

El «exactamente una vez» tiene alcance preciso. La documentación lo ofrece en Kafka Streams, la biblioteca de procesamiento del proyecto [2]. También al leer, procesar y escribir entre tópicos de Kafka, con un productor transaccional y un consumidor que solo lee lo confirmado [2]. Hacia otros sistemas de destino, en general, requiere la cooperación de esos sistemas [2].

Un evento se da por confirmado cuando todas las réplicas sincronizadas de su partición lo escribieron [2]. Desde ahí no se pierde mientras siga vivo al menos un broker que replique esa partición [2].

¿Cuánto tiempo guarda Kafka los eventos?

Kafka guarda los eventos según una política de retención que se fija por tópico [4]. La política por defecto borra los segmentos viejos del log cuando se cumple un límite de tiempo o de tamaño [6]. La otra, la compactación, conserva el último valor de cada clave [6].

Parámetro del tópico	Qué controla	Valor por defecto
retention.ms	Cuánto tiempo se guarda el log antes de descartar segmentos viejos [6]	604800000 milisegundos, es decir, 7 días; con -1 no hay límite de tiempo [6]
retention.bytes	Cuánto puede crecer cada partición antes de descartar segmentos viejos [6]	-1: sin límite de tamaño, solo el de tiempo [6]
cleanup.policy	Si se borra por tiempo y tamaño («delete»), se compacta («compact») o ambas [6]	delete [6]

Ojo con un detalle: el límite de tamaño se aplica a cada partición. Para saber cuánto ocupa el tópico completo, hay que multiplicarlo por el número de particiones [6].

Su primer productor y consumidor: un ejemplo ejecutado

El ejemplo crea un tópico de tres particiones, escribe ocho eventos de pedidos con su clave y los lee como un grupo de consumidores. Sirve para ver con sus propios ojos dos ideas: la clave decide la partición, y el orden solo se respeta dentro de cada una.

Lo ejecuté el 14 de noviembre de 2026 con Kafka 4.4.0, la distribución oficial descargada del servidor de Apache. Antes comprobé su huella de verificación, un código que confirma que el archivo llegó completo y sin cambios.

Kafka corre sobre Java, y usé la versión 21 en un portátil con Windows. La guía pide Java 17 o posterior [5]. La documentación da soporte completo a tres versiones: 17, 21 y 25 [12].

El servidor corrió en modo KRaft, en el que Kafka coordina su propio clúster sin un servicio externo. Usé el archivo de configuración que trae la distribución, donde un solo servidor hace de broker y de controlador.

Los pasos fueron estos:

1. Preparar el directorio de datos y arrancar el servidor, con los comandos de la guía de inicio rápido [5].
2. Crear el tópico «pedidos» con tres particiones.
3. Escribir ocho eventos con la herramienta de consola del productor.
4. Leerlos con la herramienta de consola del consumidor, como grupo «facturacion».

El archivo de eventos tiene un evento por línea. Lo que va antes de los dos puntos es la clave, el municipio de la tienda:

giron:pedido 101 creado
floridablanca:pedido 102 creado
giron:pedido 101 pagado
piedecuesta:pedido 103 creado
floridablanca:pedido 102 pagado
giron:pedido 101 despachado
piedecuesta:pedido 103 pagado
floridablanca:pedido 102 despachado

Estos son los comandos, escritos con los scripts de la distribución, que son pequeños programas de línea de comandos, que es la forma que documenta la guía oficial [5]. En Windows, los scripts para ese sistema fallaron con un error de línea demasiado larga. Por eso llamé las mismas herramientas con Java directamente, con los mismos parámetros.

# Crear el tópico «pedidos» con 3 particiones
bin/kafka-topics.sh --create --topic pedidos --partitions 3 --bootstrap-server localhost:9092

# Escribir los ocho eventos; lo que va antes de «:» es la clave
bin/kafka-console-producer.sh --topic pedidos --bootstrap-server localhost:9092 \
  --reader-property parse.key=true --reader-property key.separator=: < eventos.txt

# Leerlos desde el principio como grupo «facturacion», con partición, offset y clave
bin/kafka-console-consumer.sh --topic pedidos --from-beginning --group facturacion \
  --max-messages 8 --bootstrap-server localhost:9092 \
  --formatter-property print.key=true --formatter-property print.partition=true \
  --formatter-property print.offset=true

Esta fue la salida del consumidor, sin el aviso informativo que imprime al arrancar:

Partition:2	Offset:0	giron	pedido 101 creado
Partition:2	Offset:1	giron	pedido 101 pagado
Partition:2	Offset:2	piedecuesta	pedido 103 creado
Partition:2	Offset:3	giron	pedido 101 despachado
Partition:2	Offset:4	piedecuesta	pedido 103 pagado
Partition:0	Offset:0	floridablanca	pedido 102 creado
Partition:0	Offset:1	floridablanca	pedido 102 pagado
Partition:0	Offset:2	floridablanca	pedido 102 despachado
Processed a total of 8 messages

Mire el pedido 102. Fue el segundo evento escrito, pero salió en el sexto lugar. El orden global se perdió, porque el consumidor leyó primero toda la partición 2 y después la 0.

En cambio, la historia de cada pedido está intacta: creado, pagado, despachado. Eso pasa porque todos los eventos de una misma clave cayeron en la misma partición. El productor la elige con un cálculo sobre la clave, llamado hash [7].

También salta a la vista que Girón y Piedecuesta comparten la partición 2, y que la partición 1 quedó vacía. Con solo tres claves, el reparto no tiene por qué ser parejo.

Después revisé la posición del grupo con la herramienta que documenta la guía de operaciones [8]:

bin/kafka-consumer-groups.sh --describe --group facturacion --bootstrap-server localhost:9092

Consumer group 'facturacion' has no active members.

GROUP           TOPIC           PARTITION  CURRENT-OFFSET  LOG-END-OFFSET  LAG             CONSUMER-ID     HOST            CLIENT-ID
facturacion     pedidos         0          3               3               0               -               -               -
facturacion     pedidos         1          0               0               0               -               -               -
facturacion     pedidos         2          5               5               0               -               -               -

La columna CURRENT-OFFSET es la posición que el grupo guardó en cada partición. LOG-END-OFFSET es dónde termina el log. LAG es la diferencia: cuántos eventos le faltan por leer. Aquí es cero en las tres, porque el grupo ya leyó todo.

Hice dos pruebas más, sin cambiar nada. Un segundo grupo, «despachos», leyó desde el principio los mismos ocho eventos: leerlos no los había borrado. Y el grupo «facturacion», lanzado otra vez sin pedir el principio, no recibió ninguno en ocho segundos de espera: retomó desde la posición que había guardado.

Buenas prácticas que recomienda la documentación

Las buenas prácticas de Kafka empiezan por diseñar bien las claves y las copias, antes de escribir el primer evento. Estas son las que la documentación oficial recomienda o explica con su consecuencia:

1. Elija la clave por lo que necesita en orden. Si los eventos de un cliente deben leerse en secuencia, el identificador del cliente va como clave [4]. Añadir particiones después puede cambiar la partición a la que va una clave, y Kafka no redistribuye los datos que ya existen [8].
2. Guarde dos o tres copias. La guía de operaciones recomienda un factor de réplica de 2 o 3 [8]. Un escenario típico, según la documentación, combina un factor de 3, un mínimo de 2 réplicas sincronizadas y productores que esperan la confirmación de todas [6].
3. Deje activa la idempotencia del productor. Con ella, el productor asegura que en el flujo quede una sola copia de cada mensaje, aunque reintente [7]. Viene activa por defecto, salvo que otra configuración choque con ella [7]. Para controlar los reintentos, la documentación sugiere ajustar el tiempo máximo de entrega en lugar del número de reintentos [7].
4. Haga que su consumidor tolere repetidos. Con la entrega al menos una vez, un evento puede llegar dos veces [2]. Si cada evento trae una clave primaria, procesarlo de nuevo solo sobrescribe el mismo registro [2].
5. Vigile el retraso de los consumidores. La herramienta de grupos muestra cuánto le falta a cada uno [8], y el consumidor publica una métrica con su mayor retraso [16].
6. Si busca «exactamente una vez», configure las transacciones como pide la guía. El consumidor solo lee lo confirmado y no confirma su posición de forma automática; el productor lleva un identificador transaccional [2]. Se aconseja un productor por cada consumidor [2].

KRaft y ZooKeeper: ¿qué cambió?

Desde la versión 4.0, Kafka funciona solo en modo KRaft: ZooKeeper, el servicio externo que antes coordinaba el clúster, ya no se usa [9]. Esa versión salió el 18 de marzo de 2025 [3]. La guía de actualización vigente repite la advertencia en varias versiones posteriores: el modo ZooKeeper fue eliminado [9].

En el artículo de 2011, Kafka usaba ZooKeeper para detectar qué brokers y consumidores entraban o salían, y para guardar el offset consumido de cada partición [1]. KRaft mete esa coordinación dentro del propio Kafka [10]. Unos servidores llamados controladores administran los metadatos, es decir, los datos sobre el propio clúster [10]. Se ponen de acuerdo con el protocolo Raft, un método para que varias máquinas coincidan en un mismo registro [10].

La documentación de la versión 4.4 da tres pautas para los controladores [11]:

1. Un administrador suele elegir 3 o 5 servidores para ese papel.
2. Debe seguir viva la mayoría: con 3 controladores se tolera la caída de 1, y con 5, la de 2.
3. El modo combinado, en el que un mismo servidor es broker y controlador, sirve para casos pequeños como un entorno de desarrollo, pero no se recomienda en despliegues críticos.

Si usted hereda un clúster viejo con ZooKeeper, no puede saltar directo a la 4.x. La migración exige pasar por una versión puente, y la última es la 3.9 [11]. KRaft se consideró listo para producción desde la 3.3 [9].

¿Cuándo usar Kafka y cuándo no?

Lo que sigue es criterio editorial, no una regla de la documentación. Kafka tiene sentido cuando un mismo hecho le interesa a varios sistemas o cuando hay que poder volver a leer el pasado. También cuando el volumen obliga a repartir la escritura entre servidores. Sus propias piezas apuntan ahí: tópicos con muchos lectores, retención configurable y particiones [4][6].

Conviene pensarlo dos veces en estos casos:

1. Un solo sistema le pasa datos a otro, y nada más. Una llamada directa o una carga programada puede bastar.
2. Necesita orden total entre todos los eventos. Kafka solo lo da dentro de una partición [4]; un tópico de una sola partición lo consigue, pero renuncia al trabajo en paralelo [8].
3. Cada mensaje es una tarea suelta que debe confirmarse una por una. La documentación admite que algunas cargas de mensajería tradicional no encajan bien con los grupos de consumidores; para eso Kafka ofrece los grupos de reparto, o share groups [2]. Las colas de mensajes como familia de herramientas son otro tema.
4. Nadie en el equipo puede operar el clúster. Un despliegue crítico pide, además de los brokers, controladores separados: normalmente 3 o 5 [11]. Existe la opción de contratarlo como servicio gestionado a varios proveedores [4].

Kafka no es un motor de cálculo. Para transformar eventos con SQL, el lenguaje para consultar datos, o con modelos, se suele leer de Kafka desde otra herramienta. Apache Spark, por ejemplo, trae una integración para leer y escribir datos de Kafka [14]. Mover datos con conectores hacia otros sistemas es tarea de Kafka Connect, la pieza del proyecto para importar y exportar eventos [4]. Y quién decide qué datos lleva cada tópico, o quién puede leerlo, es asunto del gobierno de datos.

Para un equipo latinoamericano pequeño, la cuenta empieza en cero: la licencia no cuesta [15] y la distribución corre en un solo computador con Java, como en el ejemplo [5]. El gasto aparece después, en servidores, en almacenamiento y en el tiempo de quien lo opera. Dentro del panorama del big data, instalarlo para aprender es sencillo; sostenerlo en producción es lo que cuesta.

Tomo partido en una cosa, y es opinión mía: lo que hace valioso a Kafka no es la velocidad. Es que trata los datos como un libro de registro, donde lo escrito no se borra al leerlo y cada lector lleva su propio separador. El ejemplo de Girón lo muestra en pequeño. Dos áreas leyeron los mismos ocho pedidos sin estorbarse, y ninguna tuvo que preguntarle a la otra por dónde iba.

Antes de instalarlo, haga una sola pregunta en su equipo: ¿qué hecho de su negocio necesitan saber tres sistemas a la vez? Si no aparece ninguno, todavía no necesita Kafka.

Preguntas frecuentes

¿Apache Kafka es gratis? Sí, el software no cobra licencia. Es un proyecto de la Fundación Apache, que publica lo que produce bajo la licencia Apache 2.0 [15]. Lo que sí cuesta es la infraestructura que lo sostiene y el personal que lo mantiene. También se puede contratar ya administrado por un proveedor [4].

¿Kafka todavía necesita ZooKeeper? No en las versiones actuales. A partir de la 4.0, el modo ZooKeeper fue eliminado y solo existe el modo KRaft [9]. Quien tenga un clúster antiguo debe migrar primero con una versión puente, la 3.9, antes de subir a la serie 4 [11].

¿Qué pasa con un evento después de que alguien lo lee? Nada: sigue en el tópico. Otro grupo puede leerlo desde el principio, y el mismo grupo puede retroceder a un offset anterior si lo necesita [2][4]. Con la política por defecto («delete»), el evento sale del log cuando vence la retención o cuando el tamaño de la partición pasa del límite configurado [6].

¿Kafka garantiza el orden de los mensajes? Solo dentro de cada partición [4]. Si dos eventos deben conservar su secuencia, tienen que viajar con la misma clave, que los manda al mismo pedazo del tópico [4]. Y si un tópico gana particiones después, una clave puede pasar a otra partición [8].

¿Cuántas particiones debe tener un tópico? Depende de cuántos consumidores quiera tener trabajando a la vez. El número de particiones pone el techo de consumidores trabajando en paralelo dentro de un grupo y obliga a que cada partición quepa entera en un servidor [8]. Como agregarlas luego puede mover claves de partición, conviene calcularlas desde el arranque [8].

Referencias

1. Kreps, Jay; Narkhede, Neha; Rao, Jun (LinkedIn Corp.). Kafka: a Distributed Messaging System for Log Processing, NetDB’11, 12 de junio de 2011, Atenas, ACM 978-1-4503-0652-2 — sistema de mensajería distribuido para datos de log desarrollado en LinkedIn; abierto como código abierto y en producción en LinkedIn por más de 6 meses; volumen de los datos de actividad varios órdenes de magnitud mayor que los datos «reales»; aplicaciones con retrasos de no más de unos segundos; las garantías de entrega de los sistemas empresariales son a menudo excesivas para logs: «losing a few pageview events occasionally is certainly not the end of the world»; modelo «pull»; un tópico define un flujo de mensajes de un tipo; solo garantiza entrega al menos una vez; orden garantizado dentro de una partición y no entre particiones; uso de ZooKeeper para registrar brokers, consumidores y offsets. Microsoft Research: Kafka, NetDB 2011 (PDF) — Consultada: 2026-11-14.
2. The Apache Software Foundation. Design, documentación de Apache Kafka 4.4 (modificada el 26 de octubre de 2026) — posición del consumidor como un entero, el offset del siguiente mensaje; cada partición la consume un solo consumidor de cada grupo; rebobinar a un offset viejo «violates the common contract of a queue»; semánticas como máximo, al menos y exactamente una vez; mensaje confirmado cuando lo aplican todas las réplicas sincronizadas; productor idempotente y transacciones desde 0.11.0.0; «Kafka guarantees at-least-once delivery by default»; exactamente una vez en Kafka Streams y con productor transaccional y consumidor read_committed; configuración de transacciones; share groups; replicación con líder y seguidores; cargas periódicas hacia Hadoop o un data warehouse relacional. Apache Kafka: Design 4.4 — Consultada: 2026-11-14.
3. The Apache Software Foundation. Downloads — 4.4.0 publicada el 22 de octubre de 2026; 4.3.2 publicada el 23 de octubre de 2026, ambas con soporte; 4.0.0 publicada el 18 de marzo de 2025; 0.11.0.0 publicada el 28 de junio de 2017. Apache Kafka: Downloads — Consultada: 2026-11-14.
4. The Apache Software Foundation. Introduction, documentación de Apache Kafka 4.4 (modificada el 22 de octubre de 2026) — la transmisión de eventos como equivalente digital del sistema nervioso central; usos como el procesamiento de pagos en tiempo real; tres capacidades: publicar y suscribirse, guardar de forma duradera, procesar; clúster de servidores y clientes; brokers; tolerancia a fallas; evento también llamado registro o mensaje, con clave, valor, marca de tiempo y cabeceras; productores y consumidores desacoplados, los productores nunca esperan a los consumidores; tópicos como carpetas, multiproductor y multisuscriptor; los eventos no se borran al consumirse; retención por tópico; particiones; misma clave, misma partición; orden garantizado dentro de la partición; servicios gestionados de varios proveedores; Kafka Connect. Apache Kafka: Introduction 4.4 — Consultada: 2026-11-14.
5. The Apache Software Foundation. Quick Start, documentación de Apache Kafka 4.4 (modificada el 26 de octubre de 2026) — requiere Java 17 o posterior; generar el identificador del clúster, formatear el directorio con «kafka-storage.sh format –standalone» y arrancar con «kafka-server-start.sh»; crear un tópico y usar el productor y el consumidor de consola. Apache Kafka: Quick Start 4.4 — Consultada: 2026-11-14.
6. The Apache Software Foundation. Topic Configs, documentación de Apache Kafka 4.4 — retention.ms (por defecto 604800000, 7 días; -1 sin límite), retention.bytes (por defecto -1; límite por partición, multiplicar por el número de particiones), cleanup.policy (por defecto delete; compact conserva el último valor de cada clave), min.insync.replicas con el escenario típico de factor 3, mínimo 2 y acks all. Apache Kafka: Topic Configs 4.4 — Consultada: 2026-11-14.
7. The Apache Software Foundation. Producer Configs, documentación de Apache Kafka 4.4 — acks 0, 1 o all (por defecto all); enable.idempotence (por defecto true) asegura una sola copia de cada mensaje y se desactiva si hay configuraciones en conflicto; retries: preferir delivery.timeout.ms; partición elegida por hash de la clave si hay clave y no se indica partición. Apache Kafka: Producer Configs 4.4 — Consultada: 2026-11-14.
8. The Apache Software Foundation. Basic Kafka Operations, documentación de Apache Kafka 4.4 — factor de réplica recomendado de 2 o 3; cada partición debe caber en un solo servidor; el número de particiones fija el paralelismo máximo de los consumidores; al aumentar particiones cambia el destino de las claves y no se redistribuyen los datos existentes; «kafka-consumer-groups.sh –describe» muestra posición y retraso. Apache Kafka: Basic Operations 4.4 — Consultada: 2026-11-14.
9. The Apache Software Foundation. Upgrading, documentación de Apache Kafka 4.4 (modificada el 26 de octubre de 2026) — Kafka 4.0, 4.2 y 4.3 solo admiten el modo KRaft; el modo ZooKeeper fue eliminado; 3.3.x fue la primera versión en que KRaft se consideró listo para producción. Apache Kafka: Upgrading 4.4 — Consultada: 2026-11-14.
10. The Apache Software Foundation. KRaft vs ZooKeeper, documentación de Apache Kafka 4.4 — en modo KRaft Kafka elimina su dependencia de ZooKeeper; los controladores administran los metadatos y usan el protocolo Raft. Apache Kafka: KRaft vs ZooKeeper 4.4 — Consultada: 2026-11-14.
11. The Apache Software Foundation. KRaft, documentación de Apache Kafka 4.4 — roles de broker, controlador o ambos; el modo combinado sirve para casos pequeños como desarrollo y no se recomienda en despliegues críticos; normalmente 3 o 5 controladores; con 3 se tolera 1 falla y con 5, 2; la migración exige una versión puente y la última es la 3.9. Apache Kafka: KRaft 4.4 — Consultada: 2026-11-14.
12. The Apache Software Foundation. Java Version, documentación de Apache Kafka 4.4 — Java 17, 21 y 25 con soporte completo; se recomienda la LTS más reciente. Apache Kafka: Java Version 4.4 — Consultada: 2026-11-14.
13. The Apache Software Foundation. Use Cases, documentación de Apache Kafka 4.4 — mensajería, seguimiento de actividad de sitios web (caso de uso original), métricas, agregación de logs, procesamiento en etapas, event sourcing y commit log. Apache Kafka: Use Cases 4.4 — Consultada: 2026-11-14.
14. The Apache Software Foundation. Structured Streaming + Kafka Integration Guide, documentación de Apache Spark 4.3.0 — integración de Structured Streaming para leer datos de Kafka y escribir datos en Kafka. Apache Spark: Kafka Integration Guide — Consultada: 2026-11-14.
15. The Apache Software Foundation. Licenses — todo el software producido por la Fundación Apache o sus proyectos se licencia según los documentos listados; la Apache License 2.0 es su licencia actual. Apache: Licenses — Consultada: 2026-11-14.
16. The Apache Software Foundation. Monitoring, documentación de Apache Kafka 4.4 — métrica records-lag-max: número de mensajes que el consumidor va detrás del productor, publicada por el consumidor. Apache Kafka: Monitoring 4.4 — Consultada: 2026-11-14.

Cómo investigamos esta página

• Pregunta que responde: Qué es Apache Kafka, cómo organiza los eventos, qué garantiza, cuándo conviene y cómo se ve un primer productor y consumidor.
• Fuentes: identificadas 32 → incluidas 16
• Criterios de inclusión: documentación oficial de Kafka 4.4 y de la Fundación Apache, más el artículo fundacional de 2011; sin blogs, cursos ni enciclopedias.
• Fecha de corte de los datos: 2026-11-14