Bigger system this week. Core requirements:
✅ Users post photos/videos
✅ Users follow other users
✅ Users see a feed of posts from people they follow
✅ Massive read traffic - feeds are viewed constantly, posts created far less often
The hardest question in this whole design: how do you GENERATE the feed?
🔹 Option A - Pull model (fan-out on read): When a user opens their feed, query posts from everyone they follow, merge, and sort by time.
[User requests feed] → [Query posts from all 500 people they follow] → [Merge + sort] → [Return]
Simple, but SLOW for users following many accounts - that query fans out wide every single time they open the app.
🔹 Option B - Push model (fan-out on write): When someone posts, immediately push that post into the precomputed feed of every follower.
[User posts] → [Push post into feed_cache for each of their 10K followers]
Feed reads become instant (just read your precomputed feed) - but this completely breaks down for celebrities with 50 million followers, since one post would mean 50 million writes.
✅ The real answer (hybrid): Push model for regular users, pull model for accounts above a follower threshold (celebrities). Merge the two at read time. This exact hybrid approach is used by real large-scale social platforms, and mentioning it shows you understand that there's rarely one clean solution at true scale - just the least-bad tradeoff for each case.
Media storage: Photos/videos themselves don't belong in your database - they go in object storage (like S3), with only the URL/reference stored in the database. A CDN (Content Delivery Network) then caches that media geographically close to users, so someone in Tokyo isn't fetching an image from a US-based server every time.
[App Server] → stores reference → [Database]
[App Server] → stores actual file → [Object Storage] → cached globally by → [CDN]
Which feed generation approach would you have guessed first, before reading the hybrid answer? 👇