You are on the platform team of a professional social network: about 900 million registered members, 140 million daily actives, thousands of microservices across four data centres, and Kafka as the event backbone. The home feed is the most-visited surface. Last quarter a slow ranking-model rollout pushed feed p99 to four seconds and mobile clients showed empty feeds for 40 minutes.
The interviewer asks“Design the feed-serving system end to end. I want to hear how a new post reaches followers' feeds, how a feed request is served inside a tight latency budget, and exactly what happens when parts of it are slow or down.”
I'd split it into a write path and a read path. Writes go through Kafka to fan-out workers that push activity IDs into per-member inboxes, except for very high-follower accounts and dormant members, which are merged in at read time. Reads go through a mixer that runs candidate generation in parallel, a cheap first-pass ranker, a heavier second-pass model and a blending step, with an explicit per-hop latency budget and propagated deadlines inside a 300 ms p99. Every hop has a defined degraded answer, and the whole service walks a ladder — trimmed sources, light ranking, cached feed, chronological inbox, static snapshot — driven automatically by overload and dependency signals, with an SLI that treats an empty feed as a failure.
A free account unlocks the rest of it, and saves your progress across every track.