The Media Plane and the Control Plane
In one line: the bytes and the facts about the bytes travel on different infrastructure, and mixing them is the most expensive mistake in this design.
The tempting answer
Streaming data arrives continuously and needs to reach several consumers — the archiver, the analytics pipeline, the live viewer. That description matches a log, so the reflex is to publish video frames to Kafka and let consumers subscribe.
It is a reasonable instinct and it is wrong here, for reasons that are mechanical rather than stylistic.
Why a log is the wrong shape for media
The size assumption. Broker message size defaults to roughly one megabyte, and the ecosystem's tuning, buffer sizing and memory accounting assume messages far below that. A four-second 4 Mbps segment is about two megabytes, so every segment exceeds the default before you start. The limits are raisable; the assumptions underneath them are not.
Replication multiplies the wrong tier. A log replicates for durability, typically three ways, onto broker-attached disks. That means storing petabytes of video at three times the volume on your most expensive storage, when the entire point of the design is to get that data onto your cheapest. You would be paying a premium to triplicate the thing you most want to store cheaply.
The cache is tuned for a workload you do not have. Broker throughput depends on consumers reading recent data from the page cache. Surveillance archive is written once and read approximately never, so the cache hit rate for the archive is near zero. You would be running an architecture whose main performance mechanism is inapplicable.
Memory pressure. Large messages sit in broker heap and buffers during produce, replicate and fetch. Large payloads increase pressure on the broker JVM and slow the broker down for everything else on it — including the small messages that genuinely belong there.
The replication bandwidth. Four gigabits per second of ingest becomes twelve gigabits of inter-broker replication traffic. That is a network design problem you created by choosing the wrong component.
None of that means "no log"
The conclusion is not to remove the messaging tier. It is to be precise about what travels on it.
The pattern is claim check: write the large payload to storage built for large payloads, and publish a small reference describing it. The message carries the identity, location and metadata of the object; consumers fetch the bytes directly if and when they actually need them.
Concretely, the gateway writes the segment to object storage and then publishes something on the order of two hundred bytes:
camera_id cam-0417 site_id site-12 seq 88213 started_at 2026-09-03T14:22:04.120Z ended_at 2026-09-03T14:22:34.980Z duration_ms 30860 key s3://vault/site-12/cam-0417/2026/09/03/14/1757...fmp4 bytes 15431092 codec h265 first_idr true motion true checksum sha256:9f2c...
Two hundred bytes instead of fifteen megabytes — a reduction of roughly five orders of magnitude on the coordination path. And the log now does what logs are good at: ordered, replayable, multi-consumer delivery of small facts.
What lives on each plane
| Media plane | Control plane | |
|---|---|---|
| Carries | Segment bytes | Segment facts, events, health |
| Volume | 4 Gbps, petabytes | ~50 KB/s, gigabytes |
| Built on | Object storage | Log + index database |
| Access pattern | Write once, read rarely | Write once, read constantly |
| Durability need | High, cheap | High, and it must be fast |
| If it is lost | Footage gone | Footage exists but is unfindable |
The final row is the one people underestimate. The control plane is small, which makes it feel unimportant, but losing the index means losing the archive in every way that matters — the objects are still there, and nobody can locate the right ones among six hundred million. Back up the index accordingly, and be able to rebuild it from object keys as a last resort, which is a reason to encode camera and timestamp into the key rather than using an opaque UUID.
The general principle
This is not a fact about one message broker. It is a shape that recurs whenever a system moves large payloads and needs coordination about them.
Coordination infrastructure — logs, queues, orchestrators, workflow engines — is built around small messages, high fan-out and replayability. Payload infrastructure — object stores, filesystems — is built around large sequential writes and cheap capacity. When a design routes payloads through coordination infrastructure, it inherits the cost model of the wrong one.
The tell is a ratio. When the payload is thousands of times larger than the metadata describing it, the two want different infrastructure, and the interesting design work is deciding what the reference must contain so that the payload almost never has to be touched.
Key takeaway
Video does not belong in a replicated log: segments exceed default message sizes, three-way replication puts petabytes on the most expensive disks you own, the broker's page cache is useless against data nothing re-reads, and 4 Gbps of ingest becomes 12 Gbps of replication. Use claim-check instead — bytes to object storage, a two-hundred-byte record to the log. That keeps the coordination path five orders of magnitude smaller than the media path, and it makes the index the thing you must never lose, because objects nobody can locate are objects you do not have.
Next: how those objects are laid out, tiered, and priced.