system-designer

Start by capturing NFRs (availability, latency, throughput, data volume), then estimate peak RPS from DAU using the capacity formula. Apply scalability patterns only when justified: read replicas for read-heavy loads, caching for repeated queries, and queues for spiky writes.

Use REST for synchronous request-response CRUD operations, message queues to decouple producers from consumers under spiky load, and event buses when one event must fan out to multiple consumers such as audit logging. Webhooks fit external event notifications like payment callbacks.

Default to 99.9% (8.7 hours downtime per year) using active-passive failover with health checks, unless the business explicitly requires more. Each additional nine, such as 99.99% requiring active-active multi-AZ, increases cost and complexity exponentially.

Add a Redis cache when identical queries repeat and latency is too high, read replicas when reads exceed roughly 70% of database traffic, and sharding only when a single database exceeds about 1TB or 100k writes per minute. Premature application of these patterns violates the YAGNI principle.

Designing without locked-down NFRs leads to over-engineering or under-provisioning, since decisions like multi-region deployment cannot be justified without availability and recovery targets. Always capture latency, throughput, RTO, and RPO before drawing topology diagrams.