Hard · 8 steps · ~50 min

Design a read-heavy feed on Aurora

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

A social feed is read hundreds of times for every post. Reads can scale out; writes go through one place. You will protect the database with a cache and Aurora readers, then break both on purpose: an empty cache and a failed writer.

Same problem as Social feedsNews timelinesActivity streams

This lab uses real AWS services. Limits are AWS's documented default quotas; figures AWS does not publish are marked as assumptions on each component. See every source and assumption.

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

Steps

1. 1Serve 3,000 requests/s
2. 2Grow to 25,000 requests/s
3. 3Survive an empty cache
4. 4Lose the writer
5. 5Why more readers do not help writes
6. 6The post that vanished
7. 7Lose a task
8. 8What does the insurance cost?