KV store: what it does in a system design

Home › Reference › Components › KV store

KV store

Throughput-provisioned KV store with RCU/WCU throttling.

Settings

Instance tier: Sets the default read and write budget of each partition (units per second). A bigger tier takes more traffic before requests are throttled, but does not make a single request faster.
Partitions: How many pieces the keys are spread across, each with its own read and write budget. More partitions raise total throughput, but one hot key still lives on a single partition.
Read capacity units (RCU): Reads each partition can serve per second before extra reads are rejected as throttled. An eventual read costs 1 unit and a strong read costs 2. Leave blank to use the tier's default.
Write capacity units (WCU): Writes each partition can take per second before extra writes are rejected as throttled. Each write costs 1 unit. Leave blank to use the tier's default.
Preloaded keys: How many keys already hold a value when the run starts (keys 0 up to this number). Reads of keys that were never written find nothing. Blank uses the scenario's dataset size.
Default consistency: Which copy reads see. Eventual is cheapest but may return an older value. Strong sees the latest write, at 2 read units and ~10% more latency. Strong after write is strong only for keys written in the last second.
Sub-counters per hot key: Splits each hot key into this many sub-counters so its writes spread out instead of hitting one key's limit (1000 writes/s). The catch: each read must fetch all of them and wait for the slowest.
Split keys below: Only keys numbered below this value are split. Hot keys tend to have low numbers under a skewed workload. Blank splits every key. Has no effect unless sub-counters is above 1.
Replicas per partition: Copies kept of each partition. Above 1, reads and writes use the quorum settings below instead of the consistency setting, and each copy has its own capacity. More copies survive more crashes but cost more write units.
Read quorum (R): How many replicas a read asks, taking the newest value it sees. Higher is more up to date but slower (waits for the slowest) and fails if too few replicas are up. Needs replicas above 1 and at most replicas.
Write quorum (W): How many replicas must confirm a write before it succeeds. The rest catch up later. Higher is safer but slower. If read quorum + write quorum is more than replicas, a read always sees the latest write.
Read latency: How long one read takes inside the store, drawn at random per read. Higher means slower reads. Shapes: constant, lognormal (mostly near the mean, occasional slow ones), exponential, uniform (min to max).
Write latency: How long one write takes inside the store, drawn at random per write. Higher means slower writes. Shapes: constant, lognormal (mostly near the mean, occasional slow ones), exponential, uniform (min to max).
Replication lag: How long other copies take to receive a write. While they lag, eventual reads can return the old value. Longer lag means more stale reads. Blank means copies update instantly. Shapes: constant, lognormal, exponential, uniform.
Crashes: Scheduled outages. While the store (or one replica) is down, requests that cannot be served fail. With replicas, reads and writes still work as long as enough replicas are up to meet the quorum.