The holy grail of backend design. Users connect to a Load Balancer, which distributes their requests evenly across multiple Web Servers, which finally read/write data to a SQL Database.

Design a URL shortening service like TinyURL or bit.ly. Users submit a long URL and receive a short 7-character link. When someone clicks the short link, they are redirected to the original URL. The system needs to handle 100M URLs generated per day with a 10:1 read-to-write ratio.

Design a rate limiter that throttles API requests. It should allow a configurable number of requests per time window (e.g., 100 req/min per user). The rate limiter sits in front of your API servers and must be fast and distributed.

Design a notification system that supports push notifications (iOS/Android), SMS messages, and email delivery. The system should handle 10M daily notifications with different priorities and retry failed deliveries.

Design a distributed key-value store similar to Amazon DynamoDB or etcd. Support PUT(key, value) and GET(key) operations. The system must handle 1M QPS with horizontal scaling, data replication, and consistent hashing for key distribution.

Design a highly available load balancing layer using consistent hashing to distribute traffic across a dynamic set of cache servers. The system must minimize cache rebalancing when servers are added or removed and support heterogeneous server capacities.

Design a web crawler that downloads billions of web pages. The crawler should be polite (respect robots.txt), handle duplicate URLs, and process pages in parallel across many worker nodes.

Design a distributed unique ID generator that produces 64-bit IDs globally unique, time-ordered, and capable of generating 10,000+ IDs/millisecond with no single point of failure.

Design a social network news feed like Facebook/Twitter home timeline. Posts from followed users should appear in the feed, ordered by recency and relevance. The system serves 500M DAU with a read-heavy load (100:1 read/write ratio).

Design a real-time chat system supporting 1-on-1 and group messaging for 2B users. Messages must be delivered in under 100ms, stored reliably, and support offline delivery.

Design a search autocomplete system (typeahead) like Google Search suggestions. For every keystroke, return the top 5 suggestions within 100ms. The system processes 10M search queries per day.

Design a video upload and streaming platform handling 1B daily views and 500 hours of video uploaded per minute. Support adaptive bitrate streaming (HLS/DASH) and global delivery. This is one of the most demanding bandwidth challenges in system design — a single 4K video stream consumes 15-25 Mbps, and your platform must serve millions of concurrent streams without buffering. The upload path begins at the Client, which chunks large video files into segments and sends them through a Load Balancer to the API Gateway for authentication and rate limiting. The API Gateway routes uploads to Web Servers, which validate metadata (title, description, tags) and persist it to a relational Database while writing raw video bytes to Blob Storage. A Message Queue then dispatches transcoding jobs to Workers — each video must be encoded into multiple resolutions (360p, 720p, 1080p, 4K) and formats (H.264, VP9, AV1) to support Adaptive Bitrate Streaming. Workers produce HLS/DASH manifests alongside the transcoded segments and push them back to Blob Storage. The viewing path is read-heavy at extreme scale. When a user requests a video, the Client resolves the nearest CDN edge node. The CDN caches video segments so that popular content is served entirely from the edge, absorbing over 99% of bandwidth. Cache misses fall through to Blob Storage origin. Video metadata and recommendation data are served by Web Servers backed by a Cache layer for sub-millisecond lookups, with the Database as the source of truth for watch history, subscriptions, and channel data. Resilience is critical: dual Web Servers behind the Load Balancer eliminate single points of failure, while Monitoring tracks transcoding queue depth, CDN hit ratios, and stream start latency. The Message Queue decouples upload acceptance from transcoding, ensuring the system degrades gracefully under sudden upload spikes rather than dropping requests. Content-based filtering and copyright detection run as additional Worker tasks, scanning each uploaded video against a hash database of known copyrighted material before publishing.

Design a cloud file storage system like Google Drive supporting 1B users. Files should sync across devices, support sharing with access controls, and handle files up to 5GB. File storage at this scale is fundamentally a consistency problem — when a user edits a document on one device, every other device must converge to the same state without data loss or silent corruption. The upload path starts at the Client, which splits files into fixed-size blocks (typically 4MB) and computes content-addressable hashes for each block. Only blocks that differ from the previously synced version are uploaded — this is delta sync, which reduces bandwidth by 90% for incremental edits. Blocks flow through the Load Balancer to the API Gateway for authentication and quota enforcement, then to Web Servers that orchestrate the upload. Web Servers write raw blocks to Blob Storage (the durable object store) while recording block metadata, file trees, and version history in a relational Database with ACID guarantees. The sync protocol is bidirectional: the client periodically polls (or receives push notifications via Message Queue) for changes made on other devices. The Web Server computes a diff between the client’s last-known version vector and the current server state, then sends only the changed block references. Conflict resolution follows last-writer-wins for non-collaborative files. A Cache layer accelerates metadata lookups for file listings and permission checks, which are extremely read-heavy. Workers handle background tasks: generating thumbnails, scanning files for malware, indexing document contents for search, and garbage-collecting orphaned blocks after deletions. The Message Queue decouples these jobs from the synchronous upload path. Resilience is achieved through dual Web Servers behind the Load Balancer to eliminate single points of failure. Monitoring tracks storage utilization, sync lag, and upload error rates. Block-level deduplication across users saves significant storage — common files (OS libraries, popular documents) are stored only once.

Design a full-scale web search engine like Google. Crawl the web, build an inverted index, and return ranked results for any query within 200ms. Search is the ultimate read-heavy system — the ratio of queries to index updates can exceed 100,000:1, making cache design and index partitioning the dominant architectural concerns. The query path begins at the Client, which sends a search request through the Load Balancer to Web Servers. The Web Server parses the query, applies spell correction and synonym expansion, then fans out the query to multiple Search Index shards in parallel. Each shard scores matching documents using a combination of TF-IDF term relevance and PageRank authority signals, returning the top-K candidates. The Web Server merges results from all shards, applies personalization and freshness boosts, and returns the final ranked list. A Cache layer stores results for frequent and trending queries, absorbing the majority of read traffic since search queries follow a heavy-tailed Zipf distribution — the top 1% of queries account for over 30% of traffic. The indexing path runs offline and is equally important. Workers act as web crawlers, fetching pages from the internet, extracting text, and feeding raw documents into the indexing pipeline. The Message Queue buffers crawled pages and distributes them to Workers that tokenize content, compute term frequencies, and build inverted index segments. These segments are periodically merged and deployed to the Search Index serving tier. The crawl frontier — the priority queue of URLs to visit next — is managed with politeness policies to avoid overwhelming any single domain. Resilience matters because search availability directly impacts revenue. Dual Web Servers behind the Load Balancer provide failover. Monitoring tracks query latency percentiles (p50, p99), index freshness lag, and crawl throughput. The Message Queue decouples crawling from indexing, preventing crawler spikes from overwhelming the index build pipeline.

Design a photo sharing and social network platform like Instagram for 1B users. Users post photos/videos, follow others, explore trending content, and interact via likes/comments. Instagram-scale systems face a unique dual challenge: extremely write-heavy media ingestion (200M+ photos per day) combined with extremely read-heavy feed generation (each user’s home feed aggregates posts from hundreds of followed accounts). The upload path starts at the Client, which sends photos/videos through a CDN (which also serves as an upload accelerator via edge ingestion) to the Load Balancer and API Gateway for authentication and rate limiting. Web Servers validate the upload, generate a unique media ID, and write raw media to Blob Storage. A Message Queue dispatches processing jobs to Workers, which resize images into multiple resolutions (thumbnail, standard, full), apply filters, extract EXIF metadata, and run content moderation classifiers. Workers push processed media back to Blob Storage and update the CDN cache. Post metadata (caption, location, hashtags, timestamp) is written to a NoSQL Database optimized for high write throughput and denormalized timeline queries. The feed read path serves billions of feed requests per day. When a user opens the app, the Web Server fetches their home feed from Cache. For cache misses, it queries the NoSQL Database for recent posts from followed accounts, ranks them by engagement signals and recency, and assembles the feed. A Search Index powers the Explore tab — trending content discovery based on hashtags, location, and engagement velocity. The CDN delivers all media assets, achieving cache hit ratios above 95% for popular content. Resilience is paramount for a social platform where downtime directly impacts user engagement and advertiser trust. Dual Web Servers behind the Load Balancer eliminate application-tier single points of failure. Monitoring tracks feed latency, upload success rates, CDN hit ratios, and moderation queue depth. The Message Queue ensures media processing is decoupled from the upload response — users see instant upload confirmation while transcoding happens asynchronously.

Design a hotel booking system like Booking.com, handling 5000 reservations per second at peak, with strong consistency to prevent double-booking and supporting real-time inventory updates. Hotel reservation systems are one of the most challenging consistency problems in system design — unlike social media where eventual consistency is acceptable, a single room sold to two guests is a business-critical failure that erodes trust and incurs real financial costs. The read path dominates traffic: users browse hotel listings, compare prices, check availability, and read reviews. The Client sends requests through the Load Balancer to the API Gateway for authentication and request routing. Web Servers serve listing data from a Cache layer that holds hotel details, photos, amenities, and pre-computed availability windows. This cache is refreshed asynchronously — hotel listing metadata is read-heavy and tolerates slight staleness (a few seconds). The Database stores the authoritative room inventory, pricing rules, and reservation records with full ACID guarantees. The booking (write) path demands strong consistency. When a user submits a reservation, the Web Server initiates an optimistic locking transaction against the Database: it reads the room inventory row with its current version number, decrements availability, and commits only if the version has not changed since the read. If another booking raced and committed first, the transaction fails and the user is shown an ‘unavailable’ message. This prevents double-booking without pessimistic locks that would serialize all bookings. After a successful reservation, the Web Server calls the Payment Service to charge the guest. This follows the Saga pattern: reserve first, charge second, confirm third — with compensating transactions to release the room if payment fails. A Message Queue decouples post-booking work: confirmation emails, calendar sync, partner notifications, and analytics events are dispatched to Workers asynchronously. Resilience is achieved through dual Web Servers behind the Load Balancer, eliminating single points of failure. Monitoring tracks booking success rates, payment latency, cache hit ratios, and inventory drift between cache and database.

Design the core ride-sharing infrastructure that powers a platform like Uber, handling 100 million trips every single day across hundreds of cities worldwide. At the heart of this system lies real-time driver location tracking, where millions of drivers broadcast GPS pings every four to five seconds over persistent WebSocket connections. These location updates must flow through a high-throughput stream processing pipeline that ingests the raw GPS data, computes geospatial hashes using systems like Uber's H3 hexagonal indexing, and updates a low-latency cache so the matching engine can instantly query which drivers are in a rider's neighborhood. The rider-driver matching system itself is a fascinating optimization problem: when a rider requests a ride, the platform must search nearby H3 cells, rank available drivers by distance and estimated time of arrival, and dispatch the best match within five seconds. ETA calculation relies on historical trip data and real-time traffic conditions stored in a time-series database, enabling accurate predictions of travel time along specific road segments. Surge pricing adds another dimension of complexity. The system must continuously monitor supply and demand ratios across geographic zones, detecting when rider demand outstrips available driver supply in a given area. A stream processor aggregates these demand signals from the time-series database and adjusts pricing multipliers in near real-time, balancing marketplace economics to incentivize more drivers to enter high-demand zones. Trip management handles the full lifecycle from request through completion: the API gateway routes rider and driver requests to web servers that manage trip state in a NoSQL database optimized for the high-write, schema-flexible nature of trip records and driver profiles. The system splits traffic intelligently: REST APIs through the API gateway handle trip requests and account management, while WebSocket connections handle the continuous location streaming path. A load balancer distributes incoming REST traffic across multiple API gateway and web server instances, providing horizontal scalability and eliminating single points of failure in the request path.

Design a production-grade metrics and monitoring platform like Datadog that ingests 100 million data points per second from thousands of hosts across a globally distributed infrastructure. This system must handle one of the most extreme write-heavy workloads in all of computing: every server, container, and application in a customer's fleet emits metrics (CPU usage, memory, request latency, error rates) at one-second intervals, and your platform must reliably capture every single data point without loss. The ingestion path is the critical hot path. Metric agents running on customer hosts push data to an API gateway, which routes it to web servers that validate and normalize the incoming metrics before publishing them into a high-throughput message queue. This queue acts as a shock absorber, decoupling the variable ingestion rate from the downstream processing speed. A dedicated stream processor subscribes to the queue and performs real-time aggregation: computing per-host rollups, evaluating alert rules against streaming data, and writing the results to a purpose-built time-series database optimized for sequential writes using LSM-tree storage engines. The query path serves real-time dashboards that need sub-second response times. When a user opens a dashboard, the web server checks a cache layer for recently computed metrics. Cache hits return instantly, while misses query the time-series database directly. Workers handle the critical background task of downsampling: converting high-resolution one-second data into one-minute and one-hour rollups for long-term storage, dramatically reducing storage costs while preserving trend visibility. The cache layer uses TTL-based expiration aligned with rollup intervals, ensuring dashboard queries for recent time ranges return from memory in milliseconds rather than hitting the time-series database on disk. The platform must maintain 99.99% data durability, meaning even during partial system failures, no metric data can be permanently lost. The monitoring system itself needs monitoring: tracking consumer lag on the ingestion queue, stream processor throughput, and time-series database write latency to ensure the platform can observe itself.

Design a real-time ad click event aggregation system like Meta's click tracking infrastructure that processes over one million click events per second. Every time a user clicks an advertisement anywhere on the platform, that click event must be captured, deduplicated, attributed to the correct advertiser campaign, and aggregated into real-time metrics that power billing and performance dashboards. The system must guarantee exactly-once processing semantics because every missed or double-counted click directly impacts advertiser billing accuracy and platform revenue. The ingestion layer consists of web servers behind a load balancer that receive click beacons from client browsers and mobile apps, then immediately publish these events to a durable message queue partitioned by advertiser ID for ordered processing. A stream processor consumes from the queue and performs windowed aggregation: computing click counts, unique user counts, and conversion rates within tumbling one-minute windows. Late-arriving data from slow mobile networks is handled through watermarking, where the system waits a configurable period before closing each aggregation window. The stream processor outputs to three destinations: a time-series database for real-time dashboard queries supporting 'top-N ads by clicks in last M minutes' queries, a relational database for finalized billing records with ACID guarantees, and a dead letter queue for malformed or unparseable events that need manual review. The time-series database indexes click aggregates by campaign ID and time window, enabling advertisers to drill down into per-campaign performance metrics with sub-second analytical query response times. Workers perform batch reconciliation jobs, cross-referencing the streaming aggregates against the billing database to detect and correct any discrepancies. Click deduplication is critical: each click carries a unique impression ID, and the system uses a combination of Bloom filters and database lookups to reject duplicate submissions that occur when users double-click or when network retries replay the same beacon. The architecture must sustain this throughput continuously while maintaining strict correctness guarantees for financial reporting.

