Read replicas are the standard first answer to a database that cannot keep up: add copies, send reads to them, keep writes on the primary. It genuinely works for read-heavy workloads and it introduces one specific problem that has to be designed around rather than discovered - replication lag, and the class of bugs that follows from it.
The bug is always the same shape. A user updates something, the application redirects, the next page reads from a replica that has not yet received the change, and the user sees their old data. They assume the save failed and do it again. This is not rare or theoretical; it is the default behaviour of naive read-write splitting, and it is why the routing decision cannot simply be reads here, writes there.
The usual fix is read-your-own-writes consistency: after a user performs a write, route their reads to the primary for a short window - a few seconds, tracked in their session. Everyone else continues reading from replicas. It is a small amount of code and it removes the entire category of confusing behaviour, at the cost of a little primary load from recently-active users.
Beyond that, classify reads by how much staleness they tolerate, because most tolerate quite a lot. A dashboard, a report, a search index, an export, an analytics query - none of these are harmed by data a second or two old, and all of them are often the expensive queries. Moving exactly those to replicas relieves the primary of its heaviest work while leaving transactional reads where correctness demands. Anything inside a transaction, or feeding a decision that will be written back, belongs on the primary regardless.
Monitor replication lag as a first-class metric with an alert, because it does not stay small. A long-running transaction, a bulk import, a schema change or a burst of writes can push lag from milliseconds to minutes, and every assumption you made about acceptable staleness fails at once. Some systems can route around a lagging replica automatically; if yours cannot, you at least want to know before your users tell you.
One caution about what replicas do not solve. They add read capacity and they do not add write capacity - every write still goes to one primary, and replicas actually add a little load applying that stream. If your bottleneck is writes, replicas will not help, and the next step is a different conversation entirely about sharding or partitioning. Diagnosing which of the two you actually have, before buying replicas, saves a quarter of disappointed effort.
