What this adds beyond Kafka
How the protocol compares with an event-streaming bus, and what a plain event bus does better.
Audience: both (developer-leaning) · Read route: understand
Developers who reach for an event-streaming platform often ask whether there is anything better. This is a different tool for a different problem. Kafka moves high volumes of messages inside infrastructure you operate and trust. The base protocol is built for audit-grade data sharing between organisations that do not trust each other's infrastructure: every exchange is signed, encrypted per field, anchored to a shared public audit layer, and independently verifiable.
This page sets out what the base protocol adds, and, just as plainly, what Kafka does better, so you can choose on the merits.
The delta
| Kafka concept | Base-protocol concept | What it adds |
|---|---|---|
| Topic, an append-only event log | A shared, signed stream of recorded actions | A cryptographically anchored, signed recording that is tamper-evident, not only append-only. |
| Consumer replay from an offset | Deterministic replay into your own state | An irrefutable log: every deviation is detectable and provable, not merely repeatable. |
| The broker operator is trusted for ordering | The protocol secures ordering and verifiability | Trust the protocol, not the operator: ordering is independently verifiable without trusting the administrator. |
| Payload in plaintext, with transport encryption only | Field-level encryption on by default | Data stays at the source; only what is necessary is disclosed, selectively, per field. |
| Access-control lists and authentication per cluster | Delegation-based identity | Auditable, revocable mandates aligned with eIDAS, on open identity standards; who may do what is itself part of the verifiable log. |
| Cross-cluster mirroring copies bytes between clusters | Cross-organisation reference: proof travels with the reference, verified independently | A chained, point-in-time reference the recipient verifies for itself, with no runtime coupling, no shared live connection, and no mutual infra trust. |
| A schema-registry add-on | An open envelope and wire format on published standards | Self-rebuildable; no vendor dependency for interoperability. |
| Each organisation runs one cluster | Each organisation runs its own node, federated | No vendor dependency and portable; control stays with the organisation, and the data can be retrieved by any party through the open protocol. |
The four axes this covers are cryptographic trust, identity and delegation, audit-anchoring with replay-verifiability, and cross-organisation reference.
What Kafka does better
On these points Kafka is the stronger tool:
- Raw throughput and horizontal scale on volume. Kafka is built for orders of magnitude higher throughput on a single cluster, at low latency. Cryptographic anchoring and per-field verification cost work; for high-volume, real-time pipelines Kafka wins comfortably.
- A mature ecosystem. Kafka Connect brings hundreds of ready-made connectors, and Kafka Streams and ksqlDB give a complete stream-processing stack out of the box. That ecosystem is years ahead.
- Operational maturity and community. Battle-tested operations tooling, monitoring, a large community, and a deep hiring pool: engineers who already know Kafka are everywhere. That is a real and hard-to-match advantage.
- Native partition ordering. Kafka's partition model gives per-partition ordering as a built-in, without an external anchoring step.
If you are building real-time analytics inside a single cluster, use Kafka.
The trade in one line
The base protocol trades raw throughput for cryptographic trust and cross-organisation verifiability. It is there for audit-grade data sharing between organisations that do not trust each other's infrastructure. For the neutrality argument in decision-maker terms, see avoiding vendor lock-in; for how anchoring and verification work underneath, see anchoring and the audit log.
Getting started
Walk through mapping out a first interoperable integration, with a copyable configuration and code marked non-translatable.
Governance and working group
The open licence, the public working group, the initiator and first maintainer, the hand-over clause, and how forking keeps versions and maintainers accountable.