Compare fan-out-on-write vs fan-out-on-read for an activity feed

What's really being asked

This question tests whether you can reason about asymmetric read and write loads in distributed systems and whether you treat follower distribution as a first-class design constraint. Interviewers want to see that you understand the same architecture cannot serve normal users and celebrities equally well, and that you can derive a threshold from operational limits rather than guessing.

The full answer

First, define fan-out on write as pre-computing timelines so reads are O(1) but writes are O(N) where N is follower count. Second, define fan-out on read as storing posts once so writes are O(1) but reads are O(F) where F is the number of accounts followed. Third, quantify the celebrity problem: a user with 80 million followers would trigger 80 million cache writes in seconds, saturating the write path and delaying all other posts. Fourth, quantify the read amplification problem: a power user following 5,000 accounts would trigger 5,000 parallel queries per timeline load, making reads latency-sensitive and unpredictable. Fifth, propose a hybrid split by follower threshold T, where users below T get pushed and celebrities above T get pulled, with T derived from acceptable write throughput such as 50,000 writes per second divided by post rate.

The mistakes people make

A red flag is unconditionally choosing fan-out on write because it is simple and fast for reads without acknowledging the celebrity storm risk. Another red flag is unconditionally choosing fan-out on read because it saves storage without acknowledging that read latency grows linearly with follow count. A third red flag is treating the celebrity problem as a Twitter-specific edge case rather than a fundamental tension in any feed system.

What usually comes next

The interviewer may ask how you would store the post index for fast per-user retrieval in the pull path. They may ask how to handle a user who follows both normal friends and celebrities in the same timeline load. They may ask you to compute the exact storage cost of precomputed timelines or to choose T given a specific Redis cluster size and post rate.

A concrete example

Consider a platform with 300 million DAU, an average of 200 followers per user, and 17,000 posts per second. Fan-out on write produces 3.5 million cache writes per second on average, which fits in a 20-shard Redis cluster, but a single celebrity post with 10 million followers would overwhelm it. Fan-out on read shifts that same 3.5 million query load to the read path, which is user-facing and latency-sensitive. A hybrid model with a threshold around a few thousand followers keeps the write path bounded while keeping reads fast for the vast majority of users.