MushyBook
All challenges

Cache a read-heavy API

beginner
Scenario & brief

A mostly-read API peaks at 3,000 requests/sec. Right now every request hits the database directly, it runs in a single AZ, and backups are off. It misses the availability and durability targets and the database is saturated.

Targets: p99 ≤ 150 ms, 99.9% availability, standard durability, under $900/mo.

The fixes are exactly what you'd reach for on a read-heavy service: put an ElastiCache tier in front of the database to shed read load, run the app across two AZs, make the database Multi-AZ (a single instance can't hit 99.9%), and turn on backups. Then right-size so you're not overpaying.

3,000 rps peakp99 ≤ 150ms99.9% availdurability: standardbudget $900/mo

App Servers

Compute

2instances

System health

Erupting · SLA breach

28

/ 100

Score

SLA not met yet

Monthly cost

$478

Budget $900/mo · within budget

Metrics

Capacity57
Availability30
Durability25
Cost efficiency79

Requirements

  • Peak capacity — 3600 rps compute · 1700 rps db (need ≥ 3000 rps)
  • p99 latency — ~164 ms (need ≤ 150 ms)
  • Availability — 99.00% (need ≥ 99.90%)
  • Durability — at risk (need backups)
  • Budget — $478/mo (need ≤ $900/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

Sign in to join the 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.