
π System Design Interview Classics Β· Data Flow
How posts reach followers' feeds: fan-out on write for normal users, fan-out on read for celebrities, and a ranked feed built from a cache.
Drawing diagramβ¦
Data flow for a social feed: a post is saved in the post store and sent to a fan-out service. For users with fewer than 10,000 followers the fan-out service writes the post ID into each follower's feed cache in Redis. For celebrities it does nothing at write time. When a user opens the app, the feed service reads their cached feed, merges recent posts from celebrities they follow, ranks them, and hydrates post details from the post store.
flowchart LR U[User] -->|New post| PS[Post Service] PS -->|Post| PDB[(Post Store)] PS -->|Post ID and author| FO[Fan-out Service] G[(Follower Graph)] -->|Followers| FO FO -->|Post ID per follower| FC[(Feed Cache - Redis)] R[Reader] -->|Open feed| FS[Feed Service] FC -->|Cached post IDs| FS CEL[(Celebrity Posts)] -->|Recent posts| FS PDB -->|Post details| FS FS -->|Candidates| RK[Ranking Model] RK -->|Ranked feed| R
The classic interview design for a service like bit.ly: short code generation, fast redirects from a cache, and click analytics processed separately.
How a one-to-one chat message is delivered in a WhatsApp-style system, with sent, delivered and read ticks, and push notifications when the receiver is offline.
The core of a ride-hailing app: drivers stream their locations, a geo index finds nearby drivers, and a matching service offers the trip to the best one.
How a token bucket rate limiter decides whether to let an API request through, using Redis so all servers share the same counts.
A notification system that sends email, SMS and push messages at scale: one API, a queue per channel, user preferences, and retries.
How search suggestions appear as you type: a prefix index built offline from past searches, served from memory, and refreshed regularly.