Read Replicas diagram template
Scale reads with asynchronous replicas while the primary handles all writes.
About this design
Most applications read far more than they write, which makes replicas the cheapest first step in scaling a relational database. All writes go to a single primary; it streams its changes to several replicas that serve read-only queries, and the application, or a proxy in front of it, routes each statement accordingly. The catch is replication lag: a replica may be a few hundred milliseconds behind, so a user who just saved a profile can briefly read stale data. The template includes a connection proxy to make routing transparent and a monitor to watch lag. Use it to discuss read-your-writes consistency, sending a user's own reads to the primary for a short window, promoting a replica after a primary failure, and the point where one primary can no longer absorb the write volume and sharding becomes unavoidable.
Diagram as text
This is the source of the diagram, in the ArchBoard diagram DSL. Paste it into Tools, Diagram from text to rebuild or change it.
title "Read replicas"
direction LR
service app "Application"
[app x3]
app -> proxy "DB proxy"
db-proxy -[writes]-> db postgres "Primary"
db-proxy -[reads]-> db postgres "Replica 1"
db-proxy -[reads]-> db postgres "Replica 2"
primary -[replication]-> replica-1
primary -[replication]-> replica-2
monitor prometheus "Replication lag"
replica-1 -> replication-lag
