sydepsystem design atlas

Social Timeline (Twitter-style)

Fan-out posts to follower timelines, cached for fast reads.

AdvancedSocialWeb
ClientClientAPI GatewayNetworkingPost ServiceComputePosts StoreStorageSocial GraphStorageFan-out QueueMessagingFan-out WorkerComputeTimeline CacheStorageMedia CDNNetworking

Posting writes to a durable store and publishes a fan-out event; a worker pushes the post into each follower's precomputed timeline cache so reading a timeline is a single cache lookup, not a live join over the social graph.

When to use it

  • Read volume for timelines vastly exceeds write volume (classic read-heavy social feed)
  • Most accounts have a follower count small enough that fan-out-on-write is affordable

Trade-offs

  • Celebrity accounts with millions of followers make write-time fan-out prohibitively expensive; needs a hybrid pull model for them
  • Timeline cache and the durable post store can briefly disagree during fan-out lag

Components used

Mobile AppAPI GatewayManaged App ServiceDocument DatabaseGraph DatabaseMessage QueueContainer ServiceCacheCDN

How it works

  • On write, a new post is fanned out into each follower's precomputed timeline, so reading a feed is a single cheap lookup.
  • This trades expensive writes for cheap reads, which is correct because feeds are read far more often than posts are created.
  • Accounts with enormous follower counts are handled differently — their posts are merged in at read time instead of fanned out.

Used in the wild

  • Follower-based social feeds.
  • Activity streams inside collaboration products.
  • Notification inboxes with similar read/write asymmetry.

Good to know

  • Fan-out on write for a user with 100 million followers would mean 100 million inserts for one post, so every large platform runs a hybrid: fan-out for normal accounts, fan-in at read time for celebrities.
  • Timelines are usually capped at a few hundred entries. Nobody scrolls to the bottom, and unbounded per-user timelines would dominate storage.