Availability model — payments API across three AZs
Reliability block diagram of a regional payments API — Route 53, ALB, 2-of-3 AZ stacks, Aurora storage with a hot-standby writer and a third-party card processor — solving to 99.938% steady-state availability and naming the ALB and the processor as the two blocks that cap it.
Make it your own.
title "Payments API — regional availability model"
mission 720h
# A 30-day SLO window. Every block carries an MTBF and an MTTR, so the
# figure reports steady-state availability as well as mission reliability.
block dns "Route 53 hosted zone" mtbf: 87600h mttr: 0.5h
block alb "Application Load Balancer" mtbf: 8760h mttr: 0.88h
block az1 "AZ-a stack (nodes + pods)" mtbf: 2190h mttr: 0.25h
block az2 "AZ-b stack (nodes + pods)" mtbf: 2190h mttr: 0.25h
block az3 "AZ-c stack (nodes + pods)" mtbf: 2190h mttr: 0.25h
block storage "Aurora cluster volume" mtbf: 87600h mttr: 1h
block writer "Aurora writer instance" mtbf: 4380h mttr: 0.0083h
block reader "Aurora reader (promotable)" mtbf: 4380h mttr: 0.0083h
block psp "Card processor (99.95% SLA)" mtbf: 8760h mttr: 4.38h
series {
dns
alb
kofn 2 of 3 { az1; az2; az3 }
storage
standby hot { primary: writer; spare: reader; switch: 0.995 }
psp
}