Detailed Component Design

Fan-Out on Write

When a user tweets, the Home Feed Generator looks up their follower list and inserts the tweet (with its computed score) into every follower's Redis Sorted Set. For an average user with 200 followers, this means 200 cache writes per tweet. Across 1B tweets per day, this produces 200B fan-out writes per day.

This works because the writes are asynchronous and distributed across many Redis servers. The tweeting user does not wait for fan-out to complete. The Message Queue absorbs traffic bursts. And 200 writes per tweet is a small, predictable cost.

Tweet Database Sharding (by Tweet ID)

Sharding the tweet database by tweet ID distributes writes evenly regardless of author popularity. A celebrity and an average user both generate tweets with randomly distributed IDs, so no single shard becomes a hot spot.

The trade-off is that querying "all tweets by user X" requires scatter-gather across all shards. But this is acceptable because hashtag lookups (the more common query pattern) are fast because the Hashtag document stores tweet IDs directly, and the system can route each ID to its specific shard.

Feed Cache Sharding (by User ID)

Sharding the Redis feed cache by user ID means every feed read hits exactly one shard. The Home Feed Service hashes the user ID, finds the shard, and retrieves the Sorted Set. Each user's feed is roughly the same size (20 tweets), so the load distributes evenly.

The trade-off is that the Home Feed Generator must write to many shards during fan-out. A tweet from a user with 1,000 followers requires writes to potentially hundreds of different cache shards. But writes are async and batched, making this manageable.

Submissions

Displaying Solutions with Scores Ranging from 1 to 10