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

This component exists to trigger reads and writes with tunable consistency levels and verify outcome metrics. It directs requests to a coordinator replica in the ring, monitoring timeouts and eventual consistency states. In the demo, observe message packets traveling to the coordinator and read results returned.

Coordinator Node

This component exists to manage distributed request lifetimes, compile quorum lists, and merge versions. It receives client requests, delegates commands to target replicas, aggregates acknowledgments, and performs read repairs. In the demo, observe coordinator highlight (ring outline) and outgoing query packets (blue for write, green for read) to replicas.

Replicas (N1 to N5)

This component exists to store data partitions redundantly, execute operations, and maintain logical vector clocks. They process read/write commands, increment node-specific counters, and respond to queries from coordinator hosts. In the demo, watch node detail cards showing local key values and vector clock counters (e.g., [N1:2]).

Gossip Protocol (Anti-Entropy)

This component exists to heal partition differences and keep replicas up to date without continuous client polling. It exchanges database key signatures between node pairs asynchronously to detect and repair version drift. In the demo, observe background synchronization logs and node values converging.

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.