Design a payment processing system like Stripe that handles 1,000 transactions per second with absolute reliability, ACID guarantees, and PCI-DSS compliance. In financial systems, the consequences of failure are measured in dollars: a missed transaction means lost revenue, a duplicate charge erodes customer trust, and a security breach can end a company. The API gateway serves as the secure entry point, terminating TLS connections and enforcing rate limits to protect against abuse. Behind it, web servers handle payment intent creation, validation, and routing to the dedicated payment service. The payment service is the most critical component: it implements idempotency at every layer using client-provided idempotency keys stored in a short-TTL cache. When a duplicate request arrives (common during network retries), the system returns the original result instead of processing the payment twice. The payment service persists every transaction to a SQL database with full ACID guarantees, creating an immutable audit trail that satisfies regulatory requirements. Each transaction record includes the idempotency key, amount, currency, timestamp, and a state machine tracking the payment through its lifecycle: CREATED, AUTHORIZED, CAPTURED, SETTLED, or FAILED. After processing, the payment service publishes webhook events to a message queue for asynchronous delivery to merchant endpoints. Workers consume from this queue to deliver webhooks with exponential backoff retry logic. If a webhook consistently fails delivery after exhausting retries, the message moves to a dead letter queue for manual investigation, ensuring no payment notification is silently lost. Monitoring tracks critical payment metrics: transaction success rates, processing latency percentiles, fraud detection signals, and payment network response codes. The architecture must handle graceful degradation: if an external payment network is temporarily unavailable, circuit breakers prevent cascading failures while the message queue buffers pending transactions for later processing. A load balancer distributes incoming traffic across redundant web server instances, ensuring that no single server failure interrupts payment processing during peak transaction volumes.

Design your own distributed message queue from scratch, modeled after Apache Kafka, one of the most influential pieces of infrastructure in modern distributed systems. Your queue must support one million messages per second write throughput with persistent storage, log replay capability, consumer groups, and configurable delivery guarantees ranging from at-least-once to exactly-once. At its core, Kafka is an append-only commit log: producers write messages to the end of a partition log, and consumers read from any offset, enabling both real-time streaming and historical replay. The system uses a cluster of broker nodes (represented as workers) that own and replicate partitions across the cluster. A load balancer distributes producer and consumer connections across the broker fleet. Each broker appends incoming messages to on-disk log segments stored in a NoSQL database layer, achieving remarkable throughput through sequential I/O patterns and zero-copy data transfer from disk buffers directly to network sockets. ZooKeeper coordinates the broker cluster: tracking which brokers are alive, managing partition leadership elections, and maintaining the in-sync replica (ISR) set for each partition. When a broker fails, ZooKeeper triggers leader re-election, promoting a follower that has fully replicated data to become the new partition leader. A message is only considered committed once it has been replicated to a quorum of ISR followers, guaranteeing zero data loss even during broker crashes. Consumer offset tracking lives in a fast cache layer, enabling consumers to checkpoint their position in the log and resume from exactly where they left off after restarts. Monitoring is essential for operating a production Kafka cluster: tracking consumer lag (how far behind consumers are from the latest produced message), broker throughput, partition skew, disk utilization, and ISR shrinkage events that signal replication health degradation. A load balancer sits in front of the broker cluster to distribute producer and consumer connections evenly, preventing any single broker from becoming a hot spot under skewed partition access patterns.

Design a real-time trending topics system that analyzes millions of tweets per minute, detects spikes in hashtag usage, and surfaces the top-10 trending topics per geographic region within a five-minute sliding window. This is a classic instance of the heavy hitters problem in distributed streaming, where you must identify the most frequently occurring items in a massive, continuously arriving data stream without storing every individual event. When a user posts a tweet, the client sends it through an API gateway to web servers that extract hashtags and metadata, then publish the tweet event to a high-throughput message queue partitioned by geographic region. A fleet of stream processors consumes from the queue and performs the core trending algorithm: maintaining Count-Min Sketch data structures (a probabilistic structure using multiple hash functions and counter arrays) to estimate hashtag frequencies with sub-linear memory usage. Each processor handles a specific geographic partition, computing regional trends independently. The stream processor uses a sliding window aggregation strategy: a five-minute window that advances every ten seconds, ensuring the trending list stays fresh and responsive to viral content while smoothing out momentary noise. When the processor identifies a hashtag whose frequency exceeds a configurable threshold within its window, it writes the updated top-10 ranking to a cache layer keyed by region ID. The web server query path checks this cache first when users request trending topics, delivering sub-second response times since the heavy computation has already been performed by the stream processor. For historical trend analysis and debugging, processed results also flow to persistent storage. A monitoring component tracks consumer lag on each regional partition and stream processor throughput, alerting operators when trending computation falls behind the ingestion rate during viral traffic spikes. The system must handle burst scenarios like major sporting events or breaking news, where tweet volume can spike by 100x within seconds.

Design a real-time collaborative document editor like Google Docs where multiple users simultaneously edit the same document, with changes appearing within 100 milliseconds and all edits persisting reliably. The central challenge is conflict resolution: when two users type at the same position in a document at the same time, the system must deterministically resolve the conflict so every user converges on the same final document state. This requires implementing Operational Transformation (OT) or Conflict-free Replicated Data Types (CRDTs) on the server side. Users connect through a load balancer configured with sticky sessions to maintain their WebSocket connection to a specific server throughout their editing session. At least two WebSocket servers handle the real-time editing sessions, providing redundancy so that if one server fails, the load balancer reroutes users to the surviving server. When a user makes an edit, their WebSocket server receives the operation (insert, delete, or format change at a specific position), transforms it against any concurrent operations from other users, and broadcasts the transformed operation to all other connected editors. The critical cross-server coordination happens through a message queue: when User A edits on Server 1, the operation is published to the queue, and Server 2 (where User B is connected) consumes and applies it. This bidirectional message flow between WebSocket servers and the queue ensures all servers maintain a consistent document state. Every operation is persisted to a relational database that stores the document operation log, metadata, and access control lists. Periodically, the system creates full document snapshots and stores them in blob storage, enabling fast document loading (instead of replaying the entire operation history) and providing a revision history that users can browse and restore from. A cache layer stores active document metadata, including participant cursor positions and selection ranges, allowing the web servers to deliver real-time presence indicators without querying the database for each connected user.

Design a product catalog service for a major e-commerce platform with 100 million products, supporting fast full-text search, multi-attribute filtering, and category browsing, all under 100 milliseconds. The system must also survive Black Friday traffic spikes of 50x normal load without degradation. This is a read-heavy system that benefits enormously from the Command-Query Responsibility Segregation (CQRS) pattern: a SQL database serves as the authoritative source of truth for product data (prices, inventory counts, descriptions), while a dedicated search index powered by Elasticsearch handles all read queries with its inverted index optimized for full-text search and faceted filtering. The client interacts with two paths: static product images and category page assets are served through a CDN for instant loading with global edge caching, while dynamic API requests (search queries, filter operations, product detail lookups) flow through an API gateway to web servers. The web servers implement the query routing logic: first checking a cache layer for recently requested category pages and popular search results, then falling back to the search index for cache misses. The search index maintains a denormalized view of the product catalog, with documents structured for efficient querying by category, price range, brand, rating, and arbitrary product attributes. Product updates flow from the database to the search index asynchronously through a change data capture pipeline, ensuring the read path never blocks on write consistency while keeping the search index eventually consistent within seconds. Workers run periodic reindexing jobs that rebuild search index shards and handle bulk price updates during flash sales, ensuring catalog consistency even under heavy write bursts. Cache warming strategies are critical for Black Friday preparedness: before the event, the system pre-populates caches with predicted high-traffic category pages and deal pages. The architecture cleanly separates the write path (inventory updates, price changes) from the read path (search, browse, filter), allowing each to scale independently.

Design a distributed caching system like Memcached or Redis Cluster that partitions data across multiple cache nodes using consistent hashing, handles node failures gracefully with automatic failover, and supports 10 million operations per second with sub-millisecond p99 latency. Unlike a single-node cache, a distributed cache introduces the fundamental challenge of data partitioning: deciding which node stores which key. Consistent hashing with virtual nodes solves this elegantly by mapping both keys and nodes onto a hash ring, where each key is assigned to the next clockwise node. Virtual nodes (typically 100-200 per physical node) ensure even data distribution and minimize data movement when nodes join or leave the cluster. Clients connect through a load balancer to web servers that implement the cache routing logic. Each web server maintains a local view of the hash ring and routes GET/SET/DELETE operations to the appropriate cache node. The system requires at least three cache nodes to form a meaningful hash ring with sufficient distribution and fault tolerance. When a cache node fails, its portion of the ring is automatically redistributed to the next clockwise node, and the system continues serving requests with only a brief period of cache misses for the affected key range. ZooKeeper serves as the cluster membership registry where cache nodes register their presence through ephemeral nodes and heartbeats. When ZooKeeper detects a node failure (missed heartbeats), it notifies all web servers to recompute their local hash ring, enabling automatic failover without manual intervention. Monitoring tracks the metrics critical to cache health: hit rate (the percentage of requests served from cache versus origin), eviction rate (indicating memory pressure), hot key detection (keys receiving disproportionate traffic that may need special handling), and per-node load distribution to detect hash ring skew. Deploying multiple web server instances behind the load balancer ensures that no single routing node becomes a bottleneck, and the consistent hashing algorithm remains effective even as the cluster scales horizontally.

Design a food delivery platform like DoorDash that orchestrates the complex three-sided marketplace between customers, restaurants, and delivery drivers, handling 50,000 concurrent active orders at any given time. This system manages the entire order lifecycle through a distributed saga pattern: when a customer places an order, the system must validate the menu items, confirm restaurant acceptance, match an available driver, track the driver from restaurant to doorstep, and handle failures at any step with compensating transactions. The client communicates with two separate backends serving distinct purposes. REST API traffic flows through an API gateway to web servers that handle order placement, menu browsing, payment processing, and account management. The web servers persist order data, restaurant menus, and payment records in a relational database with ACID guarantees, ensuring that financial transactions and order state are always consistent. When an order is placed, the web server publishes an order event to a message queue, initiating the asynchronous dispatch workflow. Worker processes consume from the queue to run the driver matching engine: querying a cache that stores driver geolocation data (indexed using Redis GEO commands like GEOADD and GEORADIUS) to find the nearest available driver within a 5-kilometer radius. The matching algorithm considers driver proximity, current workload, and historical delivery performance. Simultaneously, the client maintains a persistent WebSocket connection for real-time updates. When a driver accepts an order and begins driving, their mobile app streams GPS location pings that are stored in the cache, and the WebSocket server reads from this cache to push live location updates and ETA recalculations to the customer's app. This dual-path architecture cleanly separates the transactional order management (REST + database) from the real-time tracking experience (WebSocket + cache), allowing each path to scale independently. A load balancer distributes API traffic across redundant web server instances, ensuring the order management path remains available even during traffic spikes from promotional campaigns or severe weather events that drive ordering surges.

Design a stock exchange matching engine that processes buy and sell orders in strict price-time priority, handling one million orders per second with deterministic sub-millisecond matching latency and absolutely zero data loss. This is the most latency-sensitive system in computing: every microsecond of delay can mean millions of dollars in missed trading opportunities. The order flow begins when traders submit limit or market orders through an API gateway, which routes them to web servers acting as the order validation service. The web servers validate order parameters (price, quantity, instrument, account balance), perform risk checks, and write each validated order to a sequenced message queue that serves as the system's journal. This journal is the backbone of the exchange: by recording every order before processing, the system can recover from any failure by replaying the journal from the last checkpoint. The stream processor acts as the matching engine core, consuming orders from the journal in strict sequence and maintaining the order book data structure in memory. The order book is organized by price level, with each level containing a FIFO queue of orders at that price. When a new buy order's price meets or exceeds the lowest sell price (or vice versa), a trade is executed: the matching engine deducts quantities, generates trade confirmations, and updates the order book. The stream processor writes matched trade results to two destinations: a cache layer that maintains the real-time order book depth visible to traders on their terminals, and a database that stores the permanent trade history for settlement, regulatory reporting, and audit compliance. Web servers also read from the cache to serve order book snapshots to connected traders. Monitoring tracks the metrics most critical to exchange operations: matching engine latency percentiles, message queue depth, order-to-trade ratios, and system throughput to ensure the exchange meets its SLA obligations to market participants.

Design a music streaming service like Spotify serving 500 million users worldwide, supporting on-demand playback with adaptive bitrate streaming, personalized playlist generation, offline downloads, and a social activity feed. The audio delivery architecture is built around a two-tier content distribution strategy that exploits the extreme power-law distribution of music consumption: roughly 1% of tracks generate over 80% of all plays. The client connects to a CDN for audio chunk delivery, and the CDN pulls tracks from blob storage on cache miss. Popular songs remain cached at CDN edge nodes close to users, delivering sub-second playback start times, while long-tail tracks stream from the origin blob storage with slightly higher latency. Audio files are pre-encoded at multiple bitrates (96kbps, 160kbps, 320kbps) using codecs like AAC or OGG Vorbis, and the client dynamically switches between bitrates based on current network bandwidth, similar to adaptive bitrate streaming in video but optimized for audio's lower bandwidth requirements. The API path handles everything beyond audio streaming: playlist CRUD operations, search queries, user profiles, social features, and the recommendation engine. Requests flow from the client through an API gateway to web servers that read and write user data, playlists, and track metadata in a relational database. A cache layer stores user sessions, recently played tracks, and pre-computed playlist data for fast retrieval. The recommendation engine runs as batch workers that periodically process the user-track interaction matrix using collaborative filtering algorithms ('users who liked X also liked Y'). The web server publishes listening events to a message queue, and workers consume these events to update the recommendation model. Processed recommendations are written back to the cache for instant retrieval when users open their Discover Weekly or Daily Mix playlists. A NoSQL database stores the social activity feed, capturing listening events, playlist follows, and friend activity in a denormalized timeline optimized for fast fan-out reads across each user's social graph.

Design a distributed lock manager that provides mutual exclusion guarantees across microservices, enabling safe coordination of shared resources in a distributed environment. When multiple service instances need to modify the same resource (a database row, a file, an external API with rate limits), they must acquire a distributed lock first to prevent race conditions and data corruption. The system implements the Redlock algorithm: to acquire a lock, a client must successfully set a key with NX (set-if-not-exists) and PX (auto-expire TTL) flags on a majority of independent Redis-like cache nodes within a bounded timeout. With three cache nodes, the client must succeed on at least two to consider the lock acquired. TTL-based auto-release is essential for safety: if a client crashes while holding a lock, the TTL ensures the lock automatically expires rather than being held forever, preventing deadlocks across the system. Each lock grant includes a monotonically increasing fencing token: a number that the lock service increments with every acquisition. When the lock holder writes to a shared resource, it passes the fencing token, and the resource layer rejects writes with stale (lower) tokens. This prevents a subtle but dangerous scenario where a client acquires a lock, experiences a long garbage collection pause, and then tries to use an expired lock. Clients connect through a load balancer to stateless lock service workers (at least two for redundancy) that implement the Redlock acquisition and release protocol. ZooKeeper provides an alternative locking mechanism for long-lived session locks using ephemeral nodes: a client creates an ephemeral znode to represent the lock, and if the client's session dies (heartbeat timeout), ZooKeeper automatically deletes the node, releasing the lock. Monitoring tracks lock contention metrics, acquisition latency, TTL expirations, and deadlock detection patterns to maintain system health. The system must remain available even when individual cache nodes fail: because the Redlock algorithm requires only a majority quorum, one cache node can be completely offline while locks continue to be acquired and released safely by the remaining nodes.

