Design a Key-Value Store (DynamoDB-like)

Requirements to clarify

Functional: get/put/delete by key, at scale, across many nodes.
Non-functional: what’s the priority per CAP theorem (this is the central design question) — strong consistency or high availability under partition? What’s the expected read/write ratio?

Partitioning: consistent hashing distributes keys across nodes with minimal reshuffling on node changes (see Consistent Hashing).
Replication: each key replicated to N nodes (e.g., N=3) for durability/availability.
Consistency mechanism: quorum-based reads/writes (R + W > N guarantees strong-ish consistency; R + W ≤ N favors availability/latency with eventual consistency) — this is the direct, tunable expression of the CAP tradeoff.
Conflict resolution: when concurrent writes to the same key create conflicting versions (common in leaderless/AP designs), use vector clocks or “last write wins” to resolve them.
Failure handling: hinted handoff (temporarily store writes meant for a down node elsewhere, deliver when it’s back) and anti-entropy (background sync, e.g., via Merkle trees) to repair replica divergence.

This question is fundamentally “implement CAP theorem” — a strong answer explicitly states which side of CP/AP the design lands on and why, rather than trying to claim both.