Choosing Between Replicas and Caches

Replication and caching both reduce read work on the primary. Which one should we use?

A cache is useful when many requests ask for the same thing. We can compute a result once and reuse it. Our application must arrange to refresh or invalidate the entries as needed. Shopend’s catalog is a good candidate because many shoppers request the same products.

A replica is useful when reads vary and their results are rarely reused. It can run queries against its copy of the data, and the database keeps that copy updated through replication. It can also serve as a replacement during failover, which a cache cannot do. A shopper’s past orders and platform-wide reports are candidates for replica reads, subject to their freshness requirements.

Shopend can use both: a cache for popular catalog reads and replicas for other reads that they can safely answer. Reads that must include a shopper’s recent change still follow our decision to use the primary for a short period, and purchase transactions remain on the primary.

The writes still go to one place

Our assumed workload was 10,000 reads and 1,000 writes per second. Caching can serve some of those reads, and replicas can share the remaining reads as their requirements allow. But all 1,000 application writes still go to the primary. Every other replica also applies those writes to maintain its copy of the data.

Moving reads away from the primary leaves it more capacity for writes, but adding replicas does not divide the writes among servers. Suppose the write load grows until the primary cannot keep up even after we move the eligible reads elsewhere. Another copy of the same data would still need to receive every change.

To spread that work, we would need different servers to handle writes for different parts of the data. That requires dividing the data, rather than keeping another copy of all of it.