Which Replica Can Answer a Read?

Replicas can serve reads, leaving the primary more capacity for other work. Should we send every read to a replica and leave the primary to handle only writes?

Consider three reads: listing the mug shop’s catalog, showing a shopper’s past orders, and reading prices and stock while placing an order. The first two display data. A replica can answer them if it has the data the response requires.

The third read belongs to a purchase transaction. That transaction reads prices, checks and reduces stock, records the order, and updates the cart. We keep the whole transaction on the primary, including its reads. Sending its reads to a separate replica would take them outside the transaction we designed. So even with replicas, some reads still belong on the primary.

Reading before a replica catches up

Displaying data can involve a complication too. Suppose a shopper adds an item to their cart. The primary records the change, and Shopend confirms it. The shopper then opens the cart in another browser tab or on their phone. That read goes to a replica that has not applied the change yet, so the new item is missing.

The change exists on the primary, but this replica cannot show it yet. The delay before a replica applies the primary’s changes is called replication lag.

After a shopper changes a cart or places an order, their next read must include that change. This guarantee is called read-your-writes. Without it, the shopper may see an old cart or be told that an order they just placed does not exist.

Reading from the primary for a while

One option is to send reads of the shopper’s data to the primary for a few seconds after their write. The API keeps track of when the shopper last made a change. During that short period, it uses the primary for their reads. Afterward, it can use replicas again. The storefront does not choose a database copy; the API makes that decision.

Assume the primary remains healthy and retains the successful write. Reads sent there can see the change without waiting for another replica to apply it. This is simple, but it puts more read work on the primary.

The other limitation is the time period. A few seconds is a guess about how long replicas need to catch up. If a replica is still behind when the period ends, a read sent there can still miss the change. Waiting a fixed amount of time does not prove that a replica has applied a write.

Waiting for a replica

Another option is to send the read to a replica, but require it to wait until it has applied the shopper’s write before answering. This checks for the particular change the read needs, rather than assuming that enough time has passed.

A database session or client library may manage this waiting automatically once configured. The database must support the required coordination, and the read may have to wait for the replica to catch up. In return, the read can run on a replica while still including the shopper’s change.

Our choice for Shopend

For Shopend, we read from the primary for a few seconds after a shopper’s own change. Assume these reads are a small share of all reads, so most reads can still go to replicas. Reads inside purchase transactions stay on the primary regardless of when the shopper last made a change.

This choice depends on replicas catching up within that short period. If we must guarantee read-your-writes even when replication takes longer, the fixed period is not enough; we need to confirm that the replica has applied the write before using it.