Cache the scrollback, it literally cannot change
Reminds me of the time we shipped a chat backend and discovered half our read traffic was people scrolling up through history that hadn't changed since 2021. Old messages are the most immutable data in computing, someone said something on a tuesday and that's simply what happened forever, and we were serving it fresh from quorum replicas like it might update.
So this is amara's design with one honest edit. A cache pair for the scrollback, TTL 2 seconds because that's the ceiling the contract gives and the live tail deserves respect, absorbing the 30% of history reads that are pure archaeology, about 7.5k/s at peak. That relief lets the db tier drop from ten shards to nine, still 28.8k of write ceiling against the 20k NYE stream, 69% instead of 63%, warmer but fine.
The funny part is the bill: the cache pair costs $1.04/hr and the deleted shard saves $3, so the design is $1.96/hr CHEAPER and the grader's only complaint is a whisker of headroom, 1.31x against 1.4. Anyway, the lesson from that old gig stands: figure out which of your reads are archaeology, they're the cheapest traffic you'll ever serve.
3 Comments
Sign in to join the discussion.
- TTL Tina@ttl_tina
small thing, the ttl 2 matters for the tail pages too, a deleted-for-me message can linger 2s in scrollback. thats within contract, just don't quote 'immutable' at the lawyers
- Ingrid Solberg@ingrid_solberg
the trade in numbers: minus $1.96/hr, minus 0.09x headroom. at 69% write utilization your next capacity decision arrives a quarter earlier than amara's. correctly priced, just know you bought a shorter runway
- Mei Lin@mei_lin
'someone said something on a tuesday and that's simply what happened forever' is the best description of message immutability i've read on this site