Design Slack's messaging infrastructure supporting channels, threaded conversations, direct messages, file sharing, and real-time presence indicators for 10 million concurrent users with full message search across all history. The core challenge is maintaining real-time bidirectional communication at massive scale while persisting every message durably and making it searchable. Each workspace operates as an isolated tenant with its own message history, but the infrastructure must efficiently multiplex millions of WebSocket connections across a shared pool of servers. Channels and threads use a fan-out-on-write model: when a user posts a message, it is published to a Message Queue, which distributes it to all WebSocket Servers holding connections for members of that channel. Presence tracking (online, away, DND) requires lightweight heartbeats stored in a Cache layer with TTL-based expiration. Unread counts are also maintained in Cache, incremented on each new message and reset when the user opens the channel. Message persistence uses a NoSQL Database sharded by workspace ID, enabling horizontal scaling while keeping workspace queries local. File attachments are stored in Blob Storage with metadata references in the message document. Full-text search across all messages requires a dedicated Search Index that is asynchronously updated as messages are persisted. The Load Balancer distributes incoming WebSocket upgrade requests using consistent hashing on user ID to ensure session affinity. Multiple WebSocket Servers are required for both capacity and redundancy. The architecture separates the real-time path (WebSocket Servers handling live connections) from the API path (Web Servers handling REST requests for search, file uploads, and channel management). This separation allows independent scaling of read-heavy API traffic and write-heavy real-time messaging. Monitoring provides visibility into connection counts, message throughput, queue depths, and search index lag across all components. The system handles both ephemeral presence data and durable message history, requiring different storage strategies for each workload type.

Design the recommendation engine that powers Netflix's 'Because You Watched' rows, processing viewing history of 200 million users to compute personalized top-50 recommendations using a hybrid of collaborative filtering and content-based signals, with A/B test ranking and updates within hours of new viewing activity. The system operates in two distinct modes: a batch pipeline that recomputes recommendation models every few hours, and a real-time serving layer that delivers pre-computed results to users with sub-100ms latency. The API Gateway receives recommendation requests and routes them to Web Servers, which first check the Cache for pre-computed recommendations. On a cache miss, the Web Server reads from NoSQL Database where the latest batch results are stored per user. The batch pipeline begins when Web Servers publish viewing events to a Message Queue. Workers consume these events and run the recommendation algorithms: collaborative filtering identifies users with similar viewing patterns and recommends what similar users watched, while content-based filtering uses metadata (genre, director, actors) to find similar titles. The Worker processes merge these signals using a weighted ensemble model, score each candidate title, and write the ranked top-50 list to NoSQL Database keyed by user ID. Workers also update the Cache with fresh results for active users, ensuring that the next request serves updated recommendations without a database round-trip. A/B test bucketing is handled at the API Gateway level using consistent hashing on user ID to deterministically assign users to experiment groups. Each group may use different ranking weights, enabling continuous experimentation with recommendation quality. The Load Balancer distributes API traffic across multiple redundant Web Servers, ensuring high availability during peak streaming hours. The architecture deliberately separates the computationally expensive batch training path from the latency-sensitive serving path, allowing the recommendation models to be retrained without impacting user experience. Feature stores in NoSQL Database hold pre-computed user and item embeddings that Workers access during batch computation.

Design an object storage system like Amazon S3 from scratch, supporting PUT and GET of objects up to 5TB in size with 99.999999999 percent (eleven nines) durability, 99.99 percent availability, object versioning, cross-region replication, and multi-part uploads for large files. The architecture separates the Control Plane (metadata) from the Data Plane (blob storage) to enable independent scaling. The API Gateway authenticates requests using signature-based authentication (similar to AWS Signature V4) and routes them to Web Servers. Each Web Server handles PUT, GET, DELETE, and LIST operations. For PUT requests, the Web Server splits large objects into fixed-size chunks (e.g., 64MB), computes erasure coding parity blocks using Reed-Solomon encoding to achieve durability without full replication overhead, and distributes chunks across multiple Blob Storage nodes. Object metadata including bucket name, object key, version ID, chunk locations, and ACLs is stored in a strongly consistent Database. The Database enforces unique constraints on (bucket, key, version) tuples and supports conditional writes for concurrent upload protection. Blob Storage nodes manage the physical storage of data chunks on local disks. Each Blob Storage node periodically reports its health, disk usage, and chunk inventory to Zookeeper, which maintains the cluster membership and coordinates leader election for consistency. GET requests first look up chunk locations in the Database, then retrieve chunks from Blob Storage nodes in parallel and reassemble them into the original object. Multi-part uploads allow clients to upload chunks independently and complete the upload with a finalization request that assembles the manifest. Versioning is implemented by appending a version ID to each object write; DELETE operations insert a delete marker rather than physically removing data. Monitoring tracks storage utilization, replication lag, chunk integrity verification results, and request latencies across all nodes. Lifecycle rules (transition to cold storage, expiration) are evaluated by background processes that scan metadata and issue bulk data movements.

Design a ticket booking system for concerts and events capable of handling 100,000 users competing for 50,000 seats when high-demand events like Taylor Swift concerts go on sale, with zero overselling, fairness guarantees through a virtual waiting queue, and reliable payment processing. The system faces the thundering herd problem: tens of thousands of users simultaneously hitting the purchase endpoint at the exact moment tickets become available. A CDN serves the event listing pages, venue maps, and static assets to reduce load on the backend during traffic spikes. The Client connects to both the CDN for static content and the Load Balancer for transactional requests. The Load Balancer distributes traffic across multiple Web Servers using round-robin with health checks. Each Web Server implements the booking flow as a multi-step transaction: first, it checks seat availability in the Cache (which holds a real-time inventory count), then acquires a distributed lock on the selected seats in the Database using SELECT FOR UPDATE or an advisory lock to prevent double-booking, reserves the seats with a 5-minute TTL, initiates payment through the Payment Service, and upon payment confirmation commits the booking to the Database and releases the lock. If payment fails or times out, the reservation expires and seats return to the available pool. The Cache layer stores seat availability maps, event metadata, and session state for the virtual queue. The virtual queue assigns each user a position based on arrival time and progressively admits users to the purchase flow, preventing the system from being overwhelmed. Monitoring tracks queue depth, booking completion rates, payment success rates, seat inventory drift between Cache and Database, and identifies potential overselling scenarios. The architecture ensures strong consistency for seat reservations while using eventual consistency for non-critical paths like event browsing and queue position updates. The system gracefully degrades under extreme load by expanding the virtual queue capacity while maintaining booking integrity.

Design a code hosting and collaboration platform like GitHub supporting git push and pull over HTTPS and SSH, pull request workflows with inline code review, CI/CD webhook triggers, and serving repositories to millions of developers worldwide. The platform manages 100 million repositories with atomic reference updates and sub-500ms clone initiation times. The Load Balancer distributes incoming traffic across multiple Web Servers that handle both the REST API (repository browsing, pull request management, user profiles) and the git smart HTTP protocol (clone, fetch, push). Each git push triggers a sequence of operations: the Web Server receives the packfile, validates the pushed references against the current state in the Database (ensuring no force-push conflicts without explicit permission), stores the pack objects in Blob Storage using content-addressable paths (SHA-1 hash of each object), updates the reference pointers in the Database, and publishes a push event to the Message Queue. Workers consume push events to trigger downstream actions: running CI/CD webhooks, updating pull request merge status, computing diff statistics, and sending notification emails. Failed webhook deliveries are routed to the Dead Letter Queue for retry with exponential backoff, ensuring reliable delivery even when downstream CI systems are temporarily unavailable. The Database stores repository metadata, user accounts, pull request state, review comments, and git references. Blob Storage holds the actual git objects (blobs, trees, commits) using content-addressable storage (CAS) which naturally deduplicates identical file content across repositories (forks share objects). Monitoring tracks push throughput, clone latency percentiles, webhook delivery success rates, queue depths, and storage utilization. The architecture separates synchronous user-facing operations (clone, browse, review) from asynchronous background processing (webhook delivery, CI triggers, notification dispatch), enabling the system to maintain responsiveness during traffic spikes while reliably processing millions of webhook deliveries per day. Repository forks share storage through content-addressable objects, dramatically reducing overall storage costs.

Design a platform for ingesting telemetry from 10 million IoT devices (temperature, humidity, GPS coordinates) where each device sends a reading every 30 seconds, producing 300,000 readings per second sustained throughput. Store the data with 5-year retention, detect anomalies in real-time, and serve time-range dashboard queries with sub-500ms latency. The architecture follows an event-driven streaming pattern where devices publish telemetry readings to the API Gateway, which validates device authentication tokens and normalizes the message format before forwarding to the Message Queue. The Message Queue (acting as a Kafka-like durable log) decouples ingestion from processing and absorbs traffic spikes when large fleets of devices reconnect simultaneously after network partitions. Stream Processors consume from the Message Queue in parallel, performing three critical functions: writing raw readings to the Time Series Database for long-term storage and dashboard queries, archiving compressed batches to Blob Storage for cost-effective cold storage beyond the retention window, and running anomaly detection algorithms (z-score, moving average deviation) on sliding windows of incoming data. When an anomaly is detected (e.g., temperature exceeding 3 standard deviations from the historical mean), the Stream Processor emits an alert event. Two Stream Processor instances provide redundancy and parallel processing throughput. The Time Series Database stores readings indexed by device ID and timestamp, supporting efficient range queries (give me all readings from device X between time T1 and T2) and downsampling for long-term aggregation. Blob Storage holds raw data archives organized by date partitions for compliance and batch analytics. The API Gateway also serves as the entry point for dashboard API requests, connecting to Monitoring for operational visibility into ingestion rates, processing lag, anomaly detection accuracy, and device connectivity health across the entire fleet. The platform supports configurable alerting rules per device type and geographic region, enabling operators to focus on actionable anomalies rather than noise.

Design the social graph service powering Facebook's friend connections for 2 billion users with an average of 338 friends each, producing a graph with over 600 billion edges. Support friend-of-friend queries, mutual friend computation, and People You May Know (PYMK) suggestions using 2-hop BFS traversal, all within strict latency requirements of 50ms for mutual friends and 200ms for PYMK. The API Gateway handles client authentication and request routing to Web Servers. Each Web Server implements three core endpoints: add/remove friend connections (write path), fetch mutual friends between two users (read path with graph intersection), and generate friend suggestions (computationally intensive read path). The Graph Database stores the social graph using an adjacency list model, partitioned by user ID hash to distribute the massive dataset across multiple shards. Each shard handles a subset of users and their outgoing edges. Mutual friend computation requires fetching the friend lists of two users and computing their intersection. For users with hundreds of friends, this operation is optimized using sorted friend lists and merge-intersection. The Cache layer stores frequently accessed friend lists, mutual friend results, and PYMK suggestions. Cache invalidation happens asynchronously: when a friend connection changes, the Web Server publishes an event to the Message Queue, and Workers consume these events to invalidate affected cache entries and recompute PYMK suggestions for impacted users. The PYMK algorithm performs a 2-hop BFS from the target user: first collecting all friends, then collecting all friends-of-friends, filtering out existing friends, and ranking candidates by mutual friend count. Workers handle this computationally expensive traversal asynchronously and cache the results. The Load Balancer distributes read traffic across multiple Web Servers for high availability. Monitoring tracks query latencies, graph traversal depth, cache hit rates, connection change throughput, and shard balance across the Graph Database cluster. The architecture handles the asymmetry between rare write operations and frequent read queries by caching aggressively.

Design a feature flag and configuration management service supporting instant flag evaluation for 1 billion daily requests with sub-2ms evaluation latency, gradual rollouts from 1 percent to 10 percent to 50 percent to 100 percent, A/B experiment bucketing with deterministic assignment, and kill switches for instant feature disablement across all servers without deployment. The architecture prioritizes ultra-low latency evaluation since every API request in the client application depends on feature flag decisions. The Client connects to the Load Balancer, which distributes traffic across multiple Web Servers. Each Web Server handles two types of requests: flag evaluation (given a user ID and flag key, return the variant) and flag management (create, update, delete flags and their targeting rules). Flag definitions and targeting rules are stored in the Database, which serves as the source of truth. Each flag includes metadata such as name, description, default value, percentage rollout configuration, user segment targeting rules, and kill switch status. The Cache layer is critical for performance: all active flag definitions are loaded into Cache at startup and kept synchronized via polling or pub/sub notifications. When a Web Server evaluates a flag, it reads the flag definition from Cache (sub-millisecond), applies targeting rules (user segment match, percentage rollout using consistent hashing on user ID), and returns the result without touching the Database. Gradual rollouts use consistent hashing: the user ID is hashed to a value between 0 and 100, and if the hash falls below the rollout percentage, the user gets the new variant. This ensures deterministic, sticky assignment without storing per-user state. Kill switches immediately update the Cache to override all targeting rules and return the safe default value. Monitoring tracks evaluation latency percentiles, flag change propagation delay from Database to Cache, experiment assignment distributions, and error rates. Two Web Servers provide redundancy and distribute the evaluation load across the fleet.

Design a navigation system like Google Maps that serves map tiles for rendering, computes shortest routes using graph algorithms like A* and Dijkstra with Contraction Hierarchies optimization, provides real-time traffic overlays from live GPS data, and handles turn-by-turn navigation with dynamic ETA updates. The system must deliver route computation in under 2 seconds and map tile serving in under 100ms. The architecture has two distinct data flows: tile serving and route computation. For tile serving, the Client requests map tiles from the CDN, which serves cached tiles for popular zoom levels and regions. On a cache miss, the CDN fetches from Blob Storage where pre-rendered tile images are stored in a tile pyramid structure (zoom level / x / y coordinates). This path serves the majority of requests with sub-50ms latency. For route computation and dynamic queries, the Client connects through the API Gateway to Web Servers. The Web Server reads the road network graph from NoSQL Database (partitioned geographically by region), applies Contraction Hierarchies for fast shortest-path computation, considers real-time traffic weights, and returns the route. The Cache stores frequently computed routes (e.g., popular commute paths) and traffic-weighted edge costs. Real-time traffic processing uses a streaming pipeline: drivers' GPS pings are published to the Message Queue, consumed by the Stream Processor which computes road segment speeds using moving averages over 5-minute windows, and updates the Cache with current traffic weights. The Stream Processor also detects incidents (sudden speed drops) and triggers re-routing for active navigation sessions. The Load Balancer distributes API traffic across multiple Web Servers. Monitoring tracks tile cache hit rates, route computation latency distributions, traffic data freshness, Stream Processor throughput, and GPS data ingestion rates. The architecture separates the static tile serving path (CDN to Blob Storage) from the dynamic route computation path (API Gateway to Web Server) to optimize each independently.

