Add a read replica
Copy the Database to a replica that answers reads, so the primary's capacity goes to writes and read traffic scales out.
Link the App Server to a Read Replica as well as the primary, so reads split between them.
Move up when#
The primary's load bar is full from reads, and the hot data is too big or too varied for a Cache.
The primary shows a disk limit and p99 climbs.
The Design#
Drag to pan. Hold Ctrl or Cmd and scroll to zoom.
| Where | Setting | Value | Why |
|---|---|---|---|
| App Server | Instance size | medium | Medium, so the App Server is not the limit. |
| Database | Instance size | small | Small, and one machine takes every read and every write. |
Drag to pan. Hold Ctrl or Cmd and scroll to zoom.
| Where | Setting | Value | Why |
|---|---|---|---|
| App Server | Instance size | medium | Unchanged. |
| Database | Instance size | small | Unchanged. Writes still all land here. |
| Read Replica | Instance size | small | The same size as the primary, so the App Server splits reads evenly between them. |
| Read Replica | Engine | postgres | A replica runs the primary's engine. It copies the primary and answers reads only. |
Research this Design needs: Read replicas.
In the first picture one Database takes everything. In the second, the App Server writes to the primary and sends reads to both. The replica takes only reads.
Why it works#
The replica copies the primary and answers read queries, so each Database carries about half the reads. The primary's load bar falls under full, and p99 falls from seconds to normal.
What it costs#
A replica lags behind the primary, so some reads come back stale. In the ledger that shows as stale errors, since a stale read fails an API read or a checkout that reads its own write, though a page view accepts it. The lag grows with the write rate. Writes do not scale at all, so a write-heavy load needs a bigger primary or sharding. You also pay for a second Database.
In Quorum#
Research Read replicas to unlock the Read Replica. The Stale Checkout Sandbox shows the stale read, and Replication lag is the incident. Read-your-writes routing is the repair. Read replicas covers the pattern. The next rung is to route reads and writes apart.