System Design Interview Questions and Answers

I would first clarify expected traffic, link lifetime, custom aliases, analytics, and the availability target. The core APIs are createShortUrl(longUrl, optionalAlias) and redirect(shortCode). A relational or key-value store can hold the short-code-to-URL mapping, while a Base62-encoded sequence or a distributed ID generator produces compact, unique keys without retry-heavy collisions.

Because redirects dominate writes, I would cache popular mappings close to users and use a CDN or edge layer where appropriate. I would partition the primary store by a stable hash of the short code, replicate it across availability zones, and make redirect reads tolerant of a brief replication delay. The final discussion should cover expired links, abuse detection, hot keys, analytics as an asynchronous pipeline, and what happens when the cache or a region fails.

I would clarify whether the scope includes one-to-one chat, groups, media, read receipts, and offline delivery. Clients can maintain WebSocket connections to a fleet of connection servers. A routing or presence service maps each active user and device to its connection, while a durable message service assigns conversation-scoped sequence numbers and stores messages before acknowledging the sender.

Messages should be at-least-once with idempotent client handling, because promising exactly-once delivery across networks is usually unrealistic. Online recipients receive a push over their active connection; offline devices retrieve messages from a per-user or per-conversation inbox and may also receive a platform push notification. I would then discuss ordering within a conversation, group fan-out, attachment storage, encryption boundaries, backpressure, and reconnect synchronization.

I would separate post creation from feed generation. Posts are written to a durable post store and an event is published for feed processing. For most users, fan-out on write can append post references to follower inboxes so reads stay fast. For celebrity accounts, fan-out on read avoids millions of synchronous or queued writes, so a hybrid strategy is usually more practical.

The read service merges precomputed inbox entries with posts from high-fan-out accounts, applies ranking, enforces privacy rules, and returns cursor-based pagination. A cache protects the hottest timelines and post objects. I would call out eventual consistency, duplicate suppression, deleted posts, ranking feature freshness, hot partitions, and how I would degrade gracefully to chronological results if the ranking service is unavailable.

I would define the rider request, driver availability, live tracking, matching, trip, and payment flows. Driver apps publish throttled location updates to a regional ingestion service. A geospatial index—such as geohash cells or an in-memory spatial structure—keeps the latest available drivers searchable without using the transactional trip database for every location update.

The matching service searches nearby cells, ranks candidates by ETA and marketplace rules, and offers the trip with a short lease. A transactional trip service owns the trip state machine so only one driver can accept a request. Events then update notifications, pricing, analytics, and location history asynchronously. I would discuss surge traffic, stale locations, double acceptance, regional partitioning, safety workflows, and degraded operation when maps or payments are unavailable.

I would split metadata from file bytes. A strongly consistent metadata service tracks ownership, directory structure, versions, and permissions, while immutable chunks live in replicated object storage. The client divides large files into content-addressed chunks, uploads only missing chunks through pre-signed URLs, and commits a new file version after all required chunks are durable.

A change log per user or workspace lets devices incrementally synchronize updates. Version vectors or explicit server versions help detect concurrent edits; the product can preserve both copies when automatic merging is unsafe. I would discuss resumable uploads, checksums, encryption, garbage collection for unreferenced chunks, permission changes, regional durability, bandwidth controls, and preventing cross-tenant data leakage during deduplication.

I would clarify whether suggestions come from a fixed catalog, popular queries, personalized history, or all three. The online path needs a very small latency budget: normalize the prefix, retrieve candidates from an in-memory prefix index such as a compressed trie or finite-state structure, merge optional personalized candidates, rank them, and return a small result set from a region close to the user.

A stream or scheduled pipeline aggregates query popularity, filters sensitive or abusive phrases, calculates scores by locale and time window, and publishes versioned index snapshots. Caches absorb repeated prefixes, while snapshot rollouts allow fast rollback. I would cover misspellings, Unicode normalization, trending-query freshness, privacy for personal history, memory limits, and fallback to non-personalized popular suggestions.

Producers should send a typed notification request to a durable queue instead of calling email, SMS, or push vendors directly. A notification orchestrator validates the request, loads user preferences and templates, applies rate and quiet-hour policies, and creates one delivery job per eligible channel. Channel-specific workers then call providers behind adapters so vendors can be changed or failed over independently.

Each request needs an idempotency key, and each attempt needs durable status so retries do not create duplicates. Exponential backoff handles transient failures, while permanent failures and exhausted retries go to a dead-letter queue. I would also discuss priority lanes, scheduled sends, tenant quotas, template versioning, unsubscribe compliance, provider webhooks, delivery metrics, and load shedding during a campaign spike.

The upload service should issue a resumable upload session and send video bytes directly to object storage. After the original file is durable, an event starts an asynchronous workflow that validates the media, transcodes it into multiple resolutions and codecs, creates segmented manifests and thumbnails, and records processing status in a metadata database.

Playback clients request a manifest and then fetch segments through a CDN, adapting bitrate to bandwidth and device conditions. Origin storage holds immutable segments, making caching safe and recovery straightforward. I would discuss popular-video cache warming, upload quotas, copyright and moderation hooks, failed transcodes, regional origin strategy, view-count aggregation, access control for private videos, and keeping metadata available even when processing is delayed.

I would model payments as an explicit state machine—created, authorized, captured, failed, refunded—rather than a single mutable status flag. Every write API accepts an idempotency key so client retries return the original result. A double-entry ledger records immutable money movements, while a separate payment record tracks the orchestration with processors and banks.

External calls are inherently uncertain, so workers retry safely and provider webhooks are authenticated, deduplicated, and processed asynchronously. A reconciliation job compares the internal ledger with provider settlement files and opens discrepancies for investigation. I would cover PCI scope reduction through tokenization, audit trails, currency precision, duplicate callbacks, refunds, chargebacks, regional failover, and why financial correctness may take priority over temporary availability.

I would begin with the policy: requests per identity, route, tenant, and time window, plus whether short bursts are acceptable. A token bucket is a strong default because it allows controlled bursts while enforcing a long-term rate. Gateways derive a stable key and execute an atomic update in a low-latency shared store, often via a server-side script, returning both the decision and remaining quota.

For global scale, I would prefer regional enforcement with centrally distributed configuration unless the product requires a strict global limit. Local token leases can reduce shared-store traffic at the cost of bounded overshoot. I would discuss hot keys, clock assumptions, weighted requests, configuration versioning, observability, and an explicit fail-open or fail-closed choice for each endpoint when the limiter store is unavailable.

Clients can route keys with consistent hashing or a centrally managed partition map so adding a node moves only part of the keyspace. Each partition has replicas for availability, and the system exposes simple get, set, delete, and optional compare-and-set operations. Memory is bounded with TTLs and an eviction policy such as approximate LRU or LFU.

I would make the consistency contract explicit: many caches favor availability and may briefly serve stale data, while selected use cases require primary reads or version checks. Request coalescing, jittered expirations, and stale-while-revalidate reduce stampedes. I would cover replication lag, node membership, rebalancing, hot-key replication, large-value limits, cache warming, metrics, and how applications continue safely when the cache misses or is unavailable.

I would keep catalog browsing eventually consistent but protect checkout with an inventory reservation. When checkout begins, the inventory service atomically reserves available units for a short TTL and returns a reservation ID. The order service creates a pending order, the payment service authorizes funds, and a saga coordinates confirmation or compensating actions without relying on a distributed database transaction.

If payment succeeds, the reservation becomes a committed decrement and the order advances; if payment fails or the reservation expires, stock is released. Every command and event is idempotent, and an outbox pattern prevents a committed database change from losing its event. I would discuss overselling, flash-sale hot products, cart pricing snapshots, retries, refunds, fulfillment handoff, reconciliation, and user-visible recovery from an ambiguous payment result.

The crawler starts with a durable URL frontier partitioned by host or domain so one scheduler can enforce per-site politeness and robots.txt rules. Fetch workers request eligible URLs, resolve DNS through a cache, download within strict size and timeout limits, and store raw content in object storage. A parsing pipeline extracts normalized links and metadata before adding unseen URLs back to the frontier.

URL canonicalization plus a probabilistic filter and a durable seen set limit repeated work; content fingerprints detect different URLs serving the same page. At scale, priorities should reflect freshness, importance, crawl cost, and change frequency. I would cover crawler traps, malicious content, retry classes, recrawl scheduling, DNS and host hot spots, backpressure, exactly where data loss is acceptable, and how to resume after worker or region failure.