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 he visto suficientes casos de producción como para tomarla en serio. El atractivo de Redpanda 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.
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 empresa detrás es Redpanda Data, antes Vectorized, fundada por Alex Gallego, ingeniero que antes trabajó en sistemas de baja latencia en el sector financiero.
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 JVM tuning, el rebalanceo de particiones, el GC con picos 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, 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.
Esto tiene implicaciones concretas de rendimiento. Primero, la latencia en cola larga, lo que en inglés llaman tail latency, baja mucho porque no hay pausas de recolección de basura. Segundo, el uso de CPU es más predecible porque no hay planificación agresiva entre hilos. Tercero, la red y el disco se manejan con entrada/salida 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 y significativa. Redpanda públicamente reporta hasta 10 veces mejor latencia p99 en cargas mixtas, aunque estos números conviene verificarlos en el propio entorno antes de creérselos.
Sin ZooKeeper, sin JVM, sin Connect
Redpanda elimina dependencias que Kafka arrastra. No hay ZooKeeper porque el consenso está integrado en el propio broker mediante Raft, igual que KRaft en Kafka moderno. No hay JVM porque es un binario nativo compilado. No hay Kafka Connect como sistema separado, aunque sí existe un componente interno llamado Redpanda Connect basado en Benthos. Estas decisiones reducen la superficie operativa.
En la práctica, desplegar Redpanda significa copiar un binario y arrancarlo. En contenedor, una imagen de unos doscientos megabytes frente a imágenes de Kafka que pueden superar el giga cuando incluyen JRE. La configuración inicial cabe en un fichero YAML corto. Esto no es magia: las funcionalidades complejas siguen existiendo, solo están mejor integradas. Pero el camino del “hola mundo” al “tengo un cluster corriendo” es notablemente más corto.
La ausencia de JVM también significa que no hay que aprender tuning de GC, no hay que ajustar tamaños de heap, no hay que preocuparse por pausas stop-the-world. Para equipos que no tienen experiencia operando JVM en producción, esto es un alivio real. Para equipos que ya dominan Kafka y sus herramientas, es un argumento más débil.
Compatibilidad real con Kafka
La pregunta más importante al evaluar Redpanda es hasta qué punto es realmente compatible con Kafka. La respuesta corta es: 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 no son parte del protocolo estándar o que llegan primero a Apache Kafka y más tarde a Redpanda. Algunas transacciones idempotentes, algunas características de Kafka Streams muy nuevas, 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 funcionalidades de Kafka al límite hay que hacer pruebas específicas.
Cuándo compensa y cuándo no
Mi lectura después de ver varios despliegues es que Redpanda compensa cuando la operación de Kafka ha sido un punto de dolor recurrente o cuando se parte de cero sin experiencia acumulada en JVM. En equipos pequeños con pocos operadores, la reducción de superficie operativa es real. En empresas con clusters Kafka ya estables y equipo con dominio del ecosistema, el cambio rara vez justifica la migración.
Tampoco tiene sentido en entornos donde el coste de licencia es determinante. Redpanda tiene una versión de comunidad bajo BSL que se convierte en Apache 2.0 pasados cuatro años, y una versión Enterprise con funcionalidades añadidas bajo licencia comercial. Apache Kafka es Apache 2.0 puro. Para organizaciones que huyen de cualquier licencia con matices, Kafka sigue siendo la opción sin fricciones.
La decisión final suele depender de si el problema que tienes es de rendimiento, de complejidad operativa o de ecosistema. Si el rendimiento es el cuello de botella y las máquinas son modernas, Redpanda puede dar una mejora inmediata. Si la complejidad operativa es el problema, también. Si lo que necesitas es integración con cada conector y herramienta del mundo Kafka, el ecosistema original 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.
