Wednesday, May 27, 2026 · 9:41 AM
ok can you explain timelines are precompute vs fetch-time fights like i actually need to build it
feeds force a choice between doing work when someone posts and doing work when someone opens the app
mental picture: either deliver newspapers to every doorstep overnight, or print a custom paper when each person wakes up
good, now do the real thing
not the fake diagram version
fanout-on-write pushes a new post into followers' home timelines when it is created
fanout-on-read builds the timeline by querying followed users when the viewer opens the app
so the first move is making the invisible numbers visible
exactly
celebrity accounts break naive fanout because one post may touch millions of timelines
what changes when this gets real traffic?
ranking adds another layer: freshness, relationships, engagement, blocks, muted accounts, and ads all affect ordering
search needs indexing, tokenization, ranking, freshness, spam filtering, and probably a separate search store
wait, i thought the better answer was just adding the serious-sounding tool
that is the trap
a feed is not just a list of posts. it is a distributed materialized view with product rules
ok so what bill shows up later?
fanout-on-write makes reads fast but writes expensive
fanout-on-read keeps writes cheap but can make reads slow
hybrids treat normal users and celebrity users differently
where do people usually mess this up?
assuming one database query can assemble a personalized, ranked, fresh, large-scale timeline
if i were designing this tomorrow, what should i write down first?
the read path
the write path
the thing that is allowed to be stale
the thing that absolutely is not
that is annoyingly practical
yeah. most system design is boring on purpose
decide which users get precomputed timelines, which get merged at read time, and how stale is acceptable
got it
less architecture cosplay, more pressure map
perfect
draw the pressure, then choose the machinery
Read Wed, May 27 · 9:58 AM