Relational versus wide-column for a news feed

WHAT THIS TESTS The interviewer checks whether you choose storage by access pattern and scale, and whether you understand fan-out strategies for feeds.

A GOOD ANSWER COVERS The defining question is fan-out on read versus fan-out on write. A relational schema keeps users, posts, and a follows table normalized; the feed is generated at read time by joining a user's followees to recent posts and sorting. This is flexible and consistent, supports ad hoc queries, but the read-time join over many followees becomes the latency bottleneck at scale. A wide-column store like Cassandra inverts this: you maintain a feed table partitioned by user_id and clustered by time, and when someone posts you write a copy into each follower's partition. Reads then become a single fast partition scan, ideal for low latency, at the cost of heavy write amplification and eventual consistency.

The key complication is the celebrity problem: fan-out on write to millions of followers is prohibitive, so a hybrid pulls posts from high-follower accounts at read time while pre-fanning normal accounts.

COMMON WRONG ANSWERS Picking NoSQL because it is web-scale without explaining write fan-out. Ignoring the celebrity edge case. Claiming Cassandra gives strong cross-partition transactions. Forgetting that the relational approach is perfectly fine until the join cost dominates.

LIKELY FOLLOW-UPS How do you handle the celebrity fan-out? How do you bound feed size per partition? How do you backfill a new follow? What consistency does the feed actually need?

ONE CONCRETE EXAMPLE Relational: feed = join follows where follower_id = me to posts, order by created_at desc limit 50. Cassandra: feed_table((user_id) partition, (created_at, post_id) clustering); on each post, insert a row into every follower's partition, so my feed read is one partition query returning the latest 50 rows.