Tansu предлагает пересобрать Kafka-модель: убрать состояние из брокеров и делегировать надежность внешнему хранилищу. Это меняет поведение системы под нагрузкой и упрощает операционную модель.
Проблема проявляется на уровне эксплуатации. Классический Kafka-брокер — это stateful-компонент: репликация, лидер-элекции, постоянное состояние, длительное время жизни. Такие узлы трудно масштабировать вниз, они требуют конфигурации и ресурсов (например, heap в гигабайтах). Система устойчива за счет внутренней сложности. Это работает, пока команда готова платить за операционную нагрузку и держать кластеры “всегда включенными”.
Tansu меняет предпосылку. Вместо репликации внутри брокеров он исходит из того, что хранилище уже обеспечивает durability. Брокеры становятся stateless: без лидеров, без локального состояния, с памятью порядка десятков мегабайт. Их можно масштабировать до нуля и поднимать за миллисекунды. Это компромисс: устойчивость больше не в слое брокера, а в выбранном backend-хранилище. Надежность системы теперь зависит от свойств S3, Postgres или другого backend.
Реализация строится вокруг pluggable storage. Backend задается через URL:
- S3-совместимые хранилища — для полностью diskless режима
- SQLite — для локальной разработки и тестов
- Postgres — для интеграции со стримингом и транзакциями
В случае Postgres архитектура упрощается до примитивов БД: produce — это INSERT или COPY, fetch — это SELECT. Узким местом стали последовательные INSERT из-за round-trip на каждую запись. Это заменили на COPY FROM: один setup, поток COPY DATA, финальный COPY DONE. Такой режим убирает подтверждения на каждую запись и увеличивает throughput при batch-записи.
Дополнительно исчезает необходимость в transactional outbox. Сообщение и бизнес-данные можно записать атомарно в одной транзакции через stored procedure. Это устраняет типичный разрыв между БД и брокером.
Валидация схемы перенесена на брокер. В Kafka она обычно на стороне клиента и опциональна. В Tansu брокер проверяет каждую запись (Avro, JSON, Protobuf) перед записью. Это замедляет обработку (нужно распаковать и валидировать), но гарантирует консистентность независимо от клиента. Этот же механизм позволяет писать данные напрямую в аналитические форматы (Iceberg, Delta, Parquet). Через “sink topic” можно миновать промежуточное хранение и сразу формировать таблицы.
Как прокси, Tansu может стоять перед Kafka-кластером. Заявлены ~60k записей в секунду и P99 latency ниже миллисекунды на скромном железе, с потреблением около 13 МБ RAM. Это показывает, что stateless-слой может быть легким, если убрать обязанности по хранению.
Итог — это сдвиг ответственности. Брокер становится вычислительным слоем без состояния. Хранилище — источником истины. Операционно это упрощает масштабирование и деплой (вплоть до минимальных контейнеров без ОС). Но появляются новые зависимости: свойства storage, его latency и ограничения напрямую влияют на поведение системы. Часть функций Kafka пока отсутствует (например, throttling, ACL, compaction для S3), что ограничивает сценарии использования.
Подход выглядит как прагматичное упрощение для сред, где внешнее хранилище уже является надежным и управляемым компонентом.