Apache Kafka stores events as an append-only, ordered log split across partitions. Producers write events to the head of a partition; each event gets a monotonically increasing offset. Consumers don't remove events — they simply track their own offset and can replay from any point still inside the retention window, which is the core idea behind event-driven architecture: many independent readers, one durable log.
Because Kafka never deletes data on read, the same log can feed a real-time fraud detector and an overnight batch job simultaneously — each consumer group just remembers its own offset, with no coordination between readers required.
Producers write events onto a partitioned, append-only Kafka topic log while two independent consumers replay it at their own pace — watch a lagging consumer fall behind and get reset when it drops outside the retention window.
Each partition is an ordered, offset-indexed log. Consumers never remove data — they just track a read offset, so a fast consumer and a slow one can read the exact same log independently, which is the essence of event-driven decoupling.
Adjust the partition count, producer rate and the slow consumer's processing speed. Shrink the retention window or starve Consumer B to watch its offset expire and reset — a real Kafka failure mode called an offset out-of-range reset.
Kafka can sustain millions of events per second because partitions parallelize both writes and reads — each partition is only ever appended to by one producer thread and read independently by each consumer group.