Design of a Key-Value Store

Requirements

We will design a Dynamo-inspired key-value service for predictable key-based access. The requirements favor accepting writes during some failures and reconciling divergent versions afterward. They are a choice for this workload, not a claim that key-value storage replaces every relational workload.

Functional requirements

While standard key-value stores offer get and put operations, this design focuses on specific characteristics:

• Configurable service: Applications often trade strong consistency for higher availability. The system must support configurable consistency models that allow users to balance availability, consistency, cost, and performance.

Scope: This exercise treats the selected policies as instance configuration. Whether a production implementation permits dynamic changes is an implementation detail to verify.

• Write availability: Try to accept valid writes through the failures covered by the design, even if replicas temporarily disagree. “Always write” is the Dynamo design goal used here; it cannot mean success when no suitable node is reachable or no capacity remains. State the failures and acknowledgment rules under which acceptance is required.