YugabyteDB
YugabyteDB applies Raft per tablet so the database can combine strong consistency with horizontal scale.
Architecture
Tables are split into tablets. Each tablet is replicated by its own Raft group with one leader and followers. This lets many tablet leaders coordinate writes in parallel across the cluster.
Every tablet has a replica set spread across nodes or zones. That tablet elects its own leader, maintains its own log, commits independently, and can be rebalanced separately.
Healthy deployments spread tablet leaders so one tserver does not absorb too much write coordination. Poor leader distribution causes hotspots, queue buildup, and CPU imbalance.
CAP Theory
CAP says that during a network partition, a distributed system must choose between availability and consistency for operations that require coordination. Raft-backed tablet groups choose consistency for writes: without quorum, the tablet will not safely commit new writes.
Raft enforces one committed order of writes per tablet. A successful write is confirmed only after the tablet leader reaches majority replication.
If a tablet leader is isolated in a minority partition, it cannot commit. The majority side can elect a new leader and continue safely.
A tablet that loses quorum becomes unavailable for new writes until enough replicas return. This protects correctness over unsafe availability.
Production Scenarios
If one tserver owns too many hot leaders, write coordination concentrates there. Expect high CPU, queueing, and uneven latency.
Look for packet loss, disk stalls, overloaded RPC workers, CPU starvation, and aggressive timeout settings.
After outage, replicas catch up through log replay, snapshot, or remote-bootstrap style recovery depending on lag and log retention.
Tablet availability depends on whether each tablet's remaining replicas still form quorum, not just whether the overall cluster has many nodes alive.
By sharding into many tablets. Each tablet has its own leader, so the cluster has many leaders in parallel.
Replica balancing spreads storage. Leader balancing spreads write coordination work.
During a partition, a tablet needs quorum to preserve consistency. Without quorum it should reject or stall writes instead of risking divergence.
Leader changes, vote requests, replication latency, under-replicated tablets, follower lag, disk latency, and CPU saturation.