15 Essential System Design Interview Questions and Solutions (2026)

Twitter's core challenge is handling asymmetric relationships — users follow others without requiring reciprocation — and generating personalized timelines at massive scale. The system must handle hundreds of millions of daily active users, billions of tweets, and extreme read-to-write ratios of roughly 1000:1.

Key Components: User service, tweet service, timeline service, fanout service, search service, and media service. The critical architectural decision is how to generate timelines: the fanout-on-write approach pre-computes timelines when a tweet is posted, storing them in each follower's timeline cache. This optimizes read performance but creates write amplification for celebrity accounts. The fanout-on-read approach merges timelines at read time, reducing write overhead but increasing latency. Twitter uses a hybrid: fanout-on-write for regular users and fanout-on-read for accounts with millions of followers.

Trade-offs: Storage cost vs. read latency, consistency vs. availability during high-traffic events, and real-time delivery vs. eventual consistency for timeline ordering.

A URL shortener converts long URLs into short, unique identifiers and redirects users when they access the short URL. The system must handle billions of URLs, support fast redirects with sub-50ms latency, and ensure globally unique short codes without collisions.

Key Components: A hash function generates the short code — either using MD5/SHA-256 with truncation (risking collisions) or a base-62 encoding of a unique counter. The recommended approach is a distributed ID generator (like Snowflake IDs) that produces 64-bit unique integers, then encodes them in base-62 to create 7–10 character codes. A relational database (with sharding by hash key) stores the mapping, with a Redis cache layer for hot URLs. The redirect service performs a cache lookup, then a database lookup, and issues a 301 or 302 redirect.

Trade-offs: 301 (permanent) vs. 302 (temporary) redirects affect caching and analytics. Custom aliases add complexity. Storage grows linearly but remains manageable with TTL-based expiration for unused links.

A real-time chat system must deliver messages with low latency, support one-on-one and group conversations, handle presence indicators (online/offline status), and ensure message delivery guarantees even when users go offline and reconnect.

Key Components: A WebSocket gateway maintains persistent connections with clients, enabling bidirectional real-time communication. The message service processes and routes messages, storing them in a message database (Cassandra or HBase for write-heavy workloads). A presence service tracks user status using heartbeats. For offline delivery, messages queue in a message store until the recipient reconnects. Group chats require a fanout mechanism — either fanout to all group members' inboxes or a shared message stream with per-user read pointers.

Trade-offs: WebSocket connections are stateful and resource-intensive, requiring sticky sessions or connection registries. Exactly-once delivery is expensive; most systems settle for at-least-once with client-side deduplication. End-to-end encryption adds latency but is expected in modern chat applications.

YouTube is a video streaming platform that must handle video uploads, transcoding into multiple resolutions and formats, global content delivery, and serving billions of video streams daily with minimal buffering. The system is heavily read-dominated with a complex write pipeline.

Key Components: The upload pipeline accepts raw video, stores it in blob storage (S3/GCS), and triggers a transcoding service that converts video into multiple resolutions (360p, 720p, 1080p, 4K) and formats (H.264, VP9, AV1). A CDN distributes transcoded video globally — popular content is cached at edge locations close to users, while long-tail content uses regional origin servers. The recommendation service generates personalized feeds. Video metadata is stored in a relational database, while analytics (views, likes) flow through a streaming pipeline like Kafka.

Trade-offs: Transcoding quality vs. processing time and cost, storage cost vs. number of encoding profiles, and CDN cache hit rate vs. infrastructure cost. Adaptive bitrate streaming (HLS/DASH) improves user experience but increases complexity.

A ride-sharing platform must match riders with nearby drivers in real-time, estimate arrival times, calculate fares, and handle GPS location updates from millions of concurrent drivers — all while maintaining low latency for a responsive user experience.

Key Components: A location service ingests real-time GPS updates from drivers and indexes them using geospatial data structures like geohashes or quad-trees. The matching service finds available drivers within a radius of the rider, ranks them by ETA and rating, and assigns the ride. A trip service manages ride state (requested, matched, in-progress, completed). The ETA service uses historical traffic data and real-time conditions to predict arrival times. Pricing applies surge algorithms based on supply-demand ratios per geographic zone.

Trade-offs: Location update frequency vs. battery and bandwidth cost, ETA accuracy vs. computation cost, and surge pricing fairness vs. revenue optimization. Driver matching must balance speed with optimality — a globally optimal match is NP-hard, so greedy algorithms are used.

