Solution Architecture and Design
Start from requirements, not products
Every architecture question hides a requirement. Separate functional requirements (what the system does) from non-functional ones (availability, latency, durability, cost ceiling, compliance scope). Two numbers drive most designs: recovery time objective (RTO, how long you can be down) and recovery point objective (RPO, how much data you can lose). Write them down before you pick a topology.
Building blocks
Regions and zones give you failure domains. A design is only highly available if traffic can leave a failed zone without a human decision. Prefer stateless, horizontally scalable tiers behind a load balancer, and decouple them with queues so a slow dependency becomes added latency rather than an outage. Choose managed services when they remove undifferentiated operational work, but verify the quotas, the support boundary, and the exit path. Managed does not mean unlimited.
Traps candidates fall for
- Treating multi-region as automatically highly available when failover is manual and untested.
- Confusing high availability (short, local failures) with disaster recovery (region-scale loss).
- Confusing scalability (handles growth) with elasticity (handles spikes without overpaying).
- Sizing for average load and never checking peak load or service quotas.
- Adding redundancy in one tier while leaving a single shared database as the bottleneck.
Rule of thumb
Design N+1 in every critical tier and size for peak with headroom. If RPO is minutes, you need continuous or asynchronous replication. If RTO is hours, a warm standby you can promote is enough; active-active is over-engineering and roughly doubles run cost.
Worked example
A team states RTO of 4 hours and RPO of 15 minutes. A pilot-light design (backups only) fails the RPO. Active-active fails the cost ceiling. A warm standby with asynchronous replication plus a rehearsed promotion runbook satisfies both constraints and is the defensible answer.