Design an email service handling 500 million users that supports SMTP send and receive, full-text email search, spam filtering, attachment storage, and push notifications for new mail delivery, with 99.99 percent uptime and sub-3-second email delivery. The architecture separates the synchronous user-facing API from the asynchronous email processing pipeline. The Client connects through the Load Balancer to Web Servers that handle the user-facing API: composing and sending emails, searching the inbox, reading messages, and managing folders. When a user sends an email, the Web Server validates the message, stores attachments, and publishes a send event to the Message Queue. Workers consume send events and handle the SMTP delivery pipeline: DNS MX record lookup for the recipient domain, TLS connection establishment, SMTP handshake, and message transmission. If delivery fails, the Worker retries with exponential backoff. For incoming mail, external SMTP servers connect to the platform's MX endpoints, and incoming messages are queued in the Message Queue for processing. Workers process incoming mail through a multi-stage pipeline: SPF/DKIM/DMARC authentication, spam scoring using content analysis and sender reputation, virus scanning of attachments, and finally storage. Email bodies and metadata are stored in NoSQL Database sharded by user ID, while large attachments are stored in Blob Storage with references in the message document. The Search Index is populated asynchronously as messages are stored, enabling full-text search across subject lines, bodies, and attachment names. Workers also trigger the Notification Service to send push notifications to the recipient's mobile devices and desktop clients. The Web Server queries the Search Index directly for inbox search operations. Multiple Web Servers behind the Load Balancer provide redundancy and distribute the API load. The architecture handles the asymmetry between send operations (relatively rare, computationally expensive) and read operations (very frequent, latency-sensitive) by separating them into different processing paths with independent scaling characteristics.

Design a proximity and nearby search service like Yelp or Google Places that returns businesses within a given radius, supporting 'restaurants near me' queries with filtering by category, rating, price range, and distance for a dataset of 200 million places worldwide. Queries must complete in under 100ms using geospatial indexing techniques. The API Gateway handles authentication, rate limiting, and request routing to Web Servers. Each Web Server processes proximity queries by first determining the user's location (latitude and longitude from the request), computing the geohash prefix for the target area, and querying the Search Index which stores business listings indexed by geohash, category, and rating. Geohashing converts 2D coordinates into a 1D string prefix, enabling efficient range queries: all businesses sharing the same geohash prefix are geographically nearby. For radius searches, the Web Server queries the geohash cell containing the user plus all adjacent cells (9-cell grid) to handle edge cases near cell boundaries. Results are filtered by the exact Haversine distance, category, minimum rating, and price range, then sorted by relevance (a weighted combination of distance, rating, and review count). The Cache stores popular query results keyed by (geohash prefix, category, radius) to serve repeated queries for the same area without hitting the Search Index. Popular areas like city centers have extremely high cache hit rates, dramatically reducing Search Index load. The Database stores the authoritative business data: name, address, coordinates, hours, photos, reviews, and owner information. Updates to business data (new reviews, hour changes) are written to the Database and asynchronously propagated to the Search Index and Cache. Monitoring tracks query latency percentiles, cache hit ratios, Search Index query throughput, and geohash distribution to ensure balanced load. Two Web Servers provide redundancy for the API layer while the Search Index handles the computationally intensive geospatial query workload. The design balances read-heavy geospatial lookups against write-heavy review and rating updates.

Design a content delivery network from scratch, placing edge Points of Presence (PoPs) worldwide, routing users to the nearest PoP via anycast DNS, caching content with a tiered architecture (L1 edge to L2 regional to origin), and supporting cache purge propagation within 30 seconds globally. The CDN must achieve sub-50ms time-to-first-byte from edge and 99.99 percent availability. The Client initiates content requests by first querying DNS, which uses anycast routing to direct the client to the nearest CDN edge node. DNS resolution considers geographic proximity, network latency measurements, and PoP health status. Multiple CDN nodes (edge PoPs) are deployed globally; when a request arrives at a CDN node, it checks its local Cache for the requested content. On a cache hit, the content is served immediately with minimal latency. On a cache miss, the CDN node fetches from the origin Blob Storage (or a regional cache tier in between), caches the response locally, and serves it to the client. The tiered caching architecture reduces origin load: popular content is cached at the edge (L1), moderately popular content at regional hubs (L2), and the origin Blob Storage only handles initial fetches and rare content. Cache purge is critical for content updates: when an origin content change occurs, a purge event is published to the Message Queue, and all CDN nodes subscribe to purge notifications. Each CDN node evicts the invalidated cache keys upon receiving the purge message, ensuring consistency within 30 seconds globally. The Cache layer implements content-aware caching policies: static assets (images, CSS, JS) get long TTLs, while dynamic content (API responses) gets short TTLs or no-cache headers. Request coalescing prevents cache stampedes: when many concurrent requests arrive for the same uncached URL, only one request goes to the origin while others wait for the result. Monitoring tracks cache hit ratios per PoP, origin offload percentage, purge propagation latency, bandwidth utilization, and error rates across all edge nodes.

