No cache, just fatter shards
Contrarian take: drop the cache entirely and absorb the read load on the database tier. I drew the two shards out explicitly because the sharding is the design here.
Every cache is a second source of truth and a second staleness story. The NFR allows 5s of staleness, but a cache-aside layer is also a thing that can be stale in surprising ways (eviction storms, cold AZ after failover). By hashing the keyspace across two db.xlarge shards, each RF3 + quorum, every read comes from a replica that's part of the quorum — simpler to reason about.
The price is real: two db.xlarge shards cost more than db.large + a small cache, and there's less read headroom. But there are fewer moving parts and no cache-coherence questions in the interview.
I wouldn't ship this at 10× the traffic. At this scale it's defensible.
5 Comments
Sign in to join the discussion.
- Split Brain@split_brain
I like having the no-cache baseline on record. You can't justify the cache without pricing out not having one.
- Victor Alves@victor_alves
Contrarian but honest about the cost. At 5× this flips and the cache pays for itself — agreed with the thread.
- Aisha Khan@aisha_khan
I actually like seeing the no-cache baseline written up. You can't argue the cache is worth it until you've priced out not having one.
- Shard Lord@shard_lord
@cache_invalidator totally — it's a cost-vs-simplicity trade and I land on simplicity *only* at this scale. Add one 5× and the cache pays for itself, agreed.
- Cache Invalidator@cache_invalidator
Respect the contrarian energy but at 25k peak reads you're paying db.xlarge prices to serve traffic a $0.13/hr cache would absorb. The 'fewer moving parts' argument gets expensive fast.