sydepsystem design atlas

Distributed Key-Value Store

Replicate data across nodes to make a big shared key/value space available everywhere.

AdvancedPlatformData
ClientsComputeRouting LayerNetworkingKV Node AStorageKV Node BStorageKV Node CStorage

A distributed key-value store shards and replicates data across nodes so requests can be routed to the nearest replica without sacrificing availability, with consistency tuned per operation.

When to use it

  • You need a large, shared, low-latency key/value namespace across many services or regions
  • The workload is mostly simple reads and writes, not rich relational queries

Trade-offs

  • Consistency and topology decisions (leader/follower, quorum, conflict resolution) are central to correctness
  • Operationally expensive to size and repair when a node fails

Components used

Managed App ServiceLoad BalancerKey-Value Store

How it works

  • Keys are partitioned across nodes, usually by consistent hashing, so adding or removing a node moves only a fraction of the keyspace.
  • Each partition is replicated to several nodes for durability and availability.
  • Reads and writes use quorums: requiring reads plus writes to exceed the replica count yields strong consistency, while smaller quorums trade consistency for latency.

Used in the wild

  • Session and profile storage needing single-digit millisecond access at scale.
  • Shopping carts and other high-write, low-relational workloads.
  • Feature flags, configuration and metadata read by every service.

Good to know

  • Amazon's 2007 Dynamo paper is the direct ancestor of Cassandra, Riak and DynamoDB, and popularised consistent hashing, vector clocks and tunable quorums together.
  • Hot keys break the model. Consistent hashing distributes keys evenly but not traffic, so one celebrity key can saturate a single partition no matter how many nodes you add.