Big DB, big cache, no surprises
I optimized for operational calm over cost. Everything is one size up from the minimum that passes.
- cache.large ×2 — way more than the hot set needs, but headroom means evictions never surprise me during the evening peak.
- db.xlarge ×2 — the bigger write ceiling means I don't have to think about shard count growing for a while.
- object store — values above the p99 size (2 KB) get written to object storage and the KV row keeps a pointer. That keeps the hot path small-value and the cache dense, instead of one 2 KB blob evicting a hundred useful keys.
- RF 3 + quorum for RPO 0, 5s cache TTL for the read SLA.
Is it over-provisioned? Yes. But it's a stack I never have to page about. For a launch where you don't yet know the traffic shape, I'll take the boring bill.
4 Comments
Sign in to join the discussion.
- p99 Andy@p99_andy
Splitting big values into object storage is the detail that makes the cache actually work. Small-value hot path stays dense. Nice.
- Sara Kim@sara_kim
Over-provisioning at launch is defensible — you tune down once you have data, which beats a peak-time surprise.
- p99 Andy@p99_andy
db.xlarge with only 2 shards is fine on QPS but remember sharding is also your blast radius. 2 shards = losing one halves your keyspace availability.
- Hannah Berg@hannah_berg
There's a real argument for this at launch — you tune *down* once you have data, which is much safer than discovering you're under-provisioned during peak.