In Kafka's replication model, which replica handles producer writes and reads, and what role do the other replicas play?
answer
- One leader per partition handles writes/reads
- Followers only copy, never serve clients
- Single writer = single authoritative order
- ISR follower promoted on leader failure
- Leadership is per-partition
basics
~10 sEach partition has one leader replica that handles all produce and consume requests. The other replicas are followers; they only copy the leader's data and stand by to take over if the leader fails.
solid answer
~40 sKafka uses a leader-based (single-writer) replication model. For every partition, one of its replicas is elected leader; all producer writes and (by default) all consumer reads go through that leader. The remaining replicas are followers. Followers never serve clients directly: each runs a background fetch loop that pulls new records from the leader and appends them to its own copy of the log, trying to stay caught up. If the leader broker fails, the controller promotes an eligible follower (one that is in-sync) to become the new leader, so the partition stays available. This design keeps ordering simple: because only the leader appends, there is a single authoritative log order that followers replicate byte-for-byte.
go deeper
Know there is one leader per partition that takes writes, and followers just copy it.
Explain why single-writer gives clean ordering and how a follower is promoted from the ISR on failure.
Discuss read-from-follower (KIP-392), per-partition leadership balancing, and the durability/availability trade in failover.
Reason about how the single-writer log order underpins exactly-once and ordering guarantees, and the cluster-wide implications of leadership distribution.
**Background.** A Kafka *topic* is split into *partitions*; each partition is an ordered, append-only log. For fault tolerance, each partition is *replicated* onto several brokers — the number is the *replication factor*. Each of those copies is a *replica*. **Leader vs follower.** Kafka does NOT let every replica accept writes. Instead, for each partition exactly one replica is designated the **leader**, and the rest are **followers**. This is called a *leader-based* or *single-writer* model. - The **leader** is the only replica that handles produce requests (writes) and, by default, consume requests (reads). It owns the authoritative copy of the log. - A **follower** does not talk to clients at all. Its only job is to replicate the leader's log. It runs a background thread that continuously sends *Fetch* requests to the leader, receives the new records, and appends them to its local copy in the same order. **Why a single writer?** A Kafka partition guarantees a strict total order of messages. If multiple replicas could accept writes independently, you'd need to reconcile conflicting orders. By funneling every append through one leader, the order is decided in exactly one place, and followers simply copy that order. Simplicity and strong ordering are the payoff. **Failover.** Followers that are sufficiently caught up are tracked in the **ISR** (in-sync replica set). If the leader broker crashes, the cluster *controller* picks a replica from the ISR and promotes it to be the new leader. Producers and consumers then transparently redirect to the new leader (they discover it via metadata). Because the new leader came from the ISR, it already has (almost) all the committed data, so little or nothing is lost. **Reads.** Historically all reads also went to the leader. Since KIP-392, consumers can optionally *fetch from the closest follower* (rack-aware reads) to save cross-datacenter bandwidth, but writes are still leader-only. **Edge cases.** - A broker can be leader for some partitions and follower for others simultaneously — leadership is per-partition, not per-broker. - A follower that falls too far behind is removed from the ISR but keeps fetching to catch back up. - If no in-sync follower exists and `unclean.leader.election.enable=false`, the partition goes offline rather than promote a stale replica (durability over availability).
- Can a single broker be the leader for some partitions and a follower for others at the same time?Yes. Leadership is assigned per partition. A broker is typically leader for some partitions and follower for others, which is how Kafka balances load across the cluster.
- Do consumers always read from the leader?By default yes, but since KIP-392 a consumer can be configured to fetch from the nearest in-sync follower (rack-aware fetching) to reduce cross-rack/cross-DC traffic. Writes still only go to the leader.
saying these in an interview costs you the question
- Saying all replicas accept writes (multi-master) — Kafka is single-writer
- Claiming followers serve consumer traffic by default
- Thinking a broker is globally a leader or globally a follower rather than per-partition