Redpanda: alternativa a Kafka con otra arquitectura
Actualizado: 2026-05-03
Hablar de streaming de eventos en 2025 ya no es hablar solo de Apache Kafka. Redpanda lleva varios años posicionándose como alternativa compatible con el protocolo Kafka pero construida sobre una base muy distinta, y en los últimos meses hay suficientes casos de producción como para tomarla en serio. El atractivo no está en ofrecer algo radicalmente nuevo, sino en mantener el protocolo al que ya está enganchada media industria y cambiar todo lo que hay debajo.
Puntos clave
- Redpanda es un motor de streaming en C++ que habla el protocolo Kafka a nivel de cable: las aplicaciones, librerías y conectores existentes funcionan sin cambios.
- La arquitectura thread-per-core con Seastar elimina el GC de JVM, reduce la tail latency y hace el uso de CPU más predecible.
- Sin ZooKeeper, sin JVM, sin Kafka Connect separado: la superficie operativa es notablemente menor.
- La compatibilidad con Kafka es alta para cargas estándar; funcionalidades muy recientes de Kafka Streams o el Schema Registry pueden requerir pruebas específicas.
- Tiene sentido para equipos que parten de cero o donde la operación de Kafka ha sido un dolor recurrente. Para clusters Kafka estables con equipo experimentado, el cambio rara vez se justifica.
Qué es Redpanda y por qué existe
Redpanda es un motor de streaming escrito en C++ que habla el protocolo Kafka a nivel de cable. Esto significa que las aplicaciones existentes, las librerías cliente y los conectores de Kafka funcionan sin cambios. Desde el punto de vista del desarrollador es Kafka; desde el punto de vista del operador es otra cosa.
La decisión de mantener el protocolo y cambiar la implementación responde a una realidad incómoda: el ecosistema Kafka es gigantesco, pero la operación del propio Apache Kafka es más dolorosa de lo que debería. ZooKeeper como dependencia separada, el tuning de JVM, el rebalanceo de particiones, las pausas de GC que rompen la latencia. El proyecto Kafka lleva años moviéndose hacia KRaft para eliminar ZooKeeper y ya está estable, pero el resto de problemas sigue ahí. Redpanda se plantea eliminarlos de raíz.
La arquitectura thread-per-core
El punto más diferencial de Redpanda es su motor basado en Seastar[1], el mismo entorno que usa ScyllaDB. Seastar sigue el modelo thread-per-core: cada hilo está fijado a un núcleo físico y tiene su propia cola de trabajo, sin locks compartidos entre hilos. La comunicación entre núcleos se hace por paso de mensajes, no por memoria compartida con candados.
Las implicaciones concretas de rendimiento son tres:
- Tail latency baja significativamente porque no hay pausas de recolección de basura.
- El uso de CPU es más predecible porque no hay planificación agresiva entre hilos.
- Red y disco se manejan con E/S asíncrona directa sobre el kernel Linux, sin las capas de abstracción del JVM.
La contrapartida es que Redpanda es más sensible al hardware subyacente. En máquinas pequeñas o virtualizadas con CPU compartida, el modelo thread-per-core no luce tanto. En máquinas dedicadas con muchos núcleos y discos NVMe rápidos, la diferencia con Kafka es medible. Redpanda reporta hasta diez veces mejor latencia p99 en cargas mixtas, aunque estos números conviene verificarlos en el propio entorno.
Sin ZooKeeper, sin JVM, sin Connect separado
Redpanda elimina las dependencias que Kafka arrastra:
- Sin ZooKeeper: el consenso está integrado en el propio broker mediante Raft, igual que KRaft en Kafka moderno.
- Sin JVM: es un binario nativo compilado; una imagen de contenedor de unos 200 MB frente a imágenes de Kafka que pueden superar el gigabyte.
- Sin Kafka Connect separado: existe un componente interno llamado Redpanda Connect basado en Benthos.
Desplegar Redpanda significa copiar un binario y arrancarlo. La configuración inicial cabe en un fichero YAML corto. Esto no es magia: las funcionalidades complejas siguen existiendo, solo están mejor integradas. Para equipos sin experiencia operando JVM en producción, eliminar el tuning de GC y las pausas stop-the-world es un alivio real.
Compatibilidad real con Kafka
La pregunta más importante al evaluar Redpanda es hasta qué punto es realmente compatible con Kafka. La respuesta corta: en la mayoría de casos prácticos, sí. El protocolo está implementado al nivel necesario para que los clientes oficiales de Java, Python, Go, Rust y otros funcionen sin cambios. Los conectores de Debezium para captura de cambios funcionan. Las librerías de alto nivel como kafka-streams también funcionan, aunque con algunas limitaciones en funcionalidades muy recientes.
Donde hay que tener cuidado es en funcionalidades específicas de Kafka que llegan primero a Apache Kafka y después a Redpanda: algunas transacciones idempotentes, características recientes de Kafka Streams, y el propio Schema Registry tienen su propia implementación en Redpanda que es compatible pero no idéntica. Para cargas estándar de publicación y consumo esto no importa; para arquitecturas que exprimen las funcionalidades al límite hay que hacer pruebas específicas.
El análisis de bases de datos para arquitecturas de streaming conecta con los patrones que describimos en Kafka para streaming de eventos y la estrategia de LLM routing que aparece en LLM routing multi-modelo muestra cómo el mismo patrón de selección se aplica a diferentes capas del stack.
Cuándo compensa y cuándo no
Redpanda compensa cuando:
- La operación de Kafka ha sido un punto de dolor recurrente.
- El equipo no tiene experiencia acumulada en JVM.
- Se parte de cero con cargas nuevas.
Redpanda no compensa cuando:
- Los clusters Kafka ya son estables y el equipo domina el ecosistema.
- El coste de licencia es determinante: la versión de comunidad de Redpanda usa BSL (Business Source License), que se convierte en Apache 2.0 pasados cuatro años, mientras que Apache Kafka es Apache 2.0 puro.
- Se necesita integración con cada conector y herramienta del ecosistema Kafka, que sigue siendo más profundo.
En 2025 ya no es una apuesta arriesgada elegir Redpanda para cargas nuevas; sigue siendo una migración costosa para cargas existentes.
