
π System Design Interview Classics Β· Data Flow
How search suggestions appear as you type: a prefix index built offline from past searches, served from memory, and refreshed regularly.
Drawing diagramβ¦
Data flow for search autocomplete: every search is logged to Kafka. An hourly Spark job counts queries, removes blocked terms and builds a trie with the top 10 suggestions for each prefix. The trie is stored in object storage and loaded by suggestion servers into memory. As a user types, the app calls the suggestion service, which answers from the in-memory trie; a CDN caches popular prefixes.
flowchart LR U[User types] -->|Prefix| CDN[CDN Cache] CDN -->|Cache miss| SUG[Suggestion Service] TRIE[(In-memory Trie)] -->|Top 10 for prefix| SUG SUG -->|Suggestions| U S[Search Service] -->|Search queries| K[Kafka Search Log] K -->|Queries| SP[Hourly Spark Job] BL[(Blocked Terms)] -->|Filter list| SP SP -->|New trie| OS[(Object Storage)] OS -->|Load on refresh| TRIE
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.
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.
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.