Distributed Database Replication Simulator — Leader Log, Quorum & Partitions

Interactive database replication simulator — follow numbered writes into a leader log and onto two followers, compare asynchronous and quorum acknowledgment, and partition followers to see stale reads and blocked commits.

← Cloud Computing Labs
About this tool — how it works & FAQOpen ▾Close ▴

About the Distributed Database Replication Simulator

This simulator lets you watch numbered writes enter a leader's append-only log and replay on two followers. You choose when the client is told a write succeeded, slow a follower down, or cut followers off the network, and read the consequences off the sequence counters.

What the simulator shows

• A 3D scene with the write client and acknowledgment stream, the leader's append-only log, the Follower 1 and Follower 2 replay logs, and an acknowledgment and quorum gate. • Controls for the acknowledgment policy (leader only asynchronous, or leader plus one follower), Follower 2 replay delay (1 to 6 seconds), and Disconnect follower 1 and Disconnect follower 2 switches. • Readouts for leader log sequence, each follower's sequence, the acknowledged prefix, unacknowledged writes and Follower 2's read lag. • Experiments for asynchronous lag, a blocked quorum and one follower isolated.

Acknowledgment, quorum and lag

A follower's sequence is the number of leader writes older than its replay delay, while it is connected. With the leader-only policy, a write is acknowledged as soon as it is appended locally, so the client sees success while Follower 2 may still serve an older prefix. With the leader-plus-one-follower policy, the acknowledged prefix is the median of the leader and the two follower sequences, meaning at least two copies hold the write. If both followers are disconnected, the leader keeps appending but acknowledgments stop; if only one is isolated, the other can still satisfy the two-copy requirement.

What the model is and is not

The log is monotonic and ordered, with no leader elections, leader failure, conflicting writes, disk failures or bandwidth limits, and reconnecting followers catch up instantly. The fixed leader is deliberate so replication can be studied on its own. The acknowledgment policies are simplified illustrations and are not a complete specification of any database's consistency model.

Frequently asked questions

Does an acknowledged write mean every follower has it?

Not necessarily. It depends on the policy: a two-copy quorum needs only the leader and one follower. The lab shows this when the acknowledged prefix is ahead of a slow or disconnected follower's sequence.

What is the acknowledged prefix?

It is the highest write sequence that the current policy has confirmed to the client. Under leader-only it tracks the leader log; under leader-plus-one-follower it is the median of the three sequences, so two copies are guaranteed.

What happens when both followers are disconnected?

With the quorum policy, the leader continues to append writes, but no write can gain a second copy, so the acknowledged prefix stops advancing and unacknowledged writes pile up.

Does the model simulate leader election?

No. The leader stays fixed so you can isolate log replication, acknowledgment policy and partitions without the added complexity of failover.

Related tools & guides