Apache Kafka explicado: guía 2026, arquitectura, KRaft y formas de despliegue

📅 Última actualización: 16 de abril de 2026 · ✍️ Por Redacción Maketeceasy

Apache Kafka es el sistema de mensajería distribuido más usado del mundo para mover datos en tiempo real entre sistemas. Cuando piensas en «streaming de eventos», «event-driven» o «datos en tiempo real», el nombre que aparece es Kafka. En esta guía te explicamos qué es, cómo funciona por dentro, las formas modernas de desplegarlo y cómo se usa en arquitecturas reales, con el criterio de alguien que lleva años diseñando pipelines en producción.

¿Qué es Apache Kafka?

Apache Kafka es una plataforma distribuida de streaming de eventos. Permite publicar, almacenar y consumir flujos de datos en tiempo real de forma duradera, tolerante a fallos y con un rendimiento muy alto (millones de eventos por segundo por cluster medio).

Fue creado en LinkedIn en 2011 y liberado a la Apache Software Foundation. Hoy lo usan prácticamente todas las empresas tecnológicas de cierto tamaño: Netflix, Uber, Airbnb, PayPal, LinkedIn, BBVA, Zalando, y miles más.

Conceptualmente se parece a una cola de mensajes tipo RabbitMQ, pero con una diferencia fundamental: los mensajes no se borran al consumirlos. Quedan en el topic por un tiempo configurable (horas, días o para siempre) y múltiples consumidores pueden leerlos de forma independiente, cada uno a su ritmo.

Los conceptos básicos de Kafka

• Producer: aplicación que publica mensajes en Kafka.
• Consumer: aplicación que lee mensajes.
• Topic: categoría o canal donde se publican los mensajes. Ejemplo: orders, payments, user-events.
• Partición: subdivisión interna de un topic. Habilita el paralelismo y el orden garantizado dentro de cada partición.
• Offset: posición de un mensaje dentro de una partición. Los consumidores avanzan por offset.
• Broker: un nodo del cluster Kafka. Un cluster tiene típicamente 3-9 brokers.
• Consumer Group: conjunto de consumidores que se reparten la lectura de un topic. Cada partición la consume un único miembro del grupo en un momento dado.
• Replicación: cada partición tiene copias en varios brokers para tolerancia a fallos.

Con estos siete conceptos entiendes el 90% de Kafka.

Cómo funciona Kafka por dentro

Kafka almacena los mensajes como un log inmutable, ordenado y append-only. Cada partición es físicamente una secuencia de ficheros en disco, segmentados por tamaño o tiempo. Esta estructura tan simple es la clave de su rendimiento brutal:

• Escrituras secuenciales: los discos son mucho más rápidos escribiendo secuencial que aleatoriamente.
• Zero-copy: los datos viajan del disco a la red sin pasar por la memoria de usuario del broker.
• Sin acoplamiento temporal: productores y consumidores no se conocen ni se sincronizan.
• Horizontal scaling: añadir brokers al cluster reparte la carga automáticamente.

La ordenación se garantiza dentro de cada partición, no entre particiones. Si necesitas orden global debes usar una sola partición (y sacrificar paralelismo) o asegurarte de que los mensajes relacionados comparten key (lo que garantiza que vayan a la misma partición).

KRaft: adiós a ZooKeeper

Durante años, Kafka dependió de Apache ZooKeeper para gestionar metadatos, elecciones de líder y coordinación. ZooKeeper era, honestamente, el punto débil: añadía un segundo sistema distribuido que operar y limitaba la escalabilidad.

Desde Kafka 3.3 está disponible como producción KRaft (Kafka Raft), el modo en el que el propio cluster Kafka gestiona sus metadatos internamente usando el protocolo Raft. Desde Kafka 4.0 (2025), ZooKeeper queda oficialmente deprecado y ya no se soporta.

Ventajas de KRaft:

• Un solo sistema que operar, menos componentes moviéndose.
• Arranque mucho más rápido (de minutos a segundos).
• Soporte para clusters con millones de particiones (ZooKeeper limitaba a unos pocos cientos de miles).
• Menor latencia en eventos de control del cluster (elecciones, rebalanceos).

