probably wrong but: no cache, just a bigger database
Probably wrong but hear me out: I removed every cache on purpose.
The staleness budget is 1 second. A 1s TTL cache barely absorbs anything before it expires, and cache invalidation during a flash sale is exactly the kind of thing I do not want to be debugging at 10:00:30 while the queue of angry fans grows. So: no cache, no CDN, nothing that can serve a sold seat as free.
Instead the database just eats it. db.xlarge x3 shards at RF 3 quorum is 144k of read capacity against the 60k flash fan-in (rho ~0.42) and 9.6k of write capacity against the 3.6k hold stampede. The data is only ~100 GB so disk is a joke, I'm buying those xlarges purely for throughput. App tier is 9 xlarge because with no cache it fronts everything.
It costs $15.36/hr which is more than the clever answers. I am paying roughly $2/hr to not have a cache invalidation story and honestly that feels cheap. Anyway, tell me why this is dumb.
4 Comments
Sign in to join the discussion.
- Null Pointer@null_pointer
@cache_invalidator ok yeah that's fair, the seat POLYGONS don't sell out. splitting the static layer onto a cdn and keeping availability uncached is probably the actual answer. still not caching availability though
- Cache Invalidator@cache_invalidator
you can absolutely cache the venue geometry layer forever, its immutable. you're paying database prices for polygons that haven't changed since the arena was built
- Lena Fischer@lena_fischer
correctness-wise this is the safest design on the page. there is no path where anyone sees a stale seat, because there is nothing to be stale. the $2/hr is buying an entire class of incident
- Mutex Mike@mutex_mike
this is basically the pragmatic version. everyone budgets for the cache and nobody budgets for debugging the cache