Kafka Partition & Replication

Trace one event through Kafka partition routing, leader append, replica sync, consumer assignment, and failover

animation
kafka
streaming
distributed-systems
interactive
An interactive Apache Kafka partition and replication workbench for exploring keyed routing, partition-level ordering, leader and follower replicas, in-sync replica health, producer acknowledgments, consumer group limits, and broker failure behavior.
Apache Kafka Partition routing Leader replicas Consumer groups

Follow one event through partition, replication, and failover.

Route a keyed IoT event into a topic partition, append it to the partition leader, replicate it to in-sync followers, and see how consumer parallelism and broker failures change the outcome.

Sensor telemetry Scenario
Key -> P0 Partition route
4 active lanes Consumer parallelism
Strong Write posture

Choose a key and route the event

The producer key selects exactly one partition. Ordering is scoped to that partition, not to the whole topic.

Step 1 of 6
Kafka partition and replication visualization A producer sends an event to one partition, the leader appends the record, followers replicate it, and a consumer group reads assigned partitions.
Route sensor-047 -> P0

Same key returns to the same partition while the partition count is unchanged.

Ordering Per partition

Kafka does not promise one global order across all partitions in a topic.

Replication RF=3, ISR=3

Followers must stay in sync before they are useful failover candidates.

Consumers 4 active

Extra consumers in one group stay idle when they outnumber partitions.

Current diagnosis

A keyed producer record is assigned to one partition. That partition is the unit of ordering and consumer assignment.

Event trace

    Model Reading

    Kafka stores a topic as multiple partition logs. Each partition has one leader replica for client reads and writes, plus zero or more follower replicas for durability and failover.

    • Keyed records are routed to one partition. A stable key keeps related records in the same partition while the partition count remains unchanged.
    • Ordering is guaranteed within a partition. There is no single total order for all records across a multi-partition topic.
    • A consumer group can process partitions in parallel, but one partition is assigned to only one consumer in that group at a time.
    Accuracy Notes
    • The partition calculation is a teaching hash. Real Kafka clients use configured partitioners and metadata, and behavior can change when partition counts change.
    • Replication factor counts all copies, including the leader. Fault tolerance also depends on replica placement, in-sync replica health, controller decisions, and producer settings.
    • acks=all can improve durability when enough in-sync replicas are available. It also increases the write path and can reject or delay writes when the configured ISR requirement is not met.
    • The throughput and risk labels are planning heuristics for this animation, not Kafka benchmark formulas.
    Guided Checks
    • Increase consumers beyond partitions and watch the active consumer count stop increasing.
    • Use high key skew and observe how one hot partition limits parallelism even when the topic has more partitions.
    • Fail the selected leader with replication factor one, then raise replication factor and compare the failover diagnosis.
    • Turn on follower lag with acks=all and a minimum ISR above the available replica count.