News Feed / Timeline

A home timeline looks deceptively simple: users follow people, and they see recent posts from those people, newest-first. The trap is that the two operations pull in opposite directions. Reads are enormous and latency-sensitive — every app open hits the feed, and a slow feed is a dead product. Writes are cheap individually but catastrophically amplified: when an account with fifty million followers posts once, that single write potentially needs to touch fifty million timelines. You cannot optimize one side without paying for it on the other, and the whole craft of this problem is choosing where to pay. This guide walks from a blank page to the reference architecture the SysGym simulator grades you against: a hybrid fan-out feed with a materialized timeline cache, an asynchronous fan-out queue, a replicated feed API, and a posts datastore. The simulator pushes 12,000 feed reads per second, ramps to 1.6x at peak hours, kills a feed-API node, triples offered load with a celebrity post, then stalls the posts database outright and finally slows it 8x. Throughout, it holds you to a five-part contract: availability at or above 98 percent, a 120ms p99, at least 12,000 rps of sustained throughput, peak saturation at or below 0.9, and a cost footprint at or below 9 provisioned units. Every choice below is justified against those targets — and the reference design clears all five (98.8 percent availability, a 48ms p99, roughly 23k rps served, 30 percent peak saturation, 7 cost units).