One primary takes writes; replicas serve reads and lag behind by some amount.

Three problems, three tools

Technique	Removes	Does not help with	New problem
Replication	Read throughput, single-node failure	Write throughput	Replication lag
Partitioning	Write throughput, storage limits	Cross-partition queries	Hot partitions, rebalancing
Caching	Latency, repeated expensive reads	Writes, uncacheable reads	Staleness, invalidation

Reach for the one that matches your bottleneck.

Replication and the lag you now have

Copy the data to more machines and reads spread across them while any single loss stops being fatal. The cost is that copies are not instantaneous.

One primary takes writes; replicas serve reads and lag behind by some amount.

Describe this diagram in words

Components (4): API [api]; Primary [database] — all writes; Replica [database] — reads; Replica [database] — reads Connections (5): API -> Primary (writes); API -> Replica (reads); API -> Replica (reads); Primary => Replica; Primary => Replica Legend: -> synchronous, ~> asynchronous, => replication.

Asynchronous replication means a read from a replica may not reflect a write that has already been acknowledged. Concretely: a user updates their profile, the write succeeds, the page reloads, the read lands on a lagging replica, and their change appears to have vanished. Nothing is broken and the user is certain it is.

Partitioning, and the key you cannot change

Partitioning splits data so each machine holds a slice. It is the only technique here that raises write throughput, and its whole character is decided by one choice: the partition key.

Partition by a key your queries filter on, or every query becomes a fan-out to every shard.
Prefer a key with high cardinality and even distribution — partitioning by country puts most of the load on a handful of shards.
Beware keys that concentrate recent activity: partitioning by timestamp sends every write to the newest shard.

Caching, and the invalidation you must name

A cache stores the result of expensive work close to whoever needs it. It buys latency and reduces load, and it introduces the possibility of serving something that is no longer true.

Strategy	How it works	Trade
Cache-aside	App checks cache, falls back to store, populates	Simple; first read after a miss is slow
Write-through	Writes go to cache and store together	Cache always warm; writes slower
Write-behind	Write to cache, flush to store later	Fast writes; data loss window
TTL only	Expire after a fixed time	Trivial; bounded staleness by design

Pick one on purpose.

The rule worth carrying: before adding a cache, answer 'how does an entry become wrong, and what removes it?' If the answer is a time-to-live, say what staleness is acceptable. If the answer is explicit invalidation, say who is responsible for firing it. A cache with no answer will serve wrong data, and the bug will surface far from the cache.

Replication, Partitioning and Caching — Tech Epitome