Design a real-time leaderboard for an online game with 50 million players, showing global top-100 rankings, per-friend leaderboards, and each player's exact rank and percentile. Scores update in real-time as games complete, with rank queries completing in under 50ms and the system handling 10,000 score updates per second. The architecture uses a Cache-centric design where the primary ranking data structure is a Redis Sorted Set (or equivalent) that maintains scores in sorted order with O(log N) insertion and O(log N) rank lookup. The Client connects through the Load Balancer to multiple Web Servers. Each Web Server handles three types of requests: score submission (after a game ends, submit the player's new score), rank query (get a player's current rank and percentile), and leaderboard fetch (get the top-100 or a specific rank range). For score submissions, the Web Server writes the updated score to both the Cache (for real-time ranking) and the Database (for persistence and historical analytics). The Cache sorted set allows instant rank computation: ZREVRANK returns a player's position, ZREVRANGE returns the top-N players, and ZCOUNT enables percentile calculation. The Database stores the authoritative score history, player profiles, and game metadata. It serves as the recovery source if the Cache needs to be rebuilt. Friend leaderboards are computed by fetching the friend list from the Database and looking up each friend's score and rank from the Cache. For the global leaderboard of 50M players, sharding across multiple Cache instances is necessary: players are distributed by score range, and the Web Server merges results from relevant shards. Monitoring tracks score update throughput, rank query latency, Cache memory utilization, and Database replication lag. Two Web Servers behind the Load Balancer ensure high availability and distribute the query load evenly. The design prioritizes read performance since rank queries vastly outnumber score updates.

Design a distributed task queue system like Celery that processes millions of background jobs, supporting task priorities, retries with exponential backoff, task routing by type, rate limiting per queue, and persistent result storage. The system must handle 100,000 tasks per minute with at-least-once execution guarantees and task deduplication. The Client submits tasks through the Load Balancer to Web Servers, which validate task payloads, assign unique task IDs, and publish task messages to the Message Queue with priority metadata. The Message Queue acts as the central task broker, maintaining separate priority queues that ensure high-priority tasks are consumed before lower-priority ones. Multiple Workers consume tasks from the Message Queue using a competing consumer pattern, where each Worker pulls the next available highest-priority task. Workers execute the task logic (sending emails, generating reports, processing images, running ML inference) and store results in the Cache for fast retrieval by the submitting service. Upon task completion, the Worker acknowledges the message to the Message Queue, removing it from the pending queue. For failed tasks, Workers implement retry logic with exponential backoff: the task is re-queued with an increasing delay (1s, 2s, 4s, 8s, up to a configurable maximum). After exhausting all retry attempts, failed tasks are routed to the Dead Letter Queue for manual inspection and potential reprocessing, preventing poison messages from blocking the main queue. Task deduplication uses the unique task ID stored in Cache: before executing, a Worker checks if the task ID has already been processed, preventing duplicate execution in at-least-once delivery scenarios. Rate limiting is enforced per queue using a token bucket algorithm, preventing task bursts from overwhelming downstream services. Monitoring tracks task throughput, queue depths, Worker utilization, retry rates, DLQ accumulation, and per-task-type latency distributions. Two Web Servers and two Workers provide redundancy across both the submission and execution layers.

Design a video conferencing system like Zoom supporting 1000-person meetings with real-time video and audio, adaptive bitrate streaming, screen sharing, cloud recording, and the architectural transition from peer-to-peer for small calls (2-4 participants) to SFU (Selective Forwarding Unit) for larger meetings. The system must achieve end-to-end latency below 150ms for interactive conversation quality. The Client connects through the Load Balancer to WebSocket Servers that manage the signaling layer: room creation, participant join/leave, media negotiation (SDP offer/answer exchange), and ICE candidate relay for NAT traversal. Multiple WebSocket Servers handle the persistent signaling connections, and the Load Balancer distributes new connections across them using consistent hashing on room ID to keep all participants of a meeting on the same server when possible. For media transport, the SFU architecture receives each participant's video and audio streams and selectively forwards them to other participants based on their display layout and bandwidth capacity. This avoids the N-squared scaling problem of peer-to-peer and the CPU-intensive transcoding of MCU architectures. Web Servers handle the REST API for meeting scheduling, user management, recording retrieval, and billing. When a participant requests recording, the WebSocket Server publishes a recording event to the Message Queue. Workers consume these events, receive the media streams, mux audio and video tracks into a single file, and upload the recording to Blob Storage. The Database stores meeting metadata, participant lists, recording URLs, and user profiles. Adaptive bitrate is managed at the SFU layer: each sender transmits multiple quality layers (simulcast), and the SFU selects the appropriate layer for each receiver based on their available bandwidth and display resolution. Monitoring tracks call quality metrics (jitter, packet loss, latency), participant counts per server, recording processing times, and overall system capacity utilization. Simulcast encoding and SFU-based selective forwarding eliminate the need for server-side transcoding while adapting to diverse client network conditions and device capabilities.

Design a distributed rate limiter for a public API platform serving 10,000 tenants with per-tenant, per-endpoint, and global rate limits, handling 1 million requests per second with consistent enforcement across multiple data centers and sub-1ms overhead per check. The architecture uses a combination of local and global counters to achieve both low latency and cross-datacenter consistency. The Client sends API requests through the API Gateway, which forwards each request to the Rate Limiter before allowing it to proceed to the Web Server. The Rate Limiter implements a sliding window log algorithm: for each (tenant, endpoint) pair, it maintains a sorted set of request timestamps in the Cache. When a new request arrives, the Rate Limiter removes expired entries outside the current window, counts remaining entries, and compares against the configured limit. If under the limit, the request timestamp is added and the request proceeds; otherwise, a 429 Too Many Requests response is returned with Retry-After headers. The Cache provides sub-millisecond read and write performance essential for the rate limiter's position in the critical request path. For multi-datacenter consistency, each Rate Limiter instance maintains a local counter and periodically synchronizes with a global counter in the Database. The synchronization uses an additive approach: each datacenter reports its local increments, and the Database aggregates them. This allows slight over-admission (a small percentage above the limit) in exchange for avoiding cross-datacenter round-trips on every request. Rate limit configurations (per-tenant quotas, per-endpoint limits, burst allowances) are stored in the Database and cached locally with short TTLs for fast access. Web Servers handle the actual API logic after rate limiting approval. Monitoring tracks request rates per tenant, throttle rates, cache latency, and synchronization lag between local and global counters. Two Web Servers provide redundancy for the API processing layer. The design trades slight over-admission for dramatically lower latency compared to strongly consistent global counters.

Design a real-time auction platform supporting 100,000 concurrent auctions with strict bid ordering, last-second bid extensions (anti-sniping protection), automatic outbid notifications, and deterministic winner determination. The system must confirm bids within 200ms and handle the intense write amplification during auction closing moments. The Client connects through the Load Balancer which distributes traffic to both Web Servers (for bid placement and auction management) and WebSocket Servers (for real-time bid stream updates). When a user places a bid, the Web Server validates the bid amount (must exceed current highest bid plus minimum increment), acquires an optimistic lock on the auction row in the Database, verifies no concurrent bid has been placed, writes the new bid record, updates the current highest bid, and releases the lock. The Cache stores the current highest bid and bid count per auction for fast read access without hitting the Database on every page load. After a successful bid, the Web Server publishes a bid event to the Message Queue. The Message Queue fans out bid events to two consumers: the Notification Service sends outbid alerts to the previous highest bidder via push notification and email, and the WebSocket Server broadcasts the new bid to all users watching the auction. Anti-sniping protection works by detecting bids placed in the final seconds of an auction and automatically extending the closing time by a configurable duration (e.g., 2 minutes), giving other bidders a fair chance to respond. The Database stores auction metadata (title, description, starting price, end time, seller ID), bid history (bidder, amount, timestamp), and winner determination logic. Winner determination is triggered by a scheduled check: when an auction's end time passes without further extensions, the highest bid is declared the winner. Monitoring tracks bid throughput, auction concurrent viewer counts, notification delivery latency, and database lock contention rates. Multiple Web Servers ensure the system handles peak bid activity during popular auction closings.

Design a centralized log aggregation system for a microservices platform with 1,000 services, collecting, transforming, indexing, and making searchable 1 terabyte of logs per day with 30-day retention policies and real-time alerting on error patterns. The system must support log search within 5 seconds and structured JSON logging for efficient parsing. The Client represents the dashboard and alert management interface, connecting through the Load Balancer to Web Servers that serve the search UI and API. Each of the 1,000 microservices ships its logs using lightweight agents (like Filebeat or Fluentd) that forward structured JSON log lines to the Load Balancer and then to Web Servers. The Web Servers publish incoming logs to the Message Queue, which acts as a durable buffer absorbing ingestion spikes and decoupling producers from consumers. Stream Processors consume from the Message Queue and perform log transformation: parsing structured fields (timestamp, severity, service name, trace ID, message), enriching with metadata (datacenter, environment, version), applying sampling rules for verbose debug logs, and routing to appropriate destinations. Transformed logs are written to the Search Index (Elasticsearch-compatible) for full-text search and the Blob Storage for long-term archival. The Search Index supports complex queries: filter by service, severity, time range, and free-text search across message content. Index lifecycle management automatically rolls over indices daily, applies compression to older indices, and deletes indices beyond the 30-day retention window. Real-time alerting is implemented in the Stream Processor: pattern matching rules (e.g., error rate exceeding threshold, specific exception patterns) trigger alerts that are pushed to Monitoring. The Web Server also queries the Search Index directly for interactive log exploration. Monitoring provides dashboards showing ingestion rates, indexing lag, storage utilization, alert trigger frequencies, and query performance metrics. Two Stream Processors and two Web Servers provide processing redundancy and query scalability across the entire logging infrastructure pipeline.

Design a blockchain explorer like Etherscan that indexes every block, transaction, and smart contract on Ethereum, supporting address balance lookups, transaction history, token transfer tracking, and real-time pending transaction pool (mempool) visibility. The system must keep up with the blockchain's block production rate (approximately 12-second block times) and serve queries with sub-500ms latency. The architecture uses an event-driven indexing pipeline where new blocks are detected and processed as they are produced. The API Gateway handles client requests for address balances, transaction details, contract state, and token transfer history, routing them to Web Servers. Web Servers query the Database for indexed blockchain data and the Cache for frequently accessed data like latest block numbers, popular address balances, and real-time gas prices. The indexing pipeline begins with a blockchain node watcher that detects new blocks and publishes raw block data to the Message Queue. The Stream Processor consumes these events and performs deep indexing: parsing each transaction within the block, decoding smart contract interactions, extracting ERC-20 Transfer events from transaction receipt logs, computing address balance changes, and writing all indexed data to the Database. The Stream Processor also handles chain reorganizations (reorgs): when the canonical chain changes, it detects the fork point, rolls back orphaned block data, and re-indexes the new canonical blocks. A 2-block confirmation delay reduces the frequency of reorg handling. The Search Index enables fast lookups by transaction hash, address, and contract address. The Database stores the complete indexed state: blocks, transactions, internal transactions, token transfers, contract code, and computed address balances. The Load Balancer distributes API traffic across multiple Web Servers. Monitoring tracks indexing lag (how far behind the chain tip), reorg frequency, query latency distributions, and Stream Processor throughput. The Cache dramatically reduces Database load for hot data like the latest blocks and popular contract addresses that receive disproportionately high query volumes.

Design a production Retrieval-Augmented Generation (RAG) system for an enterprise knowledge base containing 10 million documents spanning technical manuals, internal wikis, compliance policies, and customer support archives. When an employee asks a natural-language question, the system must retrieve the most relevant document chunks, rerank them by contextual relevance, and generate a grounded, cited answer using a large language model — all within 3 seconds end-to-end. The core challenge is bridging the gap between semantic search and generative AI at enterprise scale. Naive approaches — feeding entire documents to an LLM — fail catastrophically at this volume because of context window limits and cost. Instead, the architecture must implement a multi-stage pipeline: first, incoming documents are split into semantically coherent chunks by a chunking service and embedded into dense vectors by an embedding model. These vectors are stored in a specialized vector database optimized for approximate nearest neighbor (ANN) search. At query time, the user’s question is embedded into the same vector space, and the top-K most similar chunks are retrieved in under 50ms. A reranker then applies a cross-encoder to score each chunk against the original question, ensuring precision far beyond what embedding similarity alone provides. The reranked chunks are assembled into a prompt with the user’s question and sent to an LLM inference service for answer generation. Critically, guardrails must be enforced on both the input (blocking prompt injection, PII leakage) and the output (hallucination detection, toxicity filtering). An AI monitoring service tracks every request’s latency, token usage, retrieval quality, and answer faithfulness — essential for debugging production RAG pipelines where quality degrades silently. The ingestion pipeline runs asynchronously: new documents are queued, chunked by workers, embedded, and indexed into the vector database without blocking the serving path. A cache layer stores frequently asked questions and their answers to reduce LLM costs by up to 40%. This architecture is the backbone of enterprise AI assistants at companies like Microsoft (Copilot), Notion, and Confluent, and represents the current state-of-the-art in knowledge-grounded AI systems.

Design a semantic search platform capable of serving 100 million product embeddings with sub-100ms query latency, supporting an e-commerce catalog where users search by meaning rather than keywords. When a user types 'comfortable shoes for standing all day,' the system must return products semantically related to comfort and prolonged standing - even if those exact words never appear in the product listing. Simultaneously, the platform must support real-time indexing so that newly added products become searchable within seconds. This design tackles the classic CQRS (Command Query Responsibility Segregation) pattern applied to ML infrastructure. The read path and write path have fundamentally different requirements: queries demand sub-100ms latency across 100M vectors, while indexing must handle bursty ingestion (product catalog updates, seasonal bulk imports) without degrading search quality. On the write side, new product data arrives via a message queue, is processed by workers that invoke an embedding service to generate dense vector representations, and the resulting embeddings are persisted into a vector database with HNSW or IVF indexes. On the read side, user queries hit a web server that first checks a cache for recent identical queries, then embeds the query text, and performs an ANN (Approximate Nearest Neighbor) search across the vector index. The key architectural decisions center on sharding strategy (how to distribute 100M vectors across nodes), index rebuild without downtime (blue-green index swaps), and consistency guarantees (how quickly must a newly added product be searchable?). A monitoring layer tracks index health, query latency percentiles, cache hit rates, and embedding model drift - because ML systems degrade silently when the distribution of incoming data shifts. The load balancer distributes queries across multiple web server replicas, each maintaining a local cache of hot query results. Blob storage holds raw product data and model artifacts. This architecture is used by Amazon Product Search, Spotify song discovery, Pinterest visual search, and every modern e-commerce platform implementing semantic product retrieval.

Design an AI gateway that serves as the single entry point for all LLM traffic across an enterprise with hundreds of internal applications consuming AI services. The gateway must intelligently route requests - sending simple classification tasks to fast, cheap models and complex reasoning tasks to powerful but expensive models - while enforcing input/output guardrails for PII detection and toxicity filtering, caching semantically similar queries to reduce costs, and providing full observability into per-team cost attribution, latency distributions, and token consumption patterns. This is the AI equivalent of an API gateway, but with unique challenges that traditional HTTP gateways never face. First, LLM requests are expensive - a single GPT-4 call costs 100x more than a typical API call - so intelligent routing and caching directly impact the bottom line. The prompt router analyzes incoming requests using a lightweight classifier to estimate complexity, then routes to the appropriate model tier. Simple requests (summarization, translation, extraction) go to smaller models at 1/10th the cost, while complex requests (multi-step reasoning, code generation) go to frontier models. Second, the gateway must enforce guardrails in real-time: scanning inputs for prompt injection attacks, PII (social security numbers, credit cards), and scanning outputs for hallucinated content, toxic language, or policy violations. Semantic caching is a game-changer: if a user asks 'What is our refund policy?' and another asks 'How do refunds work here?', the cache recognizes these as semantically equivalent and returns the cached response, saving both latency and cost. The AI monitoring service provides dashboards showing per-application token usage, cost trends, model performance metrics, and cache hit ratios. A rate limiter prevents any single team from exhausting the organization's LLM budget. The database stores usage records, guardrail audit logs, and policy configurations. This pattern is deployed at enterprises using services like Azure AI Gateway, AWS Bedrock, and LiteLLM, where centralized AI governance is essential for cost control, compliance, and security.

Design a two-stage recommendation system for an e-commerce platform serving 50 million users browsing a catalog of 10 million products. When a user visits their homepage, the system must generate personalized product recommendations in under 200ms end-to-end, balancing relevance, diversity, and freshness. The first stage retrieves 200 candidate products via fast vector similarity search, and the second stage reranks these candidates using a cross-encoder that incorporates real-time user context - their last click, current cart contents, time of day, and browsing session features. The two-stage architecture is how every major recommendation system operates - YouTube, Netflix, Amazon, and TikTok all use this pattern because it strikes the optimal balance between recall (finding all relevant items) and precision (ranking the best items highest). Stage 1 uses a bi-encoder to embed both user intent and product features into a shared vector space, then performs an approximate nearest neighbor search to retrieve ~200 candidates from 10M products in under 20ms. Stage 2 uses a cross-encoder - which is 100x slower but 10x more accurate - to score each of the 200 candidates against the user's full context, producing a final ordered list. The real-time feature pipeline is what separates good recommendation systems from great ones. User events - every click, add-to-cart, scroll, and purchase - flow through a message queue into a stream processor that computes sliding-window aggregates (click-through rate in the last 5 minutes, category affinity in the last hour). These computed features are written to a cache acting as a real-time feature store, which the web server reads at query time with sub-millisecond latency. If features become stale, recommendation quality degrades immediately because the model relies on fresh context signals. A monitoring layer tracks recommendation diversity, click-through rates, and feature freshness to detect quality regressions before they impact revenue. The API gateway handles authentication and request routing, while the database stores product catalog metadata and historical user interaction logs for offline model retraining.

Design a platform for running autonomous AI agents capable of multi-step reasoning, dynamic tool execution, and persistent memory across conversations. A user submits a high-level goal - 'Research the latest papers on transformer quantization and write a summary report' - and the agent decomposes it into a plan, executes each step by invoking tools (web search, code execution, file operations, API calls), stores intermediate results in memory, evaluates progress, and iterates until the goal is achieved or a termination condition is met. The core architectural challenge is implementing the ReAct (Reason + Act) agent loop at production scale with safety, observability, and reliability. Each agent turn involves: (1) the LLM reasoning about current state and deciding the next action, (2) executing that action in an isolated sandbox, (3) observing the result, and (4) updating working memory. The agent relies on two memory systems operating at different time scales: episodic memory (a relational database storing the full conversation history, intermediate results, and execution trace) and semantic memory (a vector database storing retrievable knowledge fragments from past interactions for long-term learning). Tool execution must happen inside an isolated sandbox to prevent catastrophic actions - agents can hallucinate dangerous commands. The guardrail service evaluates every proposed action before execution, blocking unauthorized API calls, file system access outside the sandbox, or network requests to internal services. A message queue decouples the LLM inference step from tool execution, allowing the system to handle long-running tools (code execution that takes minutes) without blocking the inference pipeline. Workers process tool calls asynchronously and report results back. An AI monitoring service instruments every agent turn, tracking reasoning quality, tool success rates, plan adherence, and cost per goal - essential for debugging agents that take unexpected paths. The cache stores frequently used tool results and common reasoning patterns. This architecture powers systems like AutoGPT, LangGraph, and enterprise agent platforms at companies building AI automation workflows.

Design the real-time ride-matching and dispatch system that powers a global ride-sharing platform like Uber, serving 20 million rides per day across 600 cities. When a rider opens the app and requests a ride, the system must instantly find the nearest available driver, calculate the optimal route and fare estimate, match rider to driver within 10 seconds, and then track both parties in real-time via bidirectional WebSocket connections until the ride completes and payment is processed. The fundamental challenge is performing geospatial proximity queries at massive scale under sub-second latency constraints. The system maintains a continuously updating map of all active drivers - their GPS coordinates refreshing every 4 seconds. When a ride request arrives, the matching algorithm must search nearby drivers using geohash or S2 cell indexing - a technique that converts 2D latitude/longitude coordinates into a 1D sortable string, enabling efficient spatial range queries in a NoSQL database or cache. The matching engine considers not just distance but also estimated time of arrival (ETA), driver rating, vehicle type preference, and current supply-demand balance in the area. Real-time communication is critical: once matched, both rider and driver apps maintain persistent WebSocket connections to receive live location updates, ETA changes, and status transitions (driver en route → arrived → trip started → trip completed). A pub/sub system handles the fan-out of location updates to all interested parties. The payment service processes the fare at trip completion using a two-phase commit pattern - authorize at trip start, capture at trip end - ensuring idempotent payment even if the network fails mid-trip. Message queues handle asynchronous tasks like sending receipts, updating driver earnings, computing surge multipliers, and triggering fraud checks. Monitoring tracks match time, driver utilization, surge pricing accuracy, and payment success rates across all 600 cities. The DNS and load balancer layers route requests to the nearest regional deployment to minimize latency.

Design Netflix's complete video delivery pipeline serving 250 million subscribers who collectively stream over 1 billion hours of content per week across every type of device - from 4K smart TVs to mobile phones on flaky cellular connections. When a user selects a title, the system must begin high-quality video playback within 2 seconds, dynamically adapt bitrate to network conditions, and maintain the illusion of an infinite, personalized catalog powered by sophisticated recommendation algorithms. The architecture splits into two fundamentally different subsystems: the control plane (browse, search, recommendation, authentication) and the data plane (actual video byte delivery). The control plane runs on web servers behind a load balancer and API gateway, serving the personalized catalog feed - each user's homepage is uniquely generated by combining collaborative filtering, content-based signals, and viewing history stored in a NoSQL database. The data plane leverages a global CDN with points of presence on every major ISP, positioning video content within a single network hop of 95% of subscribers. The video ingestion pipeline is equally complex: when new content is uploaded to blob storage, a message queue triggers transcoding workers that encode each title into hundreds of renditions - multiple resolutions (240p through 4K), multiple codecs (H.264, VP9, AV1), and multiple audio tracks - creating thousands of small segments for adaptive bitrate streaming using HLS or DASH protocols. A stream processor analyzes viewing patterns in real-time to pre-position popular content on edge CDN nodes before demand spikes. The cache layer stores session state, user preferences, and continue-watching positions. A relational database manages the content catalog metadata, licensing windows, and regional availability restrictions. Monitoring tracks buffer ratios, time-to-first-byte, playback failures, and per-title engagement metrics - because even a 100ms increase in startup time measurably impacts viewer retention. The DNS layer routes clients to the optimal CDN location using latency-based routing.

Design a real-time team messaging platform like Slack supporting 1:1 direct messages, group channels with up to 100K members, threaded conversations, file sharing, message search, read receipts, typing indicators, and online/offline presence detection. The system must deliver messages in under 100ms and sustain 500K concurrent WebSocket connections per data center while maintaining message ordering guarantees within each channel. The core architectural challenge is message fan-out at scale. When a user sends a message to a channel with 100K members, the system cannot push individual notifications to 100K WebSocket connections synchronously - that would take seconds. Instead, the architecture uses a tiered fan-out strategy: small groups (under 500 members) use direct WebSocket push via a pub/sub system, while large channels use a lazy-loading approach where clients poll for updates on channels they are actively viewing. The WebSocket server layer maintains long-lived connections with every online client, handling connection lifecycle (connect, heartbeat, reconnect, disconnect), message delivery, and presence tracking. Message storage uses a dual-write pattern: the primary database (relational) stores the canonical message with its channel, author, timestamp, and threading metadata, while a NoSQL database stores denormalized message timelines optimized for fast sequential reads (the chat scroll experience). A search index receives messages asynchronously via a message queue and builds a full-text inverted index for keyword search with channel-scoped access control. Workers handle file processing (thumbnail generation, virus scanning, format conversion) for uploads stored in blob storage. The cache layer stores channel membership lists, user presence state, and recent message windows - the 'last 50 messages' that every client requests on channel open. Monitoring tracks message delivery latency (p50, p95, p99), WebSocket connection stability, fan-out times for large channels, and search indexing lag. The load balancer distributes WebSocket connections across server instances using sticky sessions to maintain connection affinity. This architecture is deployed at Slack, Discord, Microsoft Teams, and every modern real-time collaboration platform handling millions of concurrent users.

Design a real-time collaborative document editor like Google Docs where 50 concurrent users can edit the same document simultaneously, with every keystroke visible to all collaborators within 200ms. The system must resolve conflicting edits without data loss, maintain a complete version history with the ability to view any past state, support offline editing with automatic sync-on-reconnect, and handle documents ranging from simple notes to 500-page technical manuals with embedded images and tables. The primary technical challenge is concurrent conflict resolution. When User A inserts text at position 42 while User B simultaneously deletes text at position 40, the system must merge both operations into a consistent final state that preserves both users' intent. This design uses CRDTs (Conflict-Free Replicated Data Types) - mathematical data structures that guarantee eventual consistency without coordination. Unlike Operational Transform (OT, used in early Google Docs), CRDTs converge automatically regardless of the order operations are applied, making them ideal for peer-to-peer and offline-capable scenarios. The real-time synchronization layer uses WebSocket connections: each client maintains a persistent connection to a WebSocket server that broadcasts operations to all collaborators of a document. The pub/sub system handles cross-server fanout when collaborators are connected to different WebSocket server instances. Every operation is persisted to a NoSQL database as an immutable event log, enabling full version history reconstruction by replaying operations from any checkpoint. Workers periodically create document snapshots and store them in blob storage to speed up history browsing and reduce replay costs. The cache stores the current document state and active cursor positions for all collaborators. A relational database manages document metadata - ownership, sharing permissions, folder structure, and collaboration settings. The message queue handles asynchronous tasks: generating document previews, indexing document content for search, sending notification emails for comments, and processing image uploads. Monitoring tracks operation merge latency, conflict frequency, WebSocket connection stability, and document load times.

Design a distributed workflow orchestration engine like Apache Airflow capable of managing 10,000 concurrent DAG (Directed Acyclic Graph) runs across a cluster of worker machines. Users define workflows as DAGs where each node represents a task (run a SQL query, train an ML model, call an API, transform a dataset) and edges represent dependencies. The scheduler must respect dependency ordering - a task runs only after all its upstream dependencies complete - distribute tasks across available workers, handle retries on failure, and provide real-time visibility into every task's status, logs, and execution history. The central architectural challenge is distributed scheduling with exactly-once task execution guarantees. In a distributed system, the scheduler itself must be highly available - if the scheduler dies, thousands of in-flight workflows must not be lost or duplicated. The design uses Zookeeper for leader election: one scheduler instance is the active leader responsible for parsing DAGs, evaluating task readiness (all upstream deps completed?), and enqueuing ready tasks onto a message queue. If the leader fails, Zookeeper triggers a failover to a standby scheduler within seconds, which reconstructs state from the database. Workers consume tasks from the message queue using a competing-consumer pattern - multiple workers pull from the same queue, providing natural load balancing and horizontal scalability. A dead letter queue captures tasks that fail repeatedly, preventing poison tasks from blocking the pipeline. Each task execution is recorded in the database with start time, end time, exit code, retry count, and log output. The web server provides a dashboard showing DAG runs, task status (queued → running → success/failed), Gantt charts of execution timelines, and log streaming for debugging. A cache stores frequently accessed DAG definitions and recent task states to reduce database load. Blob storage holds task artifacts - CSV outputs, model checkpoints, generated reports - that downstream tasks can consume. A task scheduler component handles cron-based DAG triggering, evaluating which DAGs should run based on their configured schedules. Monitoring tracks scheduler lag, task queue depth, worker utilization, and failure rates per task type.

Design the order matching engine and real-time market data distribution system for a global stock exchange processing 5 million orders per second during peak trading hours. The matching engine must maintain a price-time priority order book for each of 10,000 listed symbols, execute trades with sub-millisecond deterministic latency, broadcast market data updates to 500,000 connected subscribers within 1 millisecond of execution, and maintain a tamper-proof audit trail where every order and trade is deterministically replayable for regulatory compliance. The matching engine is architecturally unique: it must be single-threaded per symbol to guarantee deterministic execution ordering. Unlike typical web services that scale horizontally, the core matching loop processes orders sequentially from a FIFO queue to ensure that two orders arriving in the same microsecond are matched in exactly the order they were received - a regulatory requirement. The engine maintains an in-memory order book with two sorted sides (bids descending by price, asks ascending by price) and executes matching by comparing the best bid against the best ask. When they cross, a trade occurs. Market data distribution uses a pub/sub fan-out architecture: every trade execution and order book update is published to a topic per symbol, and 500K subscribers (trading desks, algorithmic trading systems, market data vendors) receive updates via WebSocket connections with sub-millisecond latency requirements. A stream processor computes derived data in real-time: VWAP (volume-weighted average price), candlestick aggregations, and market-wide indicators. The time-series database stores tick-by-tick historical data for backtesting and regulatory queries. A NoSQL database stores order lifecycle events (submitted, partially filled, filled, cancelled) indexed by order ID for fast lookups. The cache holds the current state of every order book (top-of-book). The database stores account balances, positions, and risk limits. A message queue feeds post-trade processing: clearing, settlement, regulatory reporting, and margin calculations. Monitoring tracks matching latency, message queue depth, subscriber lag, and system resource utilization with microsecond precision.

Design a multi-tenant SaaS platform like Salesforce serving 10,000 enterprise customers on shared infrastructure where each tenant's data must be completely logically isolated from every other tenant. The platform must support per-tenant rate limiting, custom domain mapping (each customer accesses the platform via their own branded domain), tenant-aware query routing with shard isolation, and robust protection against the 'noisy neighbor' problem - where one tenant's heavy analytical workload must never degrade the API response times of other tenants. The foundational architectural decision in multi-tenancy is the data isolation strategy. This design implements a shared-database, sharded-by-tenant approach: all tenants share the same database cluster, but data is partitioned by tenant_id, and every query is automatically scoped to the requesting tenant's partition. This balances cost efficiency (no per-tenant DB instances) with isolation (queries physically cannot access other tenants' data). The tenant identification pipeline is critical: DNS resolves each custom domain to the load balancer, the API gateway extracts the tenant_id from the JWT token or domain mapping, and this tenant context propagates through every downstream component. The noisy neighbor mitigation strategy uses a layered defense. The rate limiter enforces per-tenant API quotas at the edge - preventing any single tenant from consuming more than their allocated share of system throughput. The circuit breaker wraps database calls on a per-tenant basis: if Tenant A's queries start exceeding 500ms (indicating they are running heavy reports), the circuit opens for Tenant A specifically, returning cached or degraded responses, while Tenant B through Tenant Z continue to receive full-speed database access. A message queue offloads heavy tenant operations (bulk data exports, report generation, data migrations) to background workers, preventing these long-running tasks from consuming web server threads. The cache stores per-tenant configuration (feature flags, plan limits, UI customizations) with tenant_id as a key prefix for namespace isolation. Monitoring tracks per-tenant latency, query volume, circuit breaker trip frequency, and resource consumption to identify tenants approaching their limits.

