In a distributed log like Kafka, each partition must have exactly one leader broker that handles all reads and writes. Followers replicate data from the leader for fault tolerance.

Architecture:

• Leader: the broker responsible for a partition. All producers and consumers interact with the leader.
• Followers: replicate the partition log from the leader. They do not serve reads (in standard Kafka).
• Leader election: when the leader crashes, one of the in-sync followers is elected as the new leader.

The metadata flow:

1. Producer calls metadata_request to discover which broker is the leader for a partition
2. Producer sends ProduceRequest directly to the leader broker
3. Leader writes the message to its local log
4. Leader replicates to followers
5. After replication, leader acknowledges the producer

This ensures total order within a partition — all messages pass through a single leader.

Request:  {"type": "partition_leader", "msg_id": 1, "topic": "orders", "partition": 0}
Response: {"type": "partition_leader_ok", "in_reply_to": 1, "leader": "broker-1", "followers": ["broker-2", "broker-3"], "term": 3}

Request:  {"type": "partition_failover", "msg_id": 2, "topic": "orders", "partition": 0, "failed_leader": "broker-1"}
Response: {"type": "partition_failover_ok", "in_reply_to": 2, "new_leader": "broker-2", "new_term": 4, "failover_ms": 250}