bitdrift publica blob-stream, una alternativa a Kafka con brokers sin estado
El proyecto de bitdrift imita las semánticas de Kafka pero elimina el estado local de los brokers y el tráfico entre zonas. El precio: depender de relojes muy precisos.
bitdrift ha publicado blob-stream, un sistema de streaming que se parece a Kafka por fuera pero toma dos decisiones muy distintas por dentro: los brokers no guardan nada en disco y nada viaja entre zonas de disponibilidad.
La motivación es operativa. La propia compañía reconoce que administrar el almacenamiento de los brokers de Kafka les resultaba tan engorroso que dejaron de intentarlo: levantaban un clúster nuevo, cortaban el tráfico hacia él con cuidado y borraban el anterior. blob-stream quiere que ese baile no haga falta.
De puertas afuera las semánticas son las conocidas: topics y particiones, productores que reparten registros por una clave para mantener localidad, envío por lotes al broker que posee la partición y acuse de recibo solo cuando el registro ya es durable. Los consumidores se agrupan, se reparten particiones y trabajan con commit, seek, asignación y revocación. El broker es un binario suelto y hay bibliotecas de productor y consumidor en Rust, con el papel que cumple librdkafka en el ecosistema de Kafka.
Particiones locales a la zona y brokers sin estado
Cada zona de disponibilidad recibe un writer ID —en un despliegue de tres zonas, del 0 al 2— y las particiones son locales a esa zona. Cada partición lógica se convierte así en varias particiones virtuales, una por zona, y un mismo consumidor no tiene por qué quedarse con todas. El precio: hoy no se puede garantizar orden global por clave de registro dentro de una sola partición. El anuncio sostiene que probablemente tenga solución más adelante.
El descubrimiento de brokers lo hace Kubernetes, y un hash consistente decide qué broker recibe qué particiones. Para reservar rangos de offset y escribir bloques durables, cada broker pide leases en DynamoDB. Como no hay estado local, un broker puede rotar o autoescalar sin parar el servicio.
El reloj no es un detalle
blob-stream exige relojes precisos y sincronizados entre brokers y consumidores. Está diseñado contra el servicio de sincronización horaria de AWS, que usa relojes atómicos y GPS, en la línea de TrueTime de Google. De ahí sale la reducción de bloqueos, y de ahí sale también la dependencia: si el reloj se va, las garantías se van con él. La documentación de diseño del repositorio entra en ese detalle.
Los objetivos que bitdrift pone por delante son no gastar red entre zonas, no necesitar planos de control propios más allá de Kubernetes y costar menos que las alternativas sin disco. Esa última parte es una afirmación suya: el anuncio no trae comparativas ni cifras de rendimiento, y tampoco aclara la licencia del proyecto. Para quien opera streaming a volumen la propuesta es atractiva sobre el papel; queda por ver si el ahorro se sostiene fuera de AWS y con cargas que necesiten orden global.