Design a high-throughput telemetry ingestion and monitoring platform for a fleet of 10 million IoT devices - industrial sensors, connected vehicles, smart electricity meters, and environmental monitors. Each device reports metrics every 5 seconds, generating a sustained throughput of 2 million events per second. The platform must detect anomalies in real-time (within 30 seconds of occurrence), store 90 days of raw telemetry data, and power interactive dashboards that query trillion-row datasets with sub-second latency for fleet operators monitoring device health across regions. The ingestion pipeline is designed to absorb massive, bursty traffic without data loss. Devices connect through a load balancer that multiplexes millions of concurrent connections (using connection pooling and protocol-level multiplexing), then authenticate via an API gateway that validates device certificates and extracts device metadata. Authenticated telemetry flows into a message queue acting as a shock absorber - buffering traffic spikes (devices reconnecting after a network outage can create 10x burst traffic) and decoupling ingestion from processing. The stream processor consumes events from the queue and performs three operations in parallel: writing raw events to the time-series database, computing sliding-window aggregates (mean, standard deviation, percentiles) per device for anomaly detection, and forwarding detected anomalies to a pub/sub topic for alert fan-out. The time-series database is purpose-built for this workload: it provides automatic time-based partitioning, built-in downsampling (converting 5-second raw data to 1-minute averages after 7 days, and 1-hour rollups after 30 days), and efficient range scans for dashboard queries. Workers handle the background downsampling jobs, running periodically to compact aging data. The web server powers the fleet management dashboard, querying the time-series database for historical trends and the cache for recently computed aggregates. A relational database stores device registry information - serial numbers, firmware versions, deployment locations, and ownership metadata. Monitoring tracks ingestion throughput, processing lag, anomaly detection accuracy, and per-region device connectivity rates.

Design a global payment processing platform like Stripe handling 500 billion dollars per year in transactions across 135 currencies, serving millions of merchants from local coffee shops to multinational corporations. The system must guarantee exactly-once payment execution - if a customer is charged, they must never be double-charged even if the network fails mid-transaction. The platform must support idempotency keys for safe retries, process payments through a two-phase authorize-then-capture flow, handle partial failures gracefully across a multi-step transaction pipeline, maintain PCI-DSS level 1 compliance, and reconcile every transaction with merchant settlement within 24 hours. The two-phase payment flow works as follows: when a customer initiates payment, the system first authorizes the amount - checking card validity, available balance, and fraud signals - and places a hold without actually transferring money. The capture step, triggered after order fulfillment, completes the actual fund transfer. This separation allows merchants to cancel unfulfilled orders without ever moving money, and handles the real-world gap between 'customer clicked pay' and 'merchant shipped the product.' The payment service encapsulates the state machine for each transaction (created → authorized → captured → settled → reconciled) with strict state transition rules and idempotency checks at every step. Exactly-once semantics are implemented through idempotency keys stored in the database: every API call includes a unique key, and the system checks if an identical request was already processed before executing it. A dead letter queue catches transactions that fail repeatedly after exhausting retries - these require human investigation and are triaged by support teams. Workers run nightly settlement batches, calculating net amounts owed to each merchant after subtracting fees and refunds, then initiating bank transfers. The rate limiter prevents fraud and abuse at the API level. The cache stores merchant configuration, fee schedules, and recent transaction lookups. Monitoring tracks authorization success rates, capture-to-settlement latency, DLQ depth, and payment method distribution across regions.

Design a distributed observability platform like Datadog ingesting 50 terabytes per day of telemetry data - traces, metrics, and logs - from 100,000 microservices deployed across 200 data centers worldwide. The system must correlate a single user request as it traverses 30+ service hops, support real-time anomaly detection on latency percentiles (alerting within 60 seconds when p99 latency spikes), provide full-text log search across petabytes of data, and retain 30 days of full-fidelity data queryable with sub-second latency. The telemetry pipeline splits into three specialized paths after ingestion. All telemetry enters through a load balancer and API gateway that classifies data type (trace, metric, or log) and routes it into a message queue for buffering. From the queue, data fans out into three parallel pipelines: (1) Logs flow through a log aggregator that parses, enriches (adding service name, environment, deployment version), and indexes them into a search index (Elasticsearch-like) optimized for full-text search with field-level filtering. (2) Traces flow to a stream processor that assembles individual spans into complete distributed traces by grouping on trace_id - this requires time-windowed aggregation (waiting up to 60 seconds for all spans from all services to arrive) - and stores assembled traces in a relational database indexed by trace_id, service, and time range. (3) Metrics are aggregated by the stream processor into time-series buckets and written to a time-series database optimized for range queries and downsampling. The query layer serves the observability dashboard: the web server handles user queries routed to the appropriate storage backend - search index for log searches, time-series database for metric dashboards, relational database for trace waterfall views. A cache stores frequently accessed dashboard queries, pre-computed aggregations, and hot trace data. The stream processor also runs continuous anomaly detection queries - computing rolling percentiles and statistical deviations on metric streams, firing alerts when thresholds are breached. Monitoring provides meta-observability: tracking the observability platform's own ingestion throughput, indexing lag, query latency, and storage utilization to ensure the platform monitoring your infrastructure is itself healthy.

Design a global content delivery network and edge computing platform like Cloudflare with 300 points of presence across 100 countries, serving 30 million requests per second at the edge. The system must route each user request to the nearest healthy edge node using anycast DNS, implement a hierarchical cache architecture with sub-50ms global cache invalidation, execute serverless functions at the edge with cold-start times under 5ms, and absorb distributed denial-of-service attacks of up to 10 Tbps without any degradation to legitimate traffic. The hierarchical cache design is the most critical architectural element. Three tiers of caching absorb traffic at progressively closer distances to the user: edge caches at 300 PoPs (closest to users, handling 90% of requests), regional caches at 30 super-PoPs (aggregating misses from nearby edges), and an origin shield (a reverse proxy layer that collapses thundering-herd cache misses before they reach origin servers). This hierarchy means origin servers see only 0.1% of total traffic - the other 99.9% is served from cache. Content flows from origin web servers through the reverse proxy, to the load balancer, and out to cache layers and CDN edge nodes. Cache invalidation across 300 PoPs must happen in under 50ms to support dynamic content caching. When origin content changes, the web server publishes an invalidation event to a pub/sub system, which broadcasts simultaneously to every edge PoP. Each PoP subscribes to the invalidation topic and purges the specified cache keys locally - this is push-based invalidation, far faster than waiting for TTL expiry. DDoS mitigation happens at the CDN edge layer: a rate limiter scrubs malicious traffic using behavioral analysis, IP reputation, and challenge-response mechanisms before traffic ever reaches origin infrastructure. Workers execute serverless functions at the edge, enabling computation at the CDN layer - URL rewriting, A/B testing, authentication, image optimization - without origin round-trips. Blob storage holds static assets. Monitoring tracks cache hit ratios, edge latency, DDoS mitigation effectiveness, and worker execution times across all 300 PoPs.

Design the complete control plane for an event-driven microservices platform like Kubernetes combined with Istio, managing 5,000 services across 50 clusters with a total of 200,000 running pods. The system must handle service discovery with real-time health checking, traffic splitting for canary deployments (routing 5% of traffic to a new version while 95% stays on the stable version), circuit breaking between services to prevent cascading failures, distributed configuration management, and full service mesh observability - all while adding less than 5ms of overhead to every service-to-service call. The service mesh architecture interposes a sidecar proxy (reverse proxy) alongside every microservice instance. All inbound and outbound traffic flows through this sidecar, which transparently handles retry logic, circuit breaking, mutual TLS encryption, load balancing, and metrics collection - freeing application code from implementing these cross-cutting concerns. The circuit breaker monitors error rates on a per-service-pair basis: if Service A's calls to Service B fail more than 50% of the time within a 10-second window, the circuit opens and all subsequent requests from A to B return an immediate fallback response, preventing A from wasting resources on a failing dependency and stopping the failure from cascading upstream. Service discovery uses a registry backed by Zookeeper for consensus. When a new service instance starts, it registers its address, health endpoint, version, and metadata with the service registry. Health checks run continuously - if a health probe fails three consecutive times, the instance is deregistered, and traffic is automatically rerouted to healthy instances. The API gateway serves as the ingress controller, querying the service registry (or its cached copy) to route external traffic to the correct internal service and version. Canary deployments are implemented by configuring traffic splitting rules in the sidecar proxies: the API gateway tags requests with a routing header, and sidecars route accordingly. Message queues enable asynchronous event-driven communication between services. Monitoring collects the golden signals (latency, traffic, errors, saturation) from every sidecar, providing end-to-end visibility into request paths across the entire mesh.

Design a web-scale search engine capable of indexing 100 billion documents - the entire publicly crawlable web - and serving 100,000 search queries per second with relevant results returned in under 500ms. The system must support near-real-time freshness, with newly published pages indexed and searchable within 10 minutes. The ranking pipeline must evaluate hundreds of signals per document, including text relevance, link authority (PageRank), content freshness, user engagement metrics, and semantic understanding - while also supporting spelling correction, query suggestions, and knowledge panel extraction. The architecture divides into two massive subsystems: the indexing pipeline and the serving stack. The indexing pipeline begins with a distributed web crawler: workers pull URLs from a priority queue (the URL frontier stored in a NoSQL database), fetch pages, extract content, discover new links, and feed them back into the frontier. Politeness constraints limit crawl rate per domain to avoid overwhelming websites. Fetched content is stored as raw HTML in blob storage and processed by stream processors that extract text, detect language, identify entities, and build inverted index entries. The inverted index - the core data structure mapping every word to the documents containing it - is sharded across 10,000 search index nodes using consistent hashing. The serving stack handles queries through a multi-stage ranking pipeline. When a query arrives, the web server first applies spelling correction and query expansion (using synonyms and related terms from a cache), then scatters the query to all relevant index shards in parallel. Each shard returns its top-K candidates using a fast first-stage scoring function (BM25 + shallow features). The results are gathered, merged, and fed to a second-stage ML ranker that evaluates deep features - semantic similarity, PageRank, click-through rate history, content freshness - to produce the final ranking. The CDN serves static assets (logos, stylesheets). A database stores user preferences and search history. The cache stores query suggestion completions, hot query results, and frequently accessed knowledge panels. Monitoring tracks query latency, index freshness lag, crawler throughput, and ranking quality metrics.

Design a globally-distributed SQL database like Google Spanner or CockroachDB that provides full serializable transaction isolation across 5 geographic regions with read latencies under 100ms and write latencies under 500ms. The system must handle complete region failures transparently (a region going offline must not cause data loss or service interruption), support automatic range-based sharding that splits and merges ranges as data grows, maintain a global transaction log with causal ordering guarantees, and achieve 99.999% availability - less than 5 minutes of downtime per year. The fundamental impossibility in distributed databases is maintaining both strong consistency and low latency across geographic distances. This design uses a Raft consensus protocol (modeled through Zookeeper) where each data range is replicated across 3 or 5 regions, and writes require a majority quorum to commit. Read operations can be served from the nearest replica using hybrid logical clocks that guarantee causal consistency - a reader always sees all writes that causally precede their read, even if those writes occurred in a different region. Writes must traverse the WAN to achieve quorum, hence the higher latency budget (500ms) compared to reads (100ms). Range-based sharding divides the key space into contiguous ranges, each assigned to a set of replicas. As data grows, ranges automatically split when they exceed a size threshold (typically 512MB), and ranges with low traffic are merged to reduce overhead. A message queue propagates range split/merge events to all nodes, and workers handle background data rebalancing. Bloom filters are critical for read performance: before issuing a disk read for a key lookup, the system checks a probabilistic bloom filter to determine if the key exists in a given data file, avoiding 99% of unnecessary disk reads. The cache stores frequently accessed data ranges and recent transaction results. A time-series database stores per-range latency metrics, replication lag, and throughput statistics for capacity planning. Monitoring tracks cross-region replication lag, transaction commit latency, range split frequency, and quorum health across all regions.

Design a real-time fraud detection system for a payment network like Visa or Mastercard, processing 65,000 transactions per second with an ironclad 50ms decision deadline - every transaction must be approved or declined before the merchant's terminal times out. The system evaluates each transaction against 200+ risk signals including velocity checks (how many transactions in the last hour), geolocation anomalies (card used in New York and London within 30 minutes), device fingerprinting, merchant risk categories, behavioral biometrics, and historical fraud patterns - achieving 99.95% precision while keeping false positives under 0.1% to avoid blocking legitimate purchases. The architecture is designed around a single imperative: the 50ms budget must never be exceeded, because a slow fraud check means a declined transaction and lost revenue. The request path is ruthlessly optimized: the web server receives the transaction, performs a bloom filter check against known-fraudulent card numbers (O(1) lookup, zero network calls), reads pre-computed risk features from a cache acting as a real-time feature store (sub-millisecond read latency), runs the ML scoring model in-process, and returns the decision. No database call is on the critical path - all feature data is pre-materialized in the cache by the streaming pipeline. The real-time feature computation pipeline runs in parallel with the scoring path. A stream processor consumes every transaction event from a message queue and maintains sliding-window aggregates: transaction count per card in the last 1/5/60 minutes, average transaction amount, geographic velocity (distance between consecutive transactions divided by time), merchant category distribution shifts, and hundreds more. These computed features are written to the cache with sub-second freshness. Workers handle offline model training - retraining the fraud scoring model on labeled transaction data (confirmed fraud vs legitimate) and deploying updated models. A NoSQL database stores the full transaction history and fraud case investigations. Bloom filters are periodically rebuilt from the confirmed fraud database and deployed to all scoring nodes. Monitoring tracks model precision, recall, false positive rate, feature freshness, and p99 scoring latency to ensure the system never degrades below its 50ms SLA.

Design a global social media platform that unifies every system design pattern you have mastered throughout this journey — user feeds, real-time messaging, live video streaming, search, notifications, payments, analytics, content moderation, and advertising — serving 3 billion monthly active users across 6 continents with 99.999% uptime. This is the ultimate integration challenge: every component must work together as a cohesive system, handling the cascading complexity of dozens of interdependent subsystems operating at planetary scale. The read path alone processes millions of requests per second: users scrolling feeds, searching content, watching videos, and receiving real-time notifications. DNS with anycast routing directs users to the nearest data center. A CDN edge layer absorbs static content requests (images, videos, stylesheets), reducing origin traffic by 99%. The load balancer and API gateway authenticate requests, enforce rate limits, and route to the appropriate backend service. Web servers handle synchronous API calls while WebSocket servers maintain persistent connections for real-time features — chat messages, typing indicators, live comments, and push notifications. The write path is equally complex: every post, like, comment, share, and message triggers a cascade of fan-out operations. A pub/sub system distributes events to dozens of downstream consumers: the feed builder, notification service, search indexer, analytics pipeline, content moderation queue, and ad relevance scorer. Stream processors compute real-time engagement metrics, trending topics, and abuse detection signals. The storage tier spans multiple specialized databases: a relational database for user accounts and relationships, a NoSQL database for timeline data and activity feeds, a graph database for the social graph and friend recommendations, blob storage for media files, a search index for full-text and entity search, and a time-series database for analytics dashboards. Workers handle every flavor of asynchronous processing: video transcoding, image resizing, content moderation ML inference, notification delivery, and advertisement auction computation. Zookeeper coordinates distributed locks and configuration across regions. The dead letter queue captures failed events for investigation. Payment service handles creator monetization and ad billing. This capstone challenge tests your ability to synthesize all patterns into a single coherent architecture.

Design the outbound delivery system that lets your platform notify third-party integrators the moment something happens - a payment succeeds, an order ships, a document is signed. Unlike a normal API response, a webhook is a promise your system makes to a URL it doesn't control: that endpoint might be slow, offline, or permanently dead, and the delivery has to survive all three without losing an event or hammering a broken partner forever. The write path accepts an internal 'event occurred' call, persists it durably, and enqueues a delivery job so the API that triggered the event never blocks on a partner's server. A pool of delivery workers pulls jobs off the queue, signs the payload (HMAC) and POSTs it to the subscriber's registered URL, retrying with exponential backoff on failure. A per-endpoint circuit breaker stops wasting attempts on a subscriber that has been down for an hour, and anything that exhausts its retries lands in a dead-letter queue for manual replay instead of vanishing.

Design the coordination layer behind a multi-step order fulfillment flow - charge payment, reserve inventory, schedule shipping - where each step is owned by a different service and there is no single database transaction spanning all three. If the third step fails after the first two succeeded, the system can't just 'roll back'; it has to run compensating actions (refund the payment, release the inventory hold) in reverse order. This is the Saga pattern: a sequence of local transactions coordinated by an orchestrator that knows how to undo each step it has already committed. An orchestrator service owns the saga's state machine, persisting exactly which step each in-flight order is on so it can resume after a crash. It calls the payment service synchronously (the one step that must confirm before anything else proceeds), then publishes step-completed events for the rest of the flow. A cache of idempotency keys stops a retried step from double-charging or double-reserving stock. Anything that can't be automatically compensated after repeated attempts is queued for manual intervention rather than silently abandoned.

Design the sync engine behind a Figma/Miro-style infinite canvas where dozens of people drag shapes, draw strokes, and edit text simultaneously and see each other's changes within milliseconds. The hard problem isn't drawing shapes - it's that two people can move the same object at the same time, on different servers, with no central lock, and both edits still have to converge to the same final state on every client without an explicit merge step. Each board session is served by a sync server holding the live, in-memory CRDT (or OT) document for that board. Every operation a client makes - move shape, add point to a stroke, edit text - is broadcast to every other server holding a connection to that board via a pub/sub fan-out, so users connected to different servers still see each other's cursors and edits in real time. The full document only round-trips to durable storage periodically as a snapshot, not on every keystroke; losing the last few hundred milliseconds of edits on a server crash is an acceptable trade for not writing to a database on every mouse-move.

Design the checkout path for a flash sale where 500 units of a product go live and 200,000 people hit 'buy' in the same 10 seconds. The system must never sell more units than exist (oversell), never let a single slow request hold stock hostage forever, and stay responsive under a traffic spike two orders of magnitude above normal - all without turning inventory decrement into a database lock convoy. Every reservation attempt goes through an atomic decrement against an in-memory counter, which is the only component fast and consistent enough to arbitrate thousands of concurrent claims per second without becoming the bottleneck itself. A successful decrement creates a short-lived hold (a TTL reservation) rather than an immediate sale - the user still has to complete checkout. A background reaper expires abandoned holds and returns that stock to the pool, and every state change (reserved, purchased, expired, released) is appended to a durable order ledger so the counter can always be reconciled against ground truth.

Design the SSO and session layer that every other service in the company delegates authentication to: login, MFA, JWT issuance, refresh-token rotation, and instant revocation, serving every internal and customer-facing app from a single identity provider. The hardest constraint isn't login throughput - it's revocation. Once a JWT is signed, it's valid until it expires unless something checks a revocation list on every request, which means that list has to be readable in low single-digit milliseconds at global scale. The auth service issues short-lived access tokens plus longer-lived refresh tokens, storing active sessions and the revocation list in an in-memory store fast enough to check on every authenticated request across the company. Credentials and MFA secrets live in a durable, encrypted store that the auth service is the only thing allowed to touch directly. When a user enables MFA, an OTP is delivered through a notification channel rather than being generated client-side, keeping the shared secret entirely server-side.

Design a Calendly-style scheduling platform: a host publishes their availability, a guest picks an open slot, and the system must guarantee that exact slot can never be double-booked - even if two guests click 'confirm' within the same millisecond, and even after the booking has to be synced out to the host's real Google/Outlook calendar. The correctness problem is a distributed one: the source of truth for 'is this slot free' has to be checked and claimed atomically, while the sync to an external calendar provider is a slow, unreliable, eventually-consistent side effect that can never be allowed to block the booking itself. The scheduling API resolves availability by intersecting the host's working hours, existing bookings, and buffer rules, then claims a slot with a conditional write that fails if it's already taken. A cache serves the hot 'next 30 days of availability' view so browsing doesn't hammer the database. Once a slot is claimed, an event fans out asynchronously to send confirmation emails/SMS and push the booking into the host's external calendar via a background worker, so a slow third-party API never makes the guest wait.

Design the bid engine behind a real-time ad exchange: a publisher's page loads, an ad slot goes up for auction, and dozens of advertisers' bidding systems have roughly 100 milliseconds - total, round-trip, across the internet - to receive the request, decide, and respond before the auction closes and the page renders without their ad. This level models the exchange side: the component that scores incoming bid requests against every active campaign's budget and targeting rules fast enough to make that deadline. Every bid request is scored against an in-memory view of each campaign's remaining budget and pacing state - a database round trip per bid is disqualifying at this latency budget, so budget/pacing lives entirely in a fast in-memory store, updated continuously. A stream processor consumes the firehose of win/loss notices after each auction closes, decrementing spend and feeding a warehouse for advertiser-facing reporting - deliberately off the hot bidding path, since accounting can be a few seconds behind without breaking anything, but a bid can't be.

Design the chat system behind a live stream with a million concurrent viewers, where every message and emoji reaction has to fan out to every connected viewer within a second or two, obvious spam/banned content has to be filtered before it's ever broadcast, and none of it can be allowed to blow up a single server's memory or bandwidth. Unlike a normal DM-style chat, live-stream chat is almost entirely broadcast: one popular streamer's room can have hundreds of thousands of concurrent connections, all needing the identical message stream. Viewers hold a persistent connection to a chat gateway; a message posted by any one of them is checked against a fast probabilistic filter for known banned phrases before being fanned out through a pub/sub layer to every gateway instance serving that room, each of which pushes it down to its own connected viewers. A short rolling buffer of recent messages lets a viewer who just joined catch up instantly without a slow historical query, while a moderation log persists a durable record for after-the-fact review and bans.

Design the server-authoritative state sync behind a real-time multiplayer game session: every player's client predicts its own movement instantly for responsiveness, but the server holds the one true game state and corrects any client that drifts, so no player can simply edit their local client to teleport or clip through walls. Dozens of players in a match each send input dozens of times per second, and the server has to simulate the resulting world state and broadcast it back to everyone in that match, in sync, every tick. A session server owns the authoritative simulation for one match and holds its live state - player positions, health, projectiles - entirely in memory, since a database round trip on every tick would blow the frame budget. Each accepted input moves the simulation forward one tick, and the resulting state broadcasts to every client in the match through the same connection each client used to send its input. When the match ends, a summary is persisted for match history and stats; the frame-by-frame state itself is never written to durable storage.

Design the infrastructure behind 'push code, get a deployed build': a commit triggers a pipeline that checks out the code, runs it through a fleet of build workers, caches dependencies and layers so the tenth build of the day isn't as slow as the first, publishes the resulting artifact, and rolls it out - all while giving every engineer in the company a live view of their build's status and a durable history of every build that ever ran. A pipeline controller receives the trigger and enqueues a build job rather than running it inline, since a build can take anywhere from thirty seconds to twenty minutes and must never tie up the API that accepted the webhook. A fleet of build runners pulls jobs off that queue, checks a layer/dependency cache before rebuilding anything from scratch, and pushes the resulting artifact to a registry. Every build's outcome, logs, and duration are written to a durable store so the pipeline controller can answer 'what's the status of build #4821' without asking the runner that may have already shut down.

Design the system that validates and redeems promo codes at checkout across a platform doing millions of orders a day, where a single viral 20%-off code can suddenly appear in ten thousand checkout requests within the same second. The system must guarantee a single-use code is never redeemed twice by the same account (even under a retried or double-submitted request), enforce per-user and global redemption caps, and reject brute-force code-guessing attempts - all inside the checkout critical path, where added latency directly costs conversion. Every redemption attempt first passes a fast probabilistic check for codes that are structurally invalid or already fully exhausted, then an idempotency check keyed on (user, code, order) so a retried request returns the original result instead of redeeming twice. Only after both checks pass does the request touch the durable coupon ledger, which enforces the real per-user and global caps with an atomic conditional write. A rate limiter ahead of the whole path exists specifically to blunt scripted brute-force attempts at guessing valid codes.

Design the pricing and availability engine behind an Airbnb-style booking platform, where every listing has its own multi-night availability calendar and its nightly price shifts continuously with demand signals - search volume, how many nights until check-in, how booked-up the surrounding dates already are. A guest browsing a listing needs an instantly-computed price for their chosen date range, and a booking must atomically claim every night in that range or none of them, since a partial multi-night hold is worse than no hold at all. The booking API resolves availability and price from a cache-backed calendar view for fast browsing, but every actual booking attempt goes through an atomic multi-night claim against the durable store - either the whole date range locks, or the attempt fails cleanly and the guest sees which nights are gone. A stream processor consumes booking and search events continuously, recalculating each listing's dynamic price from live demand signals and writing the refreshed price back, so the price a guest sees is always close to current without every page view triggering a synchronous recalculation.

Design a Stripe-style billing system that handles both fixed recurring subscriptions and metered usage billing - a customer on a $99/month plan that also pays per API call over their included quota. The system has to ingest a continuous stream of usage events without ever losing one (an unbilled API call is lost revenue), roll them up accurately per billing period, and only then hand the final amount to a payment processor - all while keeping the usage-ingestion path completely decoupled from the periodic charge-processing path, since the two run on entirely different cadences. Usage events stream in continuously and are durably queued before anything else touches them, so a burst of API traffic never risks dropping billing data. A stream aggregator rolls those events into per-customer, per-period totals. Separately, on each billing cycle, the billing API reads the subscription record and the aggregated usage total, computes the final charge, and calls the payment processor synchronously - since a charge attempt genuinely needs to know its result before proceeding - while a plan/pricing cache keeps that computation from hitting the database for data that rarely changes.

Design the ingestion pipeline that feeds a company's analytics warehouse from dozens of upstream services scattered across regions - part real-time (a stream of individual events, transformed and loaded within seconds) and part batch (large periodic bulk loads that are more efficient for high-volume, less time-sensitive sources). Both paths have to land in the same warehouse without either one corrupting or duplicating what the other wrote, and neither can be allowed to silently drop data if a downstream write fails. Upstream services publish raw events through an ingestion API that immediately queues them rather than processing inline, since transformation and loading are comparatively slow and must never block the producer. A stream processor consumes that queue continuously for the real-time path, transforming and loading each event within seconds. A separate batch worker periodically pulls accumulated raw data from cheap staging storage and bulk-loads it into the warehouse - better throughput per byte than the streaming path, at the cost of latency the batch sources don't need anyway.

Design the feature-serving layer behind a real-time ML model - fraud scoring, recommendations, ad ranking - where inference needs dozens of precomputed features (user's 7-day spend, item's click-through rate) in single-digit milliseconds, but those same features also have to be available for offline training in a way that guarantees the model sees identical values at train time and serve time. This train/serve parity requirement is the classic feature-store problem: two very different access patterns (point lookups at low latency vs bulk historical reads for training) drawing from what must be a single logical source of truth. An online store holds the latest value of every feature in memory, read on the hot inference path with no tolerance for a slow round trip. A streaming computation layer continuously recomputes features as new raw events arrive and writes the fresh values into that online store. The same computed values are also written to an offline store optimized for large historical scans, which is what a training job reads from - so a model trained on 90 days of history and a live inference call one millisecond later are guaranteed to be looking at features computed the exact same way.

Design a Kafka-style schema registry: the service every producer and consumer in an event-driven company checks before writing or reading a message, so a producer's well-intentioned field rename or type change can't silently break every downstream consumer of that topic. The core job is enforcing compatibility rules (can a new schema version be read by consumers still using the old one?) at registration time, not discovering the break in production hours later. When a producer registers a new schema version, the registry checks it against the topic's configured compatibility mode - backward, forward, or full - by comparing it to the prior version, and rejects the registration outright if it would break that guarantee. Approved versions get a monotonically increasing ID, cached aggressively since the same handful of schema IDs are looked up on nearly every message serialize/deserialize across the company. A coordination service keeps compatibility-mode config consistent across registry nodes so two nodes can never disagree about whether a given change is safe.

Design the shared rate-limiting layer that every microservice in a company calls before doing expensive or externally-billed work, enforcing a distinct quota per tenant, per API, that has to stay consistent no matter which of hundreds of service instances is asking. A naive per-instance in-memory counter would let a tenant burst well past their quota simply by spreading requests across enough instances - the whole point of a shared mesh is that the limit is enforced globally, not per process. Every quota check is an atomic operation against a shared, low-latency counter store keyed by (tenant, API, window) - this is the one component that has to be fast enough to sit on literally every internal service call without becoming the bottleneck itself. Quota plans and overrides (a tenant's negotiated limits) live in a durable store that changes rarely and is read into the hot path only as configuration, never queried per-request.

Design the global entry point that routes a user's request to the nearest healthy region out of dozens spread across the planet, using anycast DNS so the same IP address resolves to a different physical location depending on where the query originates, and continuously monitoring each region's health so a struggling region stops receiving new traffic within seconds, not minutes. This is the layer that sits in front of every other system this platform runs - if it routes someone to a dead region, nothing downstream matters. An anycast-routed DNS layer resolves a user to their nearest point of presence, which fronts a CDN for static content and a regional load balancer for everything dynamic. Each region's web tier reports health continuously; a circuit breaker trips when a region's error rate crosses a threshold, and that region stops being offered as a routing target until it recovers. Regional config and health state are held in a low-latency store so a failover decision doesn't itself become the bottleneck it's trying to route around.

Design the ingestion and rollup pipeline behind a Mixpanel/Amplitude-style analytics product: an SDK embedded in thousands of customer apps fires an event on every user action, and those events have to land durably, power live dashboards within seconds, and remain queryable in full historical detail for ad-hoc analysis - all from the same firehose. The tension is that 'update the live dashboard' and 'preserve every raw event for later SQL' are different workloads with different freshness and durability needs, even though they start from the exact same event. The ingestion API durably archives every raw event immediately - both into a time-series store for metric queries and a warehouse for ad-hoc historical analysis - before anything else happens, so a downstream failure can never lose data that's already been accepted. In parallel, a stream processor consumes the same event flow to maintain live rollups (active users right now, funnel conversion in the last hour) in a fast cache, so dashboard queries never have to scan raw events to render a number that updates every few seconds.

Design the matchmaking system behind an online multiplayer game: a player hits 'find match,' joins a queue, and the system has to group them with players of comparable skill into a balanced lobby as fast as possible, widening the acceptable skill range the longer someone waits so nobody queues forever. Once a match is found, a game session has to be provisioned and every matched player notified - and none of that provisioning work can block the queue itself from continuing to match everyone else. The matchmaking API adds a player to an active queue held in a fast in-memory store keyed by region and skill bracket, checked continuously for viable groups as ratings and wait times shift. The moment a group is found, a match-found event is published rather than provisioning the session inline, so a slow game-server allocation never stalls the matchmaker for everyone still waiting. A background worker consumes that event to spin up the session and push a notification to every matched player, while match outcomes feed back into a durable store of player stats and rating history.

Design the signaling layer behind peer-to-peer voice/video calling (WebRTC): before two devices can exchange audio/video directly with each other, they first have to discover each other, agree on media capabilities, and exchange network connection candidates - none of which flows over the eventual peer-to-peer media path itself. The signaling service is a matchmaker that gets out of the way the moment the call is actually connected. When a client initiates a call, it holds a persistent connection to a signaling server and sends an SDP offer describing its media capabilities; the server relays it to the callee, who replies with an SDP answer relayed back the same way. Both sides then trickle ICE candidates - possible network paths - through the same relay until a workable direct route is found. A presence/session cache tracks who's online and mid-call in memory, since that state changes constantly and must be checked instantly, while call records land in durable storage only after the fact, for history and billing.

Design the trust & safety pipeline that screens every piece of user-generated content - text, images, video - before or immediately after it goes live, combining fast automated classifiers with a human review queue for anything the model is uncertain about, and a durable appeals process for content creators who dispute a decision. At this volume, a human can't review everything, but nothing can be allowed to spread unchecked while waiting for one either. Every submission is screened synchronously by a classifier for high-confidence violations, blocked immediately if it clearly crosses a bright line. Ambiguous content - the large middle ground a fast classifier can't confidently resolve - is queued for a human reviewer rather than auto-approved or auto-blocked by default, since both of those failure modes carry real cost. Every decision, human or automated, is durably logged with its reasoning so a creator can appeal it, and classifier accuracy/drift is tracked continuously, because a moderation model quietly degrading is far more dangerous than one that fails loudly.

Design a banking-grade transaction system where an account's balance is sharded across multiple independent ledgers for scale, but a single transfer might need to debit an account on one shard and credit an account on another - atomically, with zero tolerance for a transfer that debits one side and never credits the other. This is the two-phase commit (2PC) problem: coordinating a single all-or-nothing outcome across data stores that have no shared transaction boundary. A transaction coordinator receives the transfer request, writes an intent record to a durable commit log before touching either shard, then executes phase one (each shard tentatively reserves its side of the transfer and reports ready) and phase two (the coordinator tells both shards to commit, only once both have confirmed ready). If the coordinator crashes mid-transaction, a recovery worker replays the commit log on restart, using it to determine exactly which transactions were left in an uncertain state and resolve them - not necessarily by guessing.

Design the ingestion platform behind a utility's smart meter network: millions of meters report usage readings continuously, the grid operator needs a near-real-time view of aggregate demand to balance load, and a meter that suddenly stops reporting is a signal - either a device fault or, at scale, the first sign of an outage - that has to surface as an alert within minutes, not be discovered from a customer complaint. Meter readings flow through an ingestion API into a durable stream, since losing billing-relevant usage data is unacceptable. A stream processor continuously aggregates readings into a live view of demand by grid segment, feeding both a fast cache for operator dashboards and a time-series store for historical load analysis. A separate consumer of the same stream watches for meters that have gone quiet against their expected reporting interval and raises an outage/fault alert - deliberately decoupled from the demand-aggregation path, since a spike in outage detection work should never degrade the operator's live load view.

Design a FHIR-style interoperability platform that lets hospitals, clinics, labs, and pharmacies exchange patient records in a standard format, where every single access - read or write - has to be checked against that specific patient's consent grants before anything happens, and every failure to sync a record between systems has to surface for compliance review rather than disappear. Healthcare data exchange has all the normal distributed-systems problems plus a hard legal requirement layered on top: an unauthorized access isn't just a bug, it's a reportable incident. An interop service exposes a standard API to partner systems; every request first passes through a consent/redaction check that filters the response (or blocks the write) according to what that specific patient has actually authorized that specific requester to see. Approved record changes are queued for asynchronous propagation to every other system that holds a copy of that patient's data, since a hospital's system being temporarily unreachable can't be allowed to block the clinic that's trying to record a same-day update. Anything that fails to sync is dead-lettered for compliance review, not silently dropped.

Design the cart-to-order path behind a global e-commerce platform: a shopper adds items over minutes or days, prices and promotions can shift under them, and the final checkout has to lock in a price, charge one of several supported payment methods, and hand off to fulfillment - without ever double-charging a card, losing a cart, or confirming an order the payment didn't actually clear for. Checkout is the one flow on the entire platform where correctness is worth more than raw throughput. The cart itself lives in a fast store since it's read and mutated on nearly every page view but only actually checked out a small fraction of the time. At checkout, the API locks the current price for every line item, persists an order record in a pending state, and calls a payment orchestrator that can route to whichever provider is configured for that payment method - synchronously, since checkout must know the outcome before confirming anything to the shopper. Only after payment confirms does the order transition to confirmed and publish an event that fans out to fulfillment, inventory, and the customer notification path, each processing independently and none blocking the others.

Design a streaming speech-to-speech translation system for live conversation: one person speaks, and a translated voice has to reach the other participant quickly enough to feel like a real conversation rather than a series of delayed messages. Unlike text translation, this pipeline chains speech recognition, machine translation, and speech synthesis - three model inference stages back to back - over an open, continuous audio stream rather than a single request/response call. Each participant holds a persistent streaming connection to a session server, which pipes audio chunks through the model pipeline and streams translated audio back as it becomes available, rather than waiting for the whole utterance to finish. A per-session context store maintains recent conversation history and a running glossary so domain-specific or previously-used terms translate consistently instead of drifting sentence to sentence. A phrase cache shortcuts common greetings and stock phrases straight to a cached translation, skipping the full model pipeline for the cases where it's pure overhead.

Design a Vault-style secrets management service: every microservice in the company fetches its database passwords, API keys, and certificates from here instead of a config file, secrets rotate automatically on a schedule, and every single read is durably audit-logged - because 'who accessed this secret and when' is a question that has to have a real answer during a security incident, not a guess. This is infrastructure where the availability requirement and the security requirement pull in the same direction for once: if this service is down, every other service that depends on it for credentials is effectively down too. A request for a secret is authenticated and authorized before anything else happens, then served from a short-lived lease cache when possible so the encrypted durable store isn't hit on every single request across the company. A distributed coordination layer manages unsealing and leader election, since only an active leader may serve decryption operations. A scheduler drives automatic credential rotation on a per-secret cadence, and every read - successful or denied - is written to an append-only audit log that itself is a first-class, permanent artifact of the system, not an afterthought.

Design the tracking backbone behind a global logistics network: a shipment moves through dozens of scan events - picked up, arrived at a hub, loaded onto a truck, customs-cleared, out for delivery - across carriers and countries, and the platform has to maintain a live, continuously-recalculated ETA while surfacing delays to both customers and operations before a human notices something's wrong. The routing itself is a graph problem: a shipment's remaining path through the network is a sequence of hops, each with its own transit-time distribution. Scan events stream in from carrier integrations and internal handling systems through an ingestion API. A stream processor consumes that stream continuously, updating each shipment's position in a route graph and recalculating its ETA against live transit-time data, while every raw scan event is also durably archived for the full audit trail a customs or customer dispute might need. A separate consumer of the same event stream watches for shipments whose gap between expected and actual scan events has grown too large and raises a delay alert - independent of the ETA-recalculation path, so a backlog in one never stalls the other.

This is the second capstone - the culmination of everything taught across Act 9 and Act 10. Design a planet-scale 'super-app' that unifies commerce, payments, social messaging, and AI-driven personalization into one coherent platform serving hundreds of millions of users: browsing a product feed shaped by a recommendation index, chatting with a seller in real time, checking out with an orchestrated payment, and having that content screened for policy violations before it ever reaches another user - all as one integrated system, not a pile of disconnected features. Global traffic resolves through anycast DNS to the nearest edge, where a CDN absorbs static content while everything dynamic flows through a load-balanced API gateway into a stateless application tier. That tier fans out to a relational store for transactional data, a NoSQL store for the social graph and feed, a vector index for recommendations, and a payment orchestrator for checkout - while a parallel real-time tier handles persistent chat connections. Every write of consequence flows through an event bus so downstream consumers - order fulfillment, notifications, content moderation - process independently and asynchronously, with nothing lost to a dead letter queue silently. This is the test of whether you can compose everything you've learned into one architecture that actually holds together.