Step 1 of 9 · Intro

Design a read-heavy feed on Aurora

Scale reads with a cache and readers, then survive an empty cache and a failed writer.

How it works

• ›An Aurora cluster has one writer and up to 15 Aurora Replicas. All instances see one shared cluster volume, so a replica needs minimal extra work to stay current, and its lag is usually well under 100 ms.
• ›If the writer fails and a replica exists, Aurora promotes one: service is typically restored in under 60 seconds and often under 30. With no replica, a new writer is created, which typically takes under 10 minutes.
• ›ElastiCache answers repeated reads from memory. When it restarts empty, every read goes to the database until it warms again.
• ›Limits come from AWS documentation (default quotas in us-east-1). Where AWS publishes no figure, such as how many requests a container or database handles, the lab states its assumption on the component.

What you'll build

1. A plain stack for 3,000 requests a second
2. A cache and a reader for 25,000
3. Enough readers to survive an empty cache
4. A cluster that survives its writer failing
5. Why more readers do not raise write capacity
6. Read-your-own-writes with replica lag
7. A task failure and what the insurance costs