Si vas a montar un cluster nuevo en 2026, usa KRaft directamente. Sin excepciones.

Formas de desplegar Kafka

1. Apache Kafka autogestionado (self-managed)

Descargas Kafka, lo instalas en tus servidores (VMs o bare-metal) y tú te encargas de todo: provisioning, upgrades, parches de seguridad, backups, monitoring, escalado. Es el modelo más barato en licencias pero el más caro en operación. Tiene sentido si ya tienes un equipo dedicado de platform engineering.

2. Confluent Platform

Distribución empresarial de Kafka ofrecida por Confluent (empresa fundada por los creadores originales). Añade herramientas útiles: Control Center, ksqlDB, conectores certificados, REST Proxy, Schema Registry, seguridad avanzada. Se instala on-premise o en la nube que elijas.

3. Confluent Cloud

Kafka as a Service totalmente gestionado por Confluent, disponible en AWS, Azure y GCP. Pagas por uso (ingesta, retención, egreso). La opción recomendada cuando quieres cero operación y estás dispuesto a pagar el coste premium.

4. Amazon MSK

Kafka gestionado por AWS. Dos variantes:

• MSK Provisioned: configuras brokers y pagas por nodo.
• MSK Serverless: sin gestión de infraestructura, pagas por ingesta y retención. Ideal para cargas variables.

5. Azure Event Hubs (protocolo Kafka)

Event Hubs ofrece una interfaz compatible con Kafka. Tus aplicaciones hablan Kafka pero por debajo corre el motor propietario de Azure. Ideal si ya estás en Azure y no quieres mantener un cluster Kafka puro.

6. Strimzi en Kubernetes

Strimzi es un Operator de Kubernetes que automatiza todo el ciclo de vida de un cluster Kafka: despliegue, upgrades, escalado, monitorización. Es la opción favorita en entornos donde ya se usa K8s intensivamente y se quiere mantener control total sin comprar licencias.

7. Redpanda

Alternativa API-compatible con Kafka reescrita en C++, sin JVM y sin ZooKeeper desde el inicio. Promete menor latencia y operación más simple. No es Kafka, pero tus clientes Kafka funcionan contra él.

Opción	Mejor para	Contras
Kafka self-managed	Control total, sin licencias	Operación costosa
Confluent Platform	Funciones empresariales avanzadas	Licencias caras
Confluent Cloud	Cero ops, cualquier nube	Coste alto en volumen
AWS MSK	Equipos ya en AWS	Solo AWS
Event Hubs (Kafka API)	Equipos en Azure, menos carga ops	No es Kafka 100%
Strimzi en K8s	Equipos con madurez K8s	Curva de aprendizaje K8s
Redpanda	Latencia mínima, operación simple	Ecosistema más joven

Kafka Connect y Kafka Streams

Dos componentes del ecosistema que conviene conocer:

Kafka Connect

Framework para mover datos entre Kafka y sistemas externos sin escribir código: bases de datos (Postgres, MySQL, MongoDB), Data Warehouses (Snowflake, BigQuery), S3/ADLS, Elasticsearch, etc. Los conectores están listos para usar y gestionan offsets, reintentos y escalado.

Kafka Streams

Librería Java/Scala para construir aplicaciones de procesamiento en tiempo real que leen, transforman y escriben a Kafka sin necesidad de un cluster separado (a diferencia de Flink o Spark). Ideal para microservicios event-driven con lógica de negocio.

Schema Registry y evolución de esquemas

En un sistema basado en eventos, los mensajes vivos en un topic pueden ser escritos hoy pero consumidos mañana, o el año que viene. Si cambias el esquema de un evento sin cuidado, puedes romper consumidores existentes.

La solución es el Schema Registry: un servicio (parte de Confluent o disponible en Apicurio, AWS Glue Schema Registry) donde se registran los esquemas (Avro, Protobuf o JSON Schema) y se valida que los cambios son compatibles hacia atrás/adelante. Es una pieza obligatoria en arquitecturas serias.

