Fan-out architectures

Fan-out is how news feeds, notifications, and social timelines work. One producer generates a message that goes to N consumers. The design question: when do you do the work?

Fan-out on write (push)

When a user posts, write to every follower's inbox immediately. Reads are fast (just look at your inbox).

• Pro: read latency is constant. Cheap reads.
• Con: write amplification. A user with 1M followers triggers 1M inbox writes.
• Worst case: celebrity with 100M followers posts. That's 100M writes for one tweet.

Fan-out on read (pull)

When a user requests their feed, query every followee's posts in real time, merge, rank.

• Pro: cheap writes (one write per post).
• Con: read is expensive (fan-in across all followees).
• Worst case: power user follows 5000 accounts, every feed load is 5000 queries.

Hybrid (production reality)

Twitter, Instagram, Facebook all use hybrid:

• For normal users: fan-out on write to follower inboxes.
• For celebrities (>10k followers): fan-out on read. Don't write to inboxes; let active users pull on demand.
• Merge at read time: user's feed = inbox + dynamic pull from celebrity accounts they follow.

This bounds write amplification (no 100M writes for one tweet) and keeps reads fast for typical users.

Inbox storage

Inboxes are typically:

• Capped (last 800 entries per user, like Twitter).
• Memory-resident (Redis sorted sets keyed by user_id).
• Sharded by user_id.

Posts in the inbox are usually just IDs. The actual content is fetched separately and cached.

Activity feeds vs notification feeds

• Activity feeds: timeline-style, append-only, time-ordered. News feed, Instagram home.
• Notification feeds: actionable, often aggregated (user A and B liked your photo).

Different storage and ranking strategies.