Kafka clients are already everywhere. The log does not have to live on broker disks.

The protocol is the part worth keeping. The disk layout, the JVM, and a separate coordination service are the part that is expensive to operate. Camus speaks the wire protocol and stores the long-term log in object storage.

What stays

Producers, consumers, and admin tools keep working by changing the bootstrap address. The broker accepts the Kafka request framing those clients already send. It does not ask you to adopt a new client SDK.

That compatibility is pinned, not aspirational. The reference is the Apache Kafka 4.4.0 tree. A later KIP does not override that tree. Unimplemented APIs return a Kafka error. They do not pretend to succeed.

What moves

Record batches that have been sealed live as objects in Cloudflare R2, or in any S3-compatible bucket. MinIO is the local stand-in. The broker does not keep a full replica of the log on its own disk in the long run.

Metadata is different from the log. Topics, group membership, committed offsets, and transaction ranges have to be agreed quickly and exactly. Those live in a Raft group, encoded so that every broker applies the same commands in the same order.

Why there is still a write-ahead log

Waiting for an object upload on every produce makes acknowledgements as slow as the bucket. The default wal mode replicates a short log to a majority of a shard, fsyncs it, and acknowledges then. The upload follows. Once the range is sealed, that slice of the write-ahead log is truncated. It is a buffer, not the system of record.

The other mode, r2, skips that buffer. The produce is acknowledged only after the object is stored and the metadata group has committed the offsets. Brokers in that mode hold no log bytes. You take that trade when you would rather wait on the bucket than keep a local log. Both modes are described on the durability page.

What a deployment looks like

A handful of copies of the same binary. One of them can run alone, which is the Docker image: it listens, then forms a one-node group by itself. Three of them, started with the brokers profile, elect a leader and keep accepting metadata writes after that leader is gone.