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

Two designs, and the DR test that passed while every write failed

An Aurora global database spans two Regions. The disaster-recovery drill promotes the secondary, and the promotion itself is flawless: it completes in minutes, the new primary accepts writes from a console query, and the runbook is signed off.

The booking service, which nobody restarted, has been failing every write for the whole drill. It is connected, it is authenticated, and the database it is talking to is refusing to write.

Both designs point the application at a name. Choose the one that is still pointing at a writable cluster after a failover.
!Read traffic is fine throughout. Every INSERT returns a read-only error from a healthy cluster in a healthy Region, and the DR dashboard is green because the failover it measures did succeed.There are two names here that both look like the database, and only one of them moves when the primary does.
Design AThe old primary's cluster endpoint

Boundaries, outermost first: eu-central-1 — promoted: New cluster (idle) eu-west-1 — demoted: Old cluster (read-only) Outside every boundary: Booking service (writes), Cluster endpoint (pinned) Connections: Booking service calls Cluster endpoint — INSERT Cluster endpoint calls Old cluster — resolves to

Booking servicewrites
Cluster endpointpinned
Old clusterread-only
New clusteridle
Design BThe global writer endpoint

Boundaries, outermost first: eu-central-1 — promoted: New cluster (accepting) eu-west-1 — demoted: Old cluster (read-only) Outside every boundary: Booking service (writes), Global writer (follows) Connections: Booking service calls Global writer — INSERT Global writer calls New cluster — resolves to

Booking servicewrites
Global writerfollows
Old clusterread-only
New clusteraccepting
Two designs, one brief. Read both, then choose the one that meets it.