Generated by Codex with gpt-5

Selected problem: Ride-Sharing Dispatch

Scope: Design the real-time backend that ingests rider requests and driver location updates, finds good matches within seconds, assigns exactly one driver to a rider, and keeps the trip state and live map updated until completion.

Problem framing

This is the classic “design Uber/Lyft dispatch” interview problem: a city-scale marketplace where the hard parts are not just finding a nearby driver, but doing so with fresh-enough location data, realistic ETAs, strong assignment correctness, and graceful handling of retries, timeouts, cancellations, and partial failures.

Generated by Codex with gpt-5

Selected problem: Chat/Messaging System

Scope: Design a text-first chat platform for one-to-one and small-to-medium group conversations with presence, multi-device sync, offline delivery, and durable message history.

Also see https://wiki.derricklin.net/software-development/System%20Design%20Interview/#chat-system

Problem framing

This is the classic interview problem of designing a real-time chat system without over-promising impossible guarantees. Grokking and Alex Xu both frame the core problem similarly: keep message delivery low-latency, keep history durable, handle offline users, and make multiple devices converge on the same conversation state. DDIA adds the deeper constraint: ordering, replication, partitioning, and delivery semantics must be chosen deliberately instead of hand-waving toward “global consistency.”

Generated by Codex with gpt-5

Selected problem: News Feed

Scope: Design a personalized feed service that lets users publish posts, reads recent and ranked posts from accounts they follow, and keeps feed retrieval fast while handling fanout skew, stale caches, media, and eventual consistency.

Also see https://wiki.derricklin.net/software-development/System%20Design%20Interview/#news-feed

Problem framing

This is the classic “design a Facebook News Feed / Twitter timeline / Instagram home feed” interview problem. Grokking and Alex Xu frame it as two linked flows: feed publishing, where a new post enters storage and is propagated to followers, and feed retrieval, where a user gets a fast, paginated, hydrated list of feed items. DDIA’s Twitter home-timeline example explains the central tradeoff: doing more work at write time makes reads fast, but high-follower authors create fanout storms; doing more work at read time avoids write amplification, but every feed read becomes an expensive merge.

Generated by Codex with gpt-5

Selected problem: Search Autocomplete

Scope: Design a low-latency autocomplete service that returns top suggestions for a typed prefix, learns from query activity over time, and handles hot prefixes, moderation, and multilingual growth without rebuilding everything on every keystroke.

Problem framing

This is the classic “design Google search suggestions” or “typeahead” interview problem. Alex Xu frames it around a brutally simple user-facing requirement: every keystroke can trigger a request, so suggestion reads must be extremely fast. Grokking’s interview style also applies cleanly here: clarify prefix-only versus infix matching, top-K size, language scope, freshness needs, and latency targets before arguing about data structures. The interview answer usually starts with a trie or prefix tree, but DDIA adds the more durable framing: autocomplete is a derived read model built from query logs, aggregation, filtering, and ranking pipelines, so the real design question is how to keep that read model fresh, cheap, and rebuildable.

Generated by Codex with gpt-5

Selected problem: Web Crawler

Scope: Design a large-scale, HTML-first web crawler for search indexing that discovers new URLs, respects host politeness and robots rules, deduplicates content, and keeps important pages reasonably fresh.

Also see https://wiki.derricklin.net/software-development/System%20Design%20Interview/#web-crawler

Problem framing

This is the classic “design Googlebot” interview question. Grokking emphasizes the minimum crawler loop: start from seed URLs, fetch pages, extract links, dedupe, and repeat. Alex Xu frames the real interview difficulty more accurately: the hard parts are URL frontier design, politeness, prioritization, freshness, robustness, and avoiding bad content. DDIA supplies the missing systems lens: frontier queues, dedupe tables, document storage, and downstream indexing are separate dataflow stages, so the design should favor partitioned state, replayable logs, and idempotent consumers rather than pretending the entire pipeline is one giant transaction.

Generated by Codex with gpt-5

Selected problem: API Rate Limiter

Scope: Design a distributed server-side rate limiter that enforces per-user, per-IP, per-tenant, and per-route API quotas with very low decision latency across many stateless services.

Problem framing

This is the classic server-side API rate limiter from Grokking and Alex Xu: every request should get a cheap admission decision before it reaches expensive application logic.

Generated by Codex with gpt-5

Selected problem: Distributed Cache

Scope: Design a distributed in-memory cache service that provides very low-latency GET/SET/DELETE/INCR operations with TTLs, eviction, sharding, and failover for many stateless application services.

Problem framing

This is the classic “design Memcache / Redis-class cache” interview problem: build a shared cache tier that is much faster than the system of record, scales horizontally, and fails gracefully instead of turning into a new bottleneck.

Generated by Codex with gpt-5

Selected problem: Notification System

Scope: Design a soft real-time notification platform that accepts events from internal services, renders user-facing messages, respects user preferences, and dispatches push, email, SMS, and in-app notifications reliably at large scale.

Also see https://wiki.derricklin.net/software-development/System%20Design%20Interview/#notification-system

Problem framing

This is the classic “design a notification system” interview problem: build the shared infrastructure that product teams use whenever they need to notify users about security alerts, messages, payments, delivery updates, marketing campaigns, or feed changes. The core challenge is not just calling APNs, FCM, an SMS gateway, or an email provider. The harder parts are durable intake, preference filtering, fanout, queue isolation, retries, deduplication, rate limiting, observability, and honest delivery semantics.

Generated by Codex with gpt-5

Selected problem: TinyURL

Scope: Design a highly available URL shortening service that creates compact aliases, resolves them with very low latency, and records click analytics without putting the redirect path at risk.

Also see https://wiki.derricklin.net/software-development/System%20Design%20Interview/#url-shortener

Problem framing

This is the classic URL shortener problem: map a short code to a long URL, make redirects fast, and survive a very read-heavy workload with occasional viral hot keys.