Casos reales de uso de Kafka

🔄 Change Data Capture (CDC) desde bases de datos operacionales

Usando Debezium sobre Kafka Connect, los cambios de una base de datos (INSERTs, UPDATEs, DELETEs) se convierten en eventos Kafka que alimentan Data Lakes, caches, motores de búsqueda, notificaciones y analítica en tiempo real.

📈 Pipelines analíticos en tiempo real

Kafka como buffer entre sistemas operacionales y plataformas analíticas (Spark Structured Streaming, Flink, Databricks). Permite absorber picos de tráfico y desacoplar productores y consumidores.

🏗️ Arquitecturas event-driven

Microservicios que se comunican por eventos en lugar de llamadas síncronas HTTP. Mejora la desacoplamiento y la resiliencia ante fallos. Patrones clásicos: Event Sourcing, CQRS, Saga.

📡 Ingesta de IoT y telemetría

Dispositivos que emiten métricas cada pocos segundos. Kafka absorbe millones de eventos por segundo, los enruta a sistemas de alertas, dashboards y almacenamiento analítico.

📝 Log aggregation

Centralización de logs de cientos o miles de servicios en topics Kafka que alimentan Elasticsearch, Splunk, Grafana Loki u otros sistemas de análisis.

Los 6 errores más habituales con Kafka

1. Diseñar sin pensar en el particionado. El número de particiones fija tu paralelismo máximo de consumo y es muy doloroso cambiarlo después.
2. Usar mensajes grandes (> 1 MB). Kafka no está pensado para eso. Si los necesitas, guarda el payload en S3/ADLS y publica solo una referencia en Kafka.
3. Ignorar el Schema Registry. Tarde o temprano alguien romperá un consumidor productivo por cambiar un campo.
4. Mal dimensionado de retención. Retener todo «por si acaso» dispara el coste de disco; retener muy poco impide reprocesar cuando aparece un bug.
5. Mezclar topics de cargas muy distintas. Un topic de baja latencia y otro de análisis batch conviene tenerlos separados.
6. No monitorizar lag de consumo. El consumer lag creciente es la señal temprana de que algo va mal. Prometheus + Grafana es el stack estándar.

Tu primer productor y consumidor Kafka en Python

Ejemplo mínimo funcional con confluent-kafka, la librería recomendada por estabilidad y rendimiento.

Instalación

pip install confluent-kafka

Productor básico

from confluent_kafka import Producer
import json, time

p = Producer({
    'bootstrap.servers': 'localhost:9092',
    'client.id': 'demo-producer',
    'acks': 'all',
    'enable.idempotence': True
})

def delivery(err, msg):
    if err:
        print(f"Error: {err}")
    else:
        print(f"→ {msg.topic()}[{msg.partition()}]@{msg.offset()}")

for i in range(10):
    evento = {"id": i, "importe": 100 + i, "ts": time.time()}
    p.produce('transacciones',
              key=str(i).encode(),
              value=json.dumps(evento).encode(),
              on_delivery=delivery)
    p.poll(0)

p.flush()

Consumidor con consumer group

from confluent_kafka import Consumer
import json

c = Consumer({
    'bootstrap.servers': 'localhost:9092',
    'group.id': 'demo-group',
    'auto.offset.reset': 'earliest',
    'enable.auto.commit': False
})
c.subscribe(['transacciones'])

try:
    while True:
        msg = c.poll(1.0)
        if msg is None: continue
        if msg.error():
            print(msg.error()); continue
        evento = json.loads(msg.value())
        print(f"Recibido: {evento}")
        c.commit(msg)  # commit manual tras procesar
except KeyboardInterrupt:
    pass
finally:
    c.close()

Cluster local con Docker Compose (KRaft)

version: '3'
services:
  kafka:
    image: apache/kafka:3.9.0
    ports:
      - "9092:9092"
    environment:
      KAFKA_NODE_ID: 1
      KAFKA_PROCESS_ROLES: broker,controller
      KAFKA_CONTROLLER_QUORUM_VOTERS: 1@kafka:9093
      KAFKA_LISTENERS: PLAINTEXT://:9092,CONTROLLER://:9093
      KAFKA_ADVERTISED_LISTENERS: PLAINTEXT://localhost:9092
      KAFKA_CONTROLLER_LISTENER_NAMES: CONTROLLER
      KAFKA_INTER_BROKER_LISTENER_NAME: PLAINTEXT
      KAFKA_LISTENER_SECURITY_PROTOCOL_MAP: PLAINTEXT:PLAINTEXT,CONTROLLER:PLAINTEXT
      CLUSTER_ID: 4L6g3nShT-eMCtK--X86sw

Levántalo con docker compose up -d y tendrás un broker Kafka single-node en KRaft listo en tu portátil.

Cómo dimensionar un cluster Kafka en producción

Estimaciones orientativas basadas en clusters reales. Sirven como punto de partida; ajusta tras medir tu carga real.

Throughput objetivo	Brokers	Particiones por topic «caliente»	Disco por broker	Notas
< 10 k msg/s	3	6	500 GB SSD	Suficiente para la mayoría de startups.
10-100 k msg/s	3-5	12-24	1-2 TB SSD	Empresas medianas.
100 k – 1 M msg/s	6-12	32-64	2-4 TB NVMe	Separar MM2 / MirrorMaker en nodos aparte.
> 1 M msg/s	12+	64-256	4+ TB NVMe	Considera KRaft + hardware dedicado.

Reglas prácticas

• Particiones ≈ paralelismo máximo. Si vas a tener 16 consumidores, mínimo 16 particiones.
• No pases de 200k particiones por cluster (incluso con KRaft). Causa problemas de metadata.
• Replication factor 3 para producción, siempre. min.insync.replicas=2.
• Retención: 7 días para eventos típicos, ilimitada solo en topics tipo «source of truth» con compacted.
• Separa topics de distinta prioridad. No mezcles un topic de telemetría con uno de facturación.
• JVM: heap 6-8 GB suele ser suficiente. Más no ayuda; el resto de RAM va a page cache del sistema.

Seguridad en Kafka: mTLS, SASL y ACLs

Un Kafka sin seguridad es un buffet abierto. En producción, los tres pilares son:

• Encriptación en tránsito con TLS: tráfico cliente↔broker y broker↔broker cifrado.
• Autenticación: normalmente SASL (SCRAM, GSSAPI/Kerberos o PLAIN sobre TLS) o mTLS con certificados por cliente.
• Autorización con ACLs: qué usuario puede producir/consumir en qué topic/grupo.

Ejemplo de ACL

# Permitir al servicio "pagos" producir en el topic "pagos-eventos"
kafka-acls --bootstrap-server kafka:9092 \
  --add --allow-principal User:servicio-pagos \
  --operation Write --topic pagos-eventos

# Permitir a "analytics" consumir
kafka-acls --bootstrap-server kafka:9092 \
  --add --allow-principal User:servicio-analytics \
  --operation Read --topic pagos-eventos \
  --group analytics-group

Una buena arquitectura de seguridad usa principio de mínimo privilegio: cada servicio tiene credenciales propias, acceso solo a los topics que necesita y permisos mínimos (producer vs consumer).

Caso real: CDC con Debezium para 2.000M eventos al día

Una entidad del sector financiero necesitaba consolidar datos de 14 bases de datos operacionales (Oracle y PostgreSQL) en una plataforma analítica moderna sin imponer carga a los sistemas transaccionales.

La arquitectura elegida

• Debezium sobre Kafka Connect leyendo el log de transacciones (LogMiner en Oracle, WAL en PostgreSQL).
• Kafka gestionado con MSK (AWS), 6 brokers m5.2xlarge y 3 TB NVMe cada uno.
• Schema Registry (Confluent) con evolución compatible hacia atrás obligatoria.
• Spark Structured Streaming consumiendo los eventos y aterrizándolos en Delta Lake Bronze.
• Separación por dominio: un topic por tabla, convenciones de nombres estrictas.