El problema fundamental que Tansu aborda es la complejidad operativa y la rigidez de escalado inherente a los sistemas de mensajería distribuidos que gestionan su propia durabilidad y replicación, como Apache Kafka. Estos sistemas, aunque robustos, requieren una gestión intensiva de 'pets' (brokers con estado), lo que dificulta la elasticidad y el escalado a cero.
Tansu propone una arquitectura donde los brokers son 'cattle' sin estado, delegando la durabilidad y la resiliencia a sistemas de almacenamiento externos ya existentes y optimizados para ello (como S3 o PostgreSQL). Esta separación de responsabilidades permite que el broker se enfoque únicamente en la lógica del protocolo de mensajería, simplificando la operación y permitiendo una escalabilidad elástica y un consumo de recursos significativamente menor. La relevancia actual radica en la creciente demanda de arquitecturas serverless y el uso eficiente de la infraestructura en la nube, donde la gestión de estado distribuido es un desafío constante.
Arquitectura del Sistema
La arquitectura de Tansu se basa en brokers sin estado que implementan el protocolo Apache Kafka. La clave de su diseño es la pluggability del backend de almacenamiento, que puede ser S3 (o compatible como Tigris, R2), SQLite o PostgreSQL. Esta elección se realiza mediante un parámetro URL, permitiendo adaptar la persistencia a diferentes escenarios de uso.
Para la integración con PostgreSQL, Tansu optimiza la ingesta de datos utilizando el protocolo COPY FROM de PostgreSQL, que permite el streaming de filas sin la necesidad de confirmaciones individuales por cada INSERT, mejorando sustancialmente el throughput para la ingesta por lotes. Esto convierte una operación de produce en una serie de COPY DATA y un COPY DONE, y un fetch en un SELECT.
Una característica distintiva es la validación de esquemas en el broker. A diferencia de Kafka, donde la validación es opcional y se delega al cliente o a un Schema Registry externo, Tansu valida cada registro (Avro, JSON, Protobuf) antes de escribirlo, garantizando la consistencia de los datos. Esta capacidad de interpretación de esquemas también permite a Tansu escribir datos validados directamente en formatos de tabla abiertos como Apache Iceberg, Delta Lake o Parquet, actuando como un pipeline directo de productores Kafka-compatibles a datos listos para análisis. En este modo, una configuración de 'sink topic' omite el almacenamiento normal y escribe exclusivamente al formato de tabla abierta.
Flujo de Producción de Mensajes con Tansu (PostgreSQL Backend)
- 1 Cliente Kafka Envía mensaje al broker Tansu usando protocolo Kafka.
- 2 Broker Tansu Recibe mensaje, valida esquema (si configurado).
- 3 Broker Tansu Utiliza protocolo COPY FROM de PostgreSQL para streaming de datos.
- 4 PostgreSQL Almacena el mensaje de forma duradera.
- 5 Broker Tansu Confirma la producción al cliente (después de COPY DONE).
Flujo de Consumo de Mensajes con Tansu (PostgreSQL Backend)
- 1 Cliente Kafka Solicita mensajes al broker Tansu.
- 2 Broker Tansu Ejecuta una consulta SELECT en PostgreSQL.
- 3 PostgreSQL Retorna los mensajes solicitados.
- 4 Broker Tansu Envía mensajes al cliente Kafka.
| Capa | Tecnología | Justificación |
|---|---|---|
| messaging | Tansu | Broker de mensajería compatible con Apache Kafka, sin estado y con durabilidad delegada. vs Apache Kafka, Redpanda, NATS Streaming |
| storage | PostgreSQL | Backend de almacenamiento duradero para mensajes, aprovechando COPY FROM para alta ingesta. vs Apache Kafka (almacenamiento interno), Cassandra, MongoDB Uso del protocolo COPY FROM para ingesta en batch. |
| storage | Amazon S3 (o compatible) | Backend de almacenamiento duradero para operación sin disco, ideal para entornos serverless. vs HDFS, Google Cloud Storage, Azure Blob Storage |
| storage | SQLite | Backend de almacenamiento para entornos de desarrollo y pruebas locales. vs H2 Database, Hsqldb |
| data-processing | Apache Iceberg / Delta Lake / Parquet | Formatos de tabla abiertos para la escritura directa de datos validados desde Tansu, facilitando el análisis. vs Avro, ORC Configuración de 'sink topic' para escritura directa. |
Trade-offs
Ganancias
- ▲ Elasticidad y escalabilidad a cero
- ▲▲ Menor consumo de memoria por broker
- ▲ Simplificación operativa (brokers sin estado)
- ▲ Garantía de consistencia de datos (validación de esquema en broker)
- ▲ Integración directa con bases de datos y formatos de tabla abiertos
Costes
- △ Mayor latencia en la validación de esquema (descompresión y validación)
- ▲ Funcionalidades aún no implementadas (throttling, ACLs, share groups, compactación S3)
Fundamentos Teóricos
La separación de la capa de computación (broker) de la capa de almacenamiento (storage backend) en Tansu resuena con principios fundamentales de los sistemas distribuidos que buscan desacoplar componentes para mejorar la escalabilidad y la resiliencia. Este patrón se observa en arquitecturas de bases de datos modernas que separan el plano de control y el plano de datos, o la lógica de procesamiento de transacciones del almacenamiento de datos. Conceptos como el 'shared-nothing architecture' (aunque Tansu usa almacenamiento compartido, los brokers son shared-nothing) y la delegación de responsabilidades a servicios especializados son pilares en la construcción de sistemas a gran escala.
La idea de brokers sin estado que dependen de un almacenamiento duradero externo puede verse como una aplicación práctica de los principios de diseño de sistemas distribuidos tolerantes a fallos, donde la persistencia se externaliza para simplificar la lógica del componente de procesamiento. Esto se alinea con la evolución de los sistemas de bases de datos que han pasado de arquitecturas monolíticas a modelos donde el almacenamiento es un servicio independiente, como se discute en trabajos sobre la evolución de los sistemas de almacenamiento en la nube y bases de datos distribuidas que utilizan objetos de almacenamiento como S3 para su durabilidad subyacente.