wtf( )unctionsystem design, drawn
← all problemsAWS SA ProHard

Three database instances, and the reads all land on one

A reporting-heavy application on RDS is running out of read capacity. Writes are latency-sensitive — they sit in a checkout path — and the business wants a failure in one Availability Zone to be survived automatically, without anyone being paged to run a procedure.

Both plans below put three database instances in three Availability Zones in one Region, and both cost about the same. One of them serves reads from one instance.

Choose the deployment that adds read capacity and automatic failover without making writes slower.
?Two of these three instances look like read capacity on the diagram. In one design only one of them is.
Design AMulti-AZ deployment, plus a read replica

Boundaries, outermost first: us-east-1b: Standby (no reads) us-east-1a: App (the caller), Primary (all reads) us-east-1c: Replica (async) Connections: App calls Primary — writes and reads Primary calls Standby — synchronous — and the failover target Primary publishes to Replica — asynchronous — promoted by hand App calls Replica — reporting reads App controls Standby — same endpoint after failover

Appthe caller
Primaryall reads
Standbyno reads
Replicaasync
Design BMulti-AZ DB cluster: two readers, both live

Boundaries, outermost first: us-east-1b: Reader 1 (readable) us-east-1a: App (the caller), Writer (one ack) us-east-1c: Reader 2 (readable) Connections: App calls Writer — writes Writer publishes to Reader 1 — semisynchronous — a failover target Writer publishes to Reader 2 — semisynchronous — a failover target App calls Reader 1 — reads App calls Reader 2 — reads

Appthe caller
Writerone ack
Reader 1readable
Reader 2readable
Two designs, one brief. Read both, then choose the one that meets it.