A file synchronization service must efficiently transfer files between devices, handle conflicts when multiple users edit the same file, support versioning, and minimize bandwidth usage — especially for large files with small changes.

Key Components: A chunking algorithm splits files into fixed-size blocks (typically 4MB) and computes hashes for each chunk. Only modified chunks are uploaded, enabling delta sync that dramatically reduces bandwidth. A metadata service tracks file hierarchies, versions, and chunk mappings in a relational database. The block storage service stores chunks in blob storage with deduplication — identical chunks across files are stored once. A notification service pushes sync events to connected clients via long polling or WebSocket. Conflict resolution uses "last writer wins" or saves conflicting versions for manual resolution.

Trade-offs: Chunk size affects deduplication granularity vs. metadata overhead. Consistency across devices requires careful ordering of operations. Offline editing creates complex merge scenarios that simple conflict resolution cannot always handle elegantly.

A web search engine must crawl billions of web pages, build an inverted index for fast retrieval, rank results by relevance, and serve queries in under 200ms — all while the web constantly changes and grows.

Key Components: The crawler discovers and fetches web pages using BFS traversal, respecting robots.txt and politeness policies. The indexer parses pages, extracts tokens, and builds an inverted index mapping each word to the documents containing it, along with frequency and position data. The ranking engine uses hundreds of signals — PageRank, content relevance, freshness, user engagement — to order results. The query processor tokenizes user queries, looks up the inverted index, merges posting lists, and applies ranking. A cache layer stores popular query results to reduce backend load.

Trade-offs: Index freshness vs. crawl cost, index size vs. query latency, and ranking algorithm complexity vs. serving speed. Storing the full inverted index requires distributed sharding across thousands of machines.

Netflix must stream high-quality video to hundreds of millions of concurrent users worldwide while providing personalized content recommendations that keep users engaged. The system combines a massive CDN with sophisticated ML-driven recommendation engines.

Key Components: Open Connect is Netflix's proprietary CDN — servers placed inside ISPs worldwide cache the most popular content locally, reducing backbone traffic. The recommendation engine uses collaborative filtering, content-based filtering, and deep learning models to generate personalized rows on the homepage. A playback servicehandles DRM, adaptive bitrate selection, and session management. The content catalog is stored in a relational database with extensive caching. A/B testing infrastructure runs thousands of experiments simultaneously on UI, recommendations, and encoding parameters.

Trade-offs: CDN cost vs. video quality and startup latency, recommendation model complexity vs. inference latency, and global consistency vs. regional content licensing restrictions. Pre-positioning content on edge servers requires accurate demand prediction.

Instagram's core challenge is generating a personalized feed from thousands of followed accounts, storing and serving billions of photos and videos efficiently, and supporting real-time engagement features like likes, comments, and stories.

Key Components: The media service handles photo/video upload, applies filters, generates thumbnails, and stores originals in object storage with CDN distribution. The feed service generates personalized timelines — Instagram historically used a fanout-on-write model similar to Twitter but has shifted toward ranked, ML-driven feeds that prioritize content by predicted engagement. A notification service pushes real-time alerts for likes, comments, and follows. The social graph is stored in a graph database or adjacency list in a relational database, sharded by user ID.

Trade-offs: Chronological vs. ranked feeds affect user engagement differently. Fanout-on-write works well for average users but creates massive write amplification for celebrity accounts. Image quality vs. storage and bandwidth cost requires careful encoding profile selection.

Amazon's e-commerce platform must manage a product catalog with hundreds of millions of items, handle search and filtering with sub-second latency, process orders with strong consistency guarantees, and scale to handle massive traffic spikes during events like Prime Day.

Key Components: The product catalog service stores product data in a relational database with Elasticsearch powering full-text search and faceted filtering. The inventory service uses optimistic locking or distributed transactions to prevent overselling. The cart service stores cart data in a fast key-value store (Redis or DynamoDB) for quick retrieval. The order service orchestrates checkout using the saga pattern across inventory, payment, and shipping services. A recommendation engine suggests products based on browsing history and purchase patterns.

Trade-offs: Strong consistency for inventory vs. availability during peak traffic, search relevance vs. indexing latency, and personalization depth vs. privacy concerns. Microservices architecture provides isolation but introduces distributed transaction complexity.

A notification system must deliver messages across multiple channels — push notifications, SMS, email, and in-app — with delivery guarantees, user preference management, and rate limiting to prevent notification fatigue.

Key Components: A notification service receives events from various producers and routes them to the appropriate delivery channels. A message queue(Kafka or SQS) decouples producers from consumers, enabling asynchronous processing and buffering during traffic spikes. Each channel has its own worker pool — APNs/FCM for push, Twilio for SMS, and SMTP services for email. A preference service stores user notification settings (quiet hours, channel preferences, frequency caps). A template engine renders notifications with user-specific content. Delivery tracking logs status for analytics and retry logic.

Trade-offs: Delivery guarantees (at-least-once) vs. duplicate handling complexity, real-time delivery vs. batching for efficiency, and channel redundancy vs. cost. Users who receive too many notifications disengage, making rate limiting and preference management critical.

A rate limiter controls the number of requests a client can make within a given time window, protecting backend services from abuse, ensuring fair resource allocation, and preventing cascading failures during traffic spikes.

Key Components: The token bucket algorithm is the most widely used approach — each client has a bucket that fills with tokens at a fixed rate. Each request consumes a token; if the bucket is empty, the request is rejected with a 429 status code. This allows burst traffic up to the bucket size while enforcing average rate limits. Alternative algorithms include sliding window log (precise but memory-intensive), sliding window counter (approximate but memory-efficient), and leaky bucket (smooths traffic to a constant rate). The limiter sits as a middleware at the API gateway layer, storing counters in Redis for distributed coordination.

Trade-offs: Precision vs. memory usage, distributed rate limiting consistency vs. latency (Redis operations add ~1ms), and per-user vs. per-IP vs. per-API-key granularity. Handling race conditions in distributed environments requires Lua scripts or atomic Redis operations.

A distributed cache stores frequently accessed data in memory across multiple nodes, reducing database load and improving response times. The system must handle node failures, data distribution, and cache consistency at scale.

Key Components: Consistent hashing distributes keys across cache nodes — when a node is added or removed, only a fraction of keys need to be remapped, minimizing disruption. Each node stores a portion of the keyspace in memory (Redis or Memcached). A cache eviction policy (LRU, LFU, or TTL-based) manages memory when the cache is full. Cache invalidation strategies include write-through (synchronous write to cache and DB), write-behind (asynchronous DB write), and cache-aside (application manages cache population). Replication across nodes provides fault tolerance, with consistent hashing with virtual nodes ensuring even distribution.

Trade-offs: Cache hit rate vs. memory cost, consistency vs. performance (stale reads are common), and replication factor vs. write latency. Thundering herd problems arise when a popular key expires, requiring cache stampede protection like probabilistic early expiration.

A web crawler systematically discovers and downloads web pages across the internet, forming the foundation for search engines, archiving systems, and data collection platforms. It must handle billions of URLs efficiently while respecting server policies and avoiding traps.

Key Components: A URL frontier manages the queue of URLs to visit, prioritized by importance (PageRank, freshness, domain authority). The crawler uses BFS traversal — processing URLs level by level from seed URLs — with a URL deduplication filter using a Bloom filter or set membership check to avoid revisiting pages. The download pool consists of distributed workers that fetch pages concurrently. A content parserextracts text, metadata, and outgoing links from downloaded HTML. A politeness moduleenforces per-domain rate limits and respects robots.txt. DNS caching reduces lookup overhead.

Trade-offs: Crawl freshness vs. bandwidth cost, BFS breadth vs. DFS depth for discovering new content, and Bloom filter false positives vs. memory usage for URL deduplication. Handling spider traps (infinite URL generators) requires depth limits and URL pattern detection.

A payment system must process financial transactions with absolute correctness — money cannot be lost, duplicated, or incorrectly charged. It must support multiple payment methods, handle partial failures gracefully, and maintain a complete audit trail for every operation.

Key Components: An API gateway accepts payment requests and applies rate limiting, authentication, and fraud detection checks. The payment orchestratorcoordinates the payment flow across multiple services: ledger (double-entry bookkeeping), payment processor integration (Stripe, PayPal, bank APIs), and notification. Idempotency is critical — every payment request includes an idempotency key that the system checks against a deduplication store before processing, preventing duplicate charges from retries. A transaction log records every state transition for auditability. The ledger uses double-entry accounting where every debit has a corresponding credit.

Trade-offs: Consistency vs. availability (payments strongly favor consistency), synchronous vs. asynchronous processing for different payment methods, and fraud detection sensitivity (false positives) vs. user friction. Reconciliation jobs periodically verify that internal records match external processor statements.