Tunable DB Consistency Simulator

A Dynamo-style masterless database lets writes succeed on any subset of replicas, trading immediate consistency for high write availability. Tunable consistency comes from three knobs — replication factor $N$, write quorum $W$, and read quorum $R$ — and the core mental model is quorum intersection: when $R + W > N$, every read overlaps a previous write on at least one replica, so the latest value is always retrievable.

Mental Model

A Dynamo-style masterless database scales write availability by allowing writes to succeed on any subset of nodes. It achieves tunable consistency through three parameters: Replication Factor ($N$), Write Quorum ($W$), and Read Quorum ($R$). The core mental model is quorum intersection: if $R + W > N$, the read quorum and write quorum are mathematically guaranteed to overlap on at least one replica node. This overlap ensures that a read will always retrieve the latest write. If $R + W \le N$, the database is eventually consistent, meaning reads might return stale data.

Components and Why They Exist

Client App

The client application triggers reads and writes at configurable consistency levels (ONE, QUORUM, ALL) and verifies whether returned values are fresh, stale, or conflicted. Request packets leave the Client App card toward the selected coordinator and report the resolved value and quorum outcome on return.

Coordinator Node

The coordinator node manages the lifecycle of a distributed request, fans queries out to the replica preference list, counts quorum acknowledgments, and triggers read repair when stale versions appear. A highlighted ring outline marks the active coordinator as it dispatches blue write packets or green read packets across the cluster.

Replicas (N1 to N5)

Replicas N1 through N5 store data partitions redundantly, execute local reads and writes, and maintain logical vector clocks to track causal history. Each replica card displays its stored key value alongside its vector clock counters (such as [N1:2]) and network partition state.

Gossip Protocol (Anti-Entropy)

The gossip protocol exchanges key metadata in the background so partitioned or skipped replicas converge without waiting for a client read to touch every stale key. Periodic anti-entropy sync events reconcile divergent vector clocks and bring lagging replica cards back into agreement.

Edge Cases and Misconceptions

• LWW (Last-Write-Wins) timestamp issues: Many databases use wall-clock timestamps to resolve version conflicts. If server clocks drift, a write that occurred later in real time might be discarded because its timestamp is lower than a stale node’s clock, causing permanent data loss.
• Quorum does not prevent conflict: If two clients write concurrently to different partitioned nodes with a write quorum of 1 (W = 1), both writes succeed, creating diverging histories. Vector clocks identify this concurrency, forcing the application or database to merge the values.
• ALL consistency availability penalty: Setting the write quorum to ALL (W = ALL) ensures absolute read freshness, but if even a single replica node is partitioned or restarts, all writes fail, destroying the system’s write availability.