Every problem in this catalog until now had an escape hatch: some fraction of reads that repeat, so some tier that absorbs them. This one sets cacheable to zero and takes the hatch away. 90,000 feed fetches a second at the evening peak, every single one assembled for exactly one person, so every single one is a miss by definition. Welcome to fan-out land, population: your database.
So the db tier IS the read tier, and it has to win on two axes at once. Reads: 7 xlarge shards at RF 3 is 336k/s of replica capacity, 27% used by the feed flood. Writes: the same 7 shards give 22.4k/s of primary write ceiling, 42% used by 9.5k/s of posts and likes, all quorum-acked because a published post that vanishes is not a latency bug, it's a betrayal. Add them up and the tier runs at 69% on both dimensions together, headroom about 1.45x, and notice the beautiful ugly truth: you're paying for read replicas AND write primaries in the same 21 instances.
The app tier is eighteen xlarges because 99.5k/s doesn't front itself. Total damage: $33.48/hr, the most expensive reference in the catalog, and correctly so. When the data is personal, the fan-out bill comes due at the storage layer and there is nobody to split it with.
Sign in to join the discussion.
four components for the hardest read load in the catalog. nothing left to delete. this is the simplicity ceiling, i checked
the discipline to not add a cache tier is the mindset. half the designs i review have a component that exists because the author was uncomfortable, not because traffic routes through it
what breaks first here is the interesting question. both dimensions crest at ~1.45x together, which means growth doesn't give you a cheap fix: one more shard buys read AND write room at the same price. clean design, expensive problem
lol at everyone who opened this problem, typed 'cache' out of muscle memory and stared at the 0. the bones of this are right, the db is the read tier, that's the whole problem