Design brief
Design a durable key-value store for one billion records averaging 2 KB including metadata. Three copies require roughly 6 TB before operational overhead. Ordinary reads and writes should tolerate one unavailable replica. Preserve concurrent versions for application resolution; state the consistency contract without promising linearizable updates. Define the durability meaning of a successful write and a target request deadline.
Draw and explain
In Excalidraw, show key placement, coordinators, replica boundaries, and membership ownership. Label durable data, causal metadata, and read/write acknowledgement paths. Sketch a client contract that carries version context and can return conflicts. Trace a write, a read that encounters divergent replicas, and a resolving write. Include the path by which an unavailable replica eventually learns missed updates.
Stress the design
A write reaches two replicas, but its reply is lost; the third replica returns later with an older value. Explain retry ambiguity and subsequent read outcomes. Separately, two clients update the same base version while disconnected. Draw how both versions remain discoverable and who is allowed to merge their meaning.
Review your design
Check the assumptions behind quorum intersection, including membership changes and durable acknowledgements. Compare availability against stronger coordination for incompatible workloads. Explain causal-metadata growth, tombstone retention, repair bandwidth, and backup recovery. Identify signals for sibling growth, quorum timeouts, repair lag, and overloaded partitions; distinguish replication from protection against accidental deletion.
Capture assumptions, sizing, and the tradeoffs behind your diagram.
Review is your own assessment of the design.