Scale database reads

advanced

Scenario & brief

A read-dominated service peaks at 9,000 rps. Someone keeps scaling the database up to cope, but it's expensive and still strained.

Targets: p99 ≤ 130 ms, 99.95% availability, critical durability, under $1,500/mo.

The cheaper path is to scale out reads: an ElastiCache tier for hot keys and read replicas to spread the remaining query load, rather than paying for one oversized instance. Make it Multi-AZ with backups, and keep an autoscaling compute tier across two AZs.

9,000 rps peakp99 ≤ 130ms99.95% availdurability: criticalbudget $1,500/mo

App Servers

Compute

Instance class

Scaling

Instances (static)

3instances

Availability Zones

Purchasing

System health

Erupting · SLA breach

/ 100

Score

SLA not met yet

Monthly cost

$1,301

Budget $1,500/mo · within budget

Metrics

Capacity47

Availability30

Durability25

Cost efficiency65

Requirements

Peak capacity — 10800 rps compute · 4200 rps db (need ≥ 9000 rps)
p99 latency — ~156 ms (need ≤ 130 ms)
Availability — 99.00% (need ≥ 99.95%)
Durability — at risk (need redundancy + backups)
Budget — $1301/mo (need ≤ $1500/mo)

Advisor

The database is saturated at peak — add a cache to shed read load, or scale it up.
Compute runs in a single AZ — spread across ≥2 AZs (with ≥2 instances) to meet the availability target.
The database has no Multi-AZ standby or replica — a failure risks data loss. Enable Multi-AZ and backups.

Discussion

No comments yet. Be the first to start the discussion.

For learning purposes only. Costs and capacities are illustrative, not live AWS prices. Not affiliated with or endorsed by Amazon Web Services.