The definitive architecture roadmap for software engineers. Master the high-level design rounds at Google, Meta, and Netflix with these 30 essential questions.
If you've applied for a senior or staff software engineer role at top-tier firms like Google, Meta, or Netflix in the last two years, you know the stakes. The system design interview is no longer just about drawing boxes and connecting them with arrows. In 2026, it's a high-stakes simulation of real-world engineering trade-offs.
This round is arguably the single highest-leverage part of your interview sequence. A strong performance doesn't just get you an offer — it determines your level (L5 vs L6), your scope, and your starting compensation package.
The 20% of effort that drives 80% of results. Use this structured approach for every system design question.
Problem Statement
Design a service that takes a long URL and returns a short, unique alias that redirects to the original URL when visited — similar to bit.ly or TinyURL.
Requirements
| Functional | Non-Functional |
|---|---|
| • Generate unique short URL from long URL | • High availability |
| • Redirect short URL to original | • Low latency redirects (<100ms) |
| • Optional: Custom aliases, expiration, analytics | • Unique non-guessable URLs |
| • Scale to billions of URLs |
Capacity Estimation
| 100M new URLs/month → ~40 writes/sec |
| 100:1 read/write ratio → ~4,000 reads/sec |
| Storage: ~3 TB over 5 years |
Core Components & Database
| Core Components | Database Choice |
|---|---|
Load BalancerStateless App ServersRedis CacheID GeneratorNoSQL/SQL DB | Key-Value Store (DynamoDB, Cassandra) - pure key lookup, scales horizontally. |
Scaling & Bottlenecks
| ↑ Scaling Strategy | ⚠ Bottlenecks & Solutions |
|---|---|
| • Cache hot URLs aggressively (Pareto principle) | • Centralized counter bottleneck → Use distributed ID generation |
| • Shard DB by hash of the short code | • Cache stampede on popular links → Use request coalescing |
| • Distributed ID generator (Snowflake) |
Architect's Summary
“Stateless service with cache-first read path, sharded KV store, and base62-encoded IDs.”
Problem Statement
Design a real-time messaging system supporting 1:1 chat, group chat, delivery guarantees, and presence — at scale (billions of users).
Requirements
| Functional | Non-Functional |
|---|---|
| • Real-time messaging | • Low latency (<200ms) |
| • 1:1 and group chats | • High availability |
| • Delivery status (sent, delivered, read) | • Message durability |
| • Presence (online/offline) | • Scale to 2B+ users |
| • Media sharing |
Capacity Estimation
| 100B messages/day → ~1.16M/sec avg |
| 10TB/day raw text data |
| Millions of concurrent persistent connections |
Core Components & Database
| Core Components | Database Choice |
|---|---|
WebSocket GatewaysPresence ServiceKafka QueuePush Notification ServiceCassandra | Cassandra for messages (time-ordered, high write scale). Redis for presence/routing state. |
Scaling & Bottlenecks
| ↑ Scaling Strategy | ⚠ Bottlenecks & Solutions |
|---|---|
| • Shard gateways by user ID, sticky sessions in Redis | • Presence registry scale → Distributed in-memory store |
| • Partition messages by conversation ID | • Group fan-out spikes → Async worker pools |
| • Async fan-out for group messages | • Ordering guarantees → Per-chat sequence numbers |
Architect's Summary
“WebSocket layer with Redis presence registry, Kafka for fan-out, and Cassandra for message history.”
Problem Statement
Design a system that generates a personalized, scrollable feed of posts from followed accounts, showing media and engagement counts.
Requirements
| Functional | Non-Functional |
|---|---|
| • Post media with captions | • Low latency load (<200ms) |
| • Follow users | • High availability (some staleness OK) |
| • View ranked feed of followed posts | • Read-heavy workload |
| • Like/comment support |
Capacity Estimation
| 500M DAU → ~100K reads/sec peak |
| 100M posts/day → ~1,150 writes/sec |
| 25:1 read/write ratio |
Core Components & Database
| Core Components | Database Choice |
|---|---|
Post ServiceFan-out WorkersFeed Cache (Redis)Graph ServiceCDNRanking Service | Cassandra for posts (partitioned by user/post ID). Redis for sorted-set feed lists. |
Scaling & Bottlenecks
| ↑ Scaling Strategy | ⚠ Bottlenecks & Solutions |
|---|---|
| • Hybrid push/pull fan-out to solve celebrity problem | • Celebrity fan-out explosion → Use pull-based model |
| • CDN for global media delivery | • Ranking overhead → Precomputed scores updated async |
| • Async ranking scorers | • Viral post hot keys → Multi-tier caching |
Architect's Summary
“Hybrid fan-out architecture with Redis-cached precomputed feeds and ML-based ranking layers.”
Problem Statement
Design a video platform for massive upload, transcoding, global streaming, and engagement (comments/search).
Requirements
| Functional | Non-Functional |
|---|---|
| • Upload videos | • Durability for video bytes |
| • Transcode to multiple renditions | • Low playback start time |
| • Adaptive bitrate streaming | • Massive storage/bandwidth scale |
| • Search & engagement | • Availability |
Capacity Estimation
| 500 hrs upload/min |
| Billions of daily views |
| Data multiplication (3-5x) for renditions |
Core Components & Database
| Core Components | Database Choice |
|---|---|
Upload ServiceTranscoding WorkersObject Store (S3)CDNElasticsearchMetadata DB | Object Storage for video files. Relational/Document DB for metadata. Wide-column store for view counts. |
Scaling & Bottlenecks
| ↑ Scaling Strategy | ⚠ Bottlenecks & Solutions |
|---|---|
| • Offload 90%+ traffic to CDN edge | • Transcoding latency → Segmented parallel workers |
| • HLS/DASH for adaptive playback | • Storage cost → Cold storage for rare renditions |
| • Chunk-based parallel transcoding | • Viral thundering herd → Multi-tier CDN caching |
Architect's Summary
“Queue-driven transcoding pipeline feeding object stores distributed through global CDN nodes.”
Problem Statement
Design a subscription-based VOD platform with global delivery, personalized recommendations, and multi-region resilience.
Requirements
| Functional | Non-Functional |
|---|---|
| • Browse catalog | • Extreme availability (active-active) |
| • Adaptive streaming | • Zero-buffering startup |
| • Resume across devices | • Graceful degradation |
| • Personalized recommendations | • Subscription consistency |
Capacity Estimation
| Millions of concurrent streams |
| Tbps aggregate bandwidth |
| Catalog is smaller but deeply transcoded |
Core Components & Database
| Core Components | Database Choice |
|---|---|
Control Plane APIOpen Connect CDNRecommendation EnginePlayback ServiceBilling | Relational for Billing. Cassandra for viewing history/resume. Precomputed ML indices for recs. |
Scaling & Bottlenecks
| ↑ Scaling Strategy | ⚠ Bottlenecks & Solutions |
|---|---|
| • Proactive content placement (pre-caching) | • Edge prediction → Demand forecasting models |
| • Active-active multi-region failover | • Recs freshness → Batch/Streaming hybrid pipelines |
| • Chaos engineering (Simian Army) | • Regional outage → Automated traffic shifting |
Architect's Summary
“ISP-embedded CDN data plane with a resilient microservices control plane and proactive caching.”
Problem Statement
Design a ride-sharing dispatch system matching riders with drivers in real-time with location tracking and surge pricing.
Requirements
| Functional | Non-Functional |
|---|---|
| • Match rider with nearby driver | • Low latency matching |
| • Real-time location tracking | • High geo-availability |
| • Fare estimation / Surge pricing | • Trip state consistency |
| • Trip lifecycle | • Scale to millions of trips |
Capacity Estimation
| 1.25M location writes/sec (peak) |
| High volume ephemeral coordinates |
| Regional partitioning |
Core Components & Database
| Core Components | Database Choice |
|---|---|
Location ServiceGeospatial Index (Redis)Matching EngineTrip ServicePricing Engine | Redis for live driver locations. Relational DB for trips/payments. Time-series for surge analytics. |
Scaling & Bottlenecks
| ↑ Scaling Strategy | ⚠ Bottlenecks & Solutions |
|---|---|
| • Partition index by city/cell | • Naive proximity scan → Use Geohashing/Quadtree |
| • Geohash lookups for fast grid proximity | • Write volume → Shard by region in memory |
| • Decouple ingestion from matching | • Fair matching → Short-lived distributed locks |
Architect's Summary
“Geohash-partitioned location registry with real-time matching and city-bounded service clusters.”
Problem Statement
Design a microblogging platform where users post short messages ('tweets'), follow other users, and view a timeline.
Requirements
| Functional | Non-Functional |
|---|---|
| • Post tweets | • High read throughput |
| • Follow/unfollow users | • Low latency timeline loads |
| • Home timeline (Reverse-chrono) | • Eventual consistency for trends |
| • Trending topics / Search | • Scale to hundreds of millions |
Capacity Estimation
| 300M+ MAU |
| ~500M tweets/day → ~6K writes/sec |
| Timeline reads dominate (~17K/sec) |
Core Components & Database
| Core Components | Database Choice |
|---|---|
Tweet ServiceFan-out WorkersTimeline CacheGraph ServiceTrending Stream Processor | Cassandra for tweets. Redis for timelines. Graph store for follows. |
Scaling & Bottlenecks
| ↑ Scaling Strategy | ⚠ Bottlenecks & Solutions |
|---|---|
| • Hybrid fan-out (Identical to Instagram) | • Celebrity fan-out → Hybrid push/pull |
| • Stream-process firehose for trends | • Real-time trends → Approximate streaming algorithms |
| • Shard follow graph by UserID | • Timeline merge latency → Partial precomputation |
Architect's Summary
“Hybrid fan-out timelines with a streaming firehose processor for global trending topic detection.”
Problem Statement
Design a personalized, ranked news feed aggregating posts from friends, pages, and groups.
Requirements
| Functional | Non-Functional |
|---|---|
| • Aggregate from Friends/Pages | • Low latency despite ranking |
| • Rank by relevance/engagement | • High availability (staleness OK) |
| • Like/Comment/Share | • Scale to billions of users |
| • Real-time-ish updates | • Personalized compute |
Capacity Estimation
| Billions of users |
| Multiplicative fan-out scale |
| High ML inference volume |
Core Components & Database
| Core Components | Database Choice |
|---|---|
Candidate GeneratorRanking ServiceFeature StoreSocial Graph StoreFeed Assembly | Wide-column for posts. Graph store for social graph. Low-latency Feature store for ML signals. |
Scaling & Bottlenecks
| ↑ Scaling Strategy | ⚠ Bottlenecks & Solutions |
|---|---|
| • Separate generation from ranking | • Inference cost → Bounded set ranking |
| • Precompute features async | • Feature freshness → Hybrid batch/streaming |
| • Cached candidate sets | • Graph traversal → Cached projections |
Architect's Summary
“ML-ranked feed generated via cheap candidate retrieval and bounded-set inference scoring.”
Problem Statement
Design a distributed, in-memory caching system storing key-value pairs across multiple nodes.
Requirements
| Functional | Non-Functional |
|---|---|
| • Get/Set/Delete | • Sub-millisecond latency |
| • TTL expiration | • High availability |
| • Even distribution | • Horizontal scale |
| • Eviction (LRU/LFU) | • Fast node failover |
Capacity Estimation
| Millions of keys |
| Hundreds of thousands ops/sec per node |
| Memory-bound shards |
Core Components & Database
| Core Components | Database Choice |
|---|---|
Cache Client/ProxyCache NodesCluster Coordinator (Gossip/etcd)Replica Sets | Custom in-memory hash table per node. |
Scaling & Bottlenecks
| ↑ Scaling Strategy | ⚠ Bottlenecks & Solutions |
|---|---|
| • Consistent hashing to minimize reshuffle | • Hot keys → Key-level replication |
| • Virtual nodes for load balancing | • Rebalance spikes → Throttled reshuffling |
| • Read replicas per shard | • Cache stampede → Request coalescing |
Architect's Summary
“Consistent-hashed in-memory cluster with virtual nodes and gossip-based membership tracking.”
Problem Statement
Design a system that sends notifications (push, email, SMS) triggered by various platform events.
Requirements
| Functional | Non-Functional |
|---|---|
| • Push/Email/SMS/In-app | • High throughput |
| • User preference center | • At-least-once delivery |
| • Templating | • Low latency for OTPs |
| • Delivery tracking | • Provider rate respect |
Capacity Estimation
| 50M+ events/day |
| Multi-channel fan-out |
| Third-party rate limited |
Core Components & Database
| Core Components | Database Choice |
|---|---|
Message Queue (Kafka)Notification ServicePreference StoreTemplating EngineDispatch Workers | Relational for Preferences. Wide-column for delivery logs. |
Scaling & Bottlenecks
| ↑ Scaling Strategy | ⚠ Bottlenecks & Solutions |
|---|---|
| • Decouple via queues | • Provider rate limits → Backpressure |
| • Parallelize consumption | • Retries → Idempotency |
| • Per-channel rate limiters | • Preference lookup latency → Local cache |
| • Batching for digests |
Architect's Summary
“Queue-driven consumer architecture with preference filtering and rate-limited channel dispatchers.”
Problem Statement
Design a low-latency system that suggests query completions as a user types into a search box.
Requirements
| Functional | Non-Functional |
|---|---|
| • Top-K matching suggestions | • Every-keystroke latency (<50ms) |
| • Ranked by popularity | • High availability |
| • Personalization / Trending support | • Freshness/Popularity balance |
Capacity Estimation
| 20B autocomplete requests/day |
| 10x search volume |
| Read-heavy throughput |
Core Components & Database
| Core Components | Database Choice |
|---|---|
Aggregation DBTrie BuilderIn-memory Trie ServiceTrending OverlayClient Debouncer | In-memory Trie structure. AggregatedLogs in KV store. |
Scaling & Bottlenecks
| ↑ Scaling Strategy | ⚠ Bottlenecks & Solutions |
|---|---|
| • Shard Trie by prefix range | • Real-time trending → Hybrid batch/streaming |
| • Precompute Top-K per node | • Memory footprint → Prune rare prefixes |
| • Cache popular prefixes at Edge | • High volume → Debouncing |
| • Client-side debouncing |
Architect's Summary
“Sharded in-memory prefix Trie with precomputed popularity scores and a fast trending overlay.”
Problem Statement
Design a persistent group chat platform supporting large channels, history, and real-time delivery.
Requirements
| Functional | Non-Functional |
|---|---|
| • Large channels | • Low latency busy channels |
| • Real-time delivery | • Durability |
| • History pagination | • Channel fan-out scale |
| • Typing/Presence | • Consistency |
Capacity Estimation
| Millions of concurrent connections |
| Large channel fan-out spikes |
| History volume |
Core Components & Database
| Core Components | Database Choice |
|---|---|
WebSocket GWRedis Pub/SubMessage ServiceMembership ServiceCassandra | Cassandra for history. Relational for Roles/Members. Redis for Presence. |
Scaling & Bottlenecks
| ↑ Scaling Strategy | ⚠ Bottlenecks & Solutions |
|---|---|
| • Partition pub/sub topics | • Mega-channel fan-out → Regional fan-out |
| • Tiered fan-out for mega-channels | • Typing indicators → Ephermal traffic |
| • Cursor-based history pagination | • Ordering → Sequence numbers |
Architect's Summary
“WebSocket gateways with Pub/Sub topics per channel, decoupled from partitioned wide-column storage.”
Problem Statement
Design a system that limits requests per client to protect backend services from abuse.
Requirements
| Functional | Non-Functional |
|---|---|
| • Enforce N requests/T timeframe | • Minimal latency addition |
| • Multi-tier limits | • Distributed enforcement |
| • 429 feedback | • High availability |
| • Accuracy vs Perf |
Capacity Estimation
| Sum of platform throughput |
| Negligible latency budget |
| Low memory per client |
Core Components & Database
| Core Components | Database Choice |
|---|---|
Rate Limit MiddlewareRedis Counter StoreAPI Gateway integration | Redis (Atomic increments with TTL). |
Scaling & Bottlenecks
| ↑ Scaling Strategy | ⚠ Bottlenecks & Solutions |
|---|---|
| • Sliding window algorithm | • Redis hotspot → Sharding |
| • Shard Redis by ClientID | • Window boundary burst → Sliding window |
| • Check at Gateway | • Clock skew → Centralized time |
Architect's Summary
“Redis-backed sliding window counter enforced at the gateway with shard-based scaling.”
Problem Statement
Design a single entry point for microservices handling routing, auth, and resilience.
Requirements
| Functional | Non-Functional |
|---|---|
| • Routing | • Minimal latency |
| • Auth/Authz | • No SPOF |
| • Rate limiting | • Horizontal scale |
| • Transformations | • Circuit breakers |
Capacity Estimation
| Aggregate platform traffic |
| Sub-10ms latency |
Core Components & Database
| Core Components | Database Choice |
|---|---|
Gateway NodeService RegistryAuth CacheCircuit Breakers | N/A (Stateless). Uses Redis for transient keys. |
Scaling & Bottlenecks
| ↑ Scaling Strategy | ⚠ Bottlenecks & Solutions |
|---|---|
| • Horizontally scaled fleet | • SPOF risk → Redundancy |
| • Local auth caching | • Auth latency → Local caching |
| • Dynamic service discovery | • Successive failure → Circuit breaking |
Architect's Summary
“Horizontally-scaled stateless routing fleet with circuit breakers and cached authentication.”
Problem Statement
Design a global system to deliver static content from edge locations near users.
Requirements
| Functional | Non-Functional |
|---|---|
| • Geo-edge caching | • Low global latency |
| • Origin fallback | • Regional resilience |
| • Invalidation/Purge | • Origin offload |
| • Media support | • High bandwidth |
Capacity Estimation
| 90%+ hit rate |
| Geo-distributed PoPs |
| Origin shielding |
Core Components & Database
| Core Components | Database Choice |
|---|---|
Edge PoPsRegional CacheOrigin ShieldGeo-DNSPurge Pipeline | Local disk/SSD caches at Edge. |
Scaling & Bottlenecks
| ↑ Scaling Strategy | ⚠ Bottlenecks & Solutions |
|---|---|
| • Multi-tier hierarchy | • Invalidation lag → Pub/sub propagation |
| • Pull vs Push caching | • Cold start spike → Origin shielding |
| • Anycast routing | • Geo skew → Dynamic routing |
Architect's Summary
“Multi-tier geo-distributed edge caching network with DNS-based routing and origin shielding.”
Problem Statement
Design a massive scale system to browse, download, and index the web while respecting politeness.
Requirements
| Functional | Non-Functional |
|---|---|
| • URL discovery | • Billions of pages scale |
| • Content storage | • Politeness per domain |
| • Recrawl logic | • Fault tolerance |
| • robots.txt respect | • Freshness prioritisation |
Capacity Estimation
| Billions of URLs in frontier |
| Petabytes of raw content |
| 380+ pages/sec avg |
Core Components & Database
| Core Components | Database Choice |
|---|---|
URL FrontierFetcher WorkersDeduplication (Bloom Filter)Link ParserContent Storage | Bloom Filters + KV for seen URLs. Object Store for content. |
Scaling & Bottlenecks
| ↑ Scaling Strategy | ⚠ Bottlenecks & Solutions |
|---|---|
| • Domain-based partitioning for politeness | • Politeness rate-limiting → Domain partitioning |
| • Bloom filter for memory-efficient dedup | • Duplicate content → Content hashing |
| • Asynchronous fetchers | • DNS bottleneck → Aggressive caching |
Architect's Summary
“Domain-partitioned priority frontier with Bloom-filter deduplication and polite fetcher workers.”
Problem Statement
Design a system for multi-level parking spot allocation, ticketing, and payment.
Requirements
| Functional | Non-Functional |
|---|---|
| • Spot tracking by type | • Physical safety |
| • Ticketing on entry | • Low latency |
| • Payment on exit | • Strong consistency (no double-alloc) |
| • Real-time availability | • Correctness |
Capacity Estimation
| Manageable QPS |
| Strong transactional requirements |
| Local lot independence |
Core Components & Database
| Core Components | Database Choice |
|---|---|
Gate ControllersAllocation ServiceTicketing EngineAggregation Service | Relational DB for Transactions. Cache for global availability view. |
Scaling & Bottlenecks
| ↑ Scaling Strategy | ⚠ Bottlenecks & Solutions |
|---|---|
| • Keep allocation transactions local to Lot | • Allocation Race conditions → Transactional locking |
| • Optimistic locking on spot records | • Sensor lag → Periodic reconciliation |
| • Aggregated availability for customer app | • OOD edge cases |
Architect's Summary
“Object-oriented spot management with transactional allocation and local lot consistency.”
Problem Statement
Design a system for event booking that handles extreme spikes and prevents double-booking seats.
Requirements
| Functional | Non-Functional |
|---|---|
| • Browse seats | • Strict seat consistency |
| • Temporary seat holds | • Spike resilience |
| • Payment & Confirmation | • Low latency browsing |
| • Waiting rooms | • Transactionality |
Capacity Estimation
| Hundreds of thousands on-sale |
| Extreme short-duration spikes |
| Inventory-locked |
Core Components & Database
| Core Components | Database Choice |
|---|---|
Seat Map ServiceHold Service (Redis)Virtual Waiting RoomPayment IntegrationInventory DB | Relational (ACID) for final bookings. Redis for TTL-based temporary holds. |
Scaling & Bottlenecks
| ↑ Scaling Strategy | ⚠ Bottlenecks & Solutions |
|---|---|
| • Virtual waiting room (Queue) for spikes | • On-sale thundering herd → Waiting room pattern |
| • Partition inventory by EventID | • Popular seat lock contention → Row-level locking |
| • Short-TTL holds to free inventory | • Abandoned holds → Auto-release TTLs |
Architect's Summary
“ACID seat inventory with TTL-based Redis holds and a virtual waiting room for spike control.”
Problem Statement
Design a highly reliable, secure system for processing financial transactions with external banks.
Requirements
| Functional | Non-Functional |
|---|---|
| • Authorize & Capture | • Extreme correctness |
| • Refunds/Chargebacks | • High availability (Fail-safe) |
| • History & Status | • Auditability |
| • Compliance | • Security (PCI) |
Capacity Estimation
| External dependency bound |
| Sequential transition state machine |
Core Components & Database
| Core Components | Database Choice |
|---|---|
Payment OrchestratorIdempotency ServiceTokenization (Vault)Immutable LedgerBank Adapters | Relational DB with ACID. Append-only ledger table for audit. |
Scaling & Bottlenecks
| ↑ Scaling Strategy | ⚠ Bottlenecks & Solutions |
|---|---|
| • Mandatory idempotency keys for loops | • Bank latency → Async polling/Webhooks |
| • Async reconciliation against bank statements | • Network retries → Idempotency enforcement |
| • Processor circuit breakers | • Data discrepancy → Scheduled reconciliation |
Architect's Summary
“State-machine orchestration with immutable ledgers and mandatory idempotency for every transaction link.”
Problem Statement
Design the backend for massive product browsing, cart management, inventory, and checkout.
Requirements
| Functional | Non-Functional |
|---|---|
| • Catalog search/browse | • High read throughput (Browse) |
| • Cart & Inventory | • Strong consistency (Inventory) |
| • Checkout & Payment | • Spike resilience |
| • Order management | • Availability |
Capacity Estimation
| Read-heavy browse (95%) vs Write-heavy checkout |
| Spiky sale events |
Core Components & Database
| Core Components | Database Choice |
|---|---|
Catalog ServiceSearch Index (ES)Cart ServiceInventory (Locked)Order Workers | Relational/Document for Catalog. Relational (ACID) for Inventory. Elasticsearch for Search. |
Scaling & Bottlenecks
| ↑ Scaling Strategy | ⚠ Bottlenecks & Solutions |
|---|---|
| • Cache product pages (CDN) | • Overselling → Inventory reservations |
| • Short-TTL inventory reservation | • Flash sale spikes → Virtual queueing |
| • Async post-order workflows | • Search relevance → Async indexing |
Architect's Summary
“Cachable catalog/search path decoupled from transaction-critical inventory and checkout microservices.”
Problem Statement
Design a platform connecting consumers, restaurants, and drivers with real-time tracking.
Requirements
| Functional | Non-Functional |
|---|---|
| • Menu management | • Three-party coordination |
| • Order placement & acceptance | • Low latency tracking |
| • Driver matching | • Regional availability |
| • Real-time ETA | • Spike resilience |
Capacity Estimation
| Meal-time spikes |
| Location-heavy ingest |
| Market partitioning |
Core Components & Database
| Core Components | Database Choice |
|---|---|
Menu ServiceOrder State MachineGeospatial MatchingETA ML EngineTracking Service | Relational for Orders/Payment. Redis Geo for Live Drivers. Document store for Menus. |
Scaling & Bottlenecks
| ↑ Scaling Strategy | ⚠ Bottlenecks & Solutions |
|---|---|
| • Partition by city market | • Predictable spikes → Proactive scaling |
| • Scheduled auto-scaling for meal-time spikes | • State sync → Unified state machine |
| • Geohash matching | • ETA accuracy → ML calibration |
Architect's Summary
“Geospatial-matching dispatch combined with a robust order-state-machine and predictive ETA engine.”
Problem Statement
Design cloud storage for file sync, sharing, and versioning across billions of files.
Requirements
| Functional | Non-Functional |
|---|---|
| • Upload/Download | • High durability |
| • Multi-device Sync | • Permission consistency |
| • Permissions/Sharing | • Efficiency (Diff-sync) |
| • Versioning | • Exabyte scale |
Capacity Estimation
| Billions of metadata records |
| Exabytes of raw bytes |
| Massive storage growth |
Core Components & Database
| Core Components | Database Choice |
|---|---|
Block ChunkerMetadata ServiceSync EngineObject StoreNotification Channel | Object store for blocks. Relational/Document for metadata. |
Scaling & Bottlenecks
| ↑ Scaling Strategy | ⚠ Bottlenecks & Solutions |
|---|---|
| • Block-level deduplication | • Large file bandwidth → Block chunking |
| • Diff-based sync (rsync style) | • Permission latency → Cached ACL checks |
| • Shard metadata by UserID | • Conflict handling → Versioning |
| • Push notifs for sync alerts |
Architect's Summary
“Block-chunked object storage with metadata-mapped versioning and efficient diff-based sync.”
Problem Statement
Design a file sync service focusing deeply on the client-side protocol and conflict resolution.
Requirements
| Functional | Non-Functional |
|---|---|
| • Local change detection | • Bandwidth efficiency |
| • Remote sync alerts | • Data safety |
| • Conflict resolution | • Offline support |
| • Selective sync | • Durability |
Capacity Estimation
| Client-side index metadata |
| High local-scan volume |
| Versioning growth |
Core Components & Database
| Core Components | Database Choice |
|---|---|
OS File WatcherLocal Sync DBServer MetadataBlock storageConflict Handler | Local SQLite for sync index. Server-side Object Store and Metadata DB. |
Scaling & Bottlenecks
| ↑ Scaling Strategy | ⚠ Bottlenecks & Solutions |
|---|---|
| • Client-side event watching | • Sync bandwidth → Diff-based blocks |
| • Version vectors for conflict detection | • Conflict logic → Version-forking |
| • Selective sync folders | • Large file scan → Local index |
| • Debounced sync batches |
Architect's Summary
“Client-side state-indexed sync protocol with block-level delta transfers and version-forking conflict resolution.”
Problem Statement
Design a system that provides mutual exclusion across a distributed cluster of nodes.
Requirements
| Functional | Non-Functional |
|---|---|
| • Acquire/Release lock | • Linearizability (Strong Consistency) |
| • Lock timeout/TTL | • High availability |
| • Wait/TryLock support | • Fault tolerance |
| • Fencing tokens | • Low latency acquisition |
Capacity Estimation
| High throughput for lock ops |
| Low state footprint |
| Safety under network partition |
Core Components & Database
| Core Components | Database Choice |
|---|---|
Lock ClientConsensus Cluster (etcd/Zookeeper)Heartbeat ServiceFencing Token Gen | Strongly consistent KV store (etcd/Zookeeper/Chubby). |
Scaling & Bottlenecks
| ↑ Scaling Strategy | ⚠ Bottlenecks & Solutions |
|---|---|
| • Session-based TTLs | • Leader bottleneck → Shard lock namespaces |
| • Watch/Wait notification instead of polling | • Network partition → Session timeouts / Fencing |
| • Hierarchical locks | • Clock skew → Logical clocks |
Architect's Summary
“Consensus-backed ephemeral key store with heartbeat sessions and fencing tokens.”
Problem Statement
Design a system to collect, index, and search log data from thousands of servers in real-time.
Requirements
| Functional | Non-Functional |
|---|---|
| • Log ingestion | • High ingestion throughput |
| • Search/Filter | • Near real-time search |
| • Aggregation/Dashboards | • Scalable storage |
| • Alerting | • Reliability |
Capacity Estimation
| Hundreds of TBs/day |
| Millions of events/sec |
| Indexing overhead |
Core Components & Database
| Core Components | Database Choice |
|---|---|
Log Agent (Filebeat)Message Queue (Kafka)Transformation (Logstash)Index/Storage (ES)Visualizer (Kibana) | Elasticsearch (Inverted index) for search. Object store for cold logs. |
Scaling & Bottlenecks
| ↑ Scaling Strategy | ⚠ Bottlenecks & Solutions |
|---|---|
| • Shard ES by time-range | • Indexing latency → Batching |
| • Decouple ingestion via Kafka | • Storage cost → Compression & TLM |
| • Async indexing | • Hot shards → Rollover indices |
| • Cold/Warm storage tiers |
Architect's Summary
“Queue-decoupled indexing pipeline feeding a time-sharded inverted index cluster.”
Problem Statement
Design a specialized database for high-volume metric storage (CPU, Mem) with fast range queries.
Requirements
| Functional | Non-Functional |
|---|---|
| • High-write ingest | • Write heavy |
| • Aggregation (Sum/Avg) | • Near real-time queries |
| • Retention policies | • Efficient compression |
| • Downsampling | • Linear scale |
Capacity Estimation
| Millions of points/sec |
| Years of historical data |
| High cardinality tags |
Core Components & Database
| Core Components | Database Choice |
|---|---|
Ingest APIMemTableWALCompactorQuery Engine | Custom TSDB (Prometheus/InfluxDB style). |
Scaling & Bottlenecks
| ↑ Scaling Strategy | ⚠ Bottlenecks & Solutions |
|---|---|
| • Delta-delta compression (Facebook Gorilla) | • Cardinality explosion → Index pruning |
| • Shard by MetricName + TimeRange | • Scan latency → Precomputed aggregations |
| • Async downsampling | • Disk I/O → Heavy compression |
Architect's Summary
“Time-ordered LSM-tree storage with delta-delta compression and async downsampling pipelines.”
Problem Statement
Design a real-time system to count ad clicks for billing and analytics with exactly-once-like guarantees.
Requirements
| Functional | Non-Functional |
|---|---|
| • Count clicks per AdID | • Extreme throughput |
| • Aggregate by Window (Min/Hr) | • Correctness |
| • Fraud detection | • Idempotency |
| • Billing reports | • Low latency aggregation |
Capacity Estimation
| Millions of clicks/sec |
| High partition volume |
| Consistency |
Core Components & Database
| Core Components | Database Choice |
|---|---|
Tracking PixelClick Queue (Kafka)Stream Processor (Flink)Counter Store (Redis)Data Warehouse | Redis for real-time counters. Relational for Billing. Snowflake/BigQuery for Analytics. |
Scaling & Bottlenecks
| ↑ Scaling Strategy | ⚠ Bottlenecks & Solutions |
|---|---|
| • Partition by AdID | • Hot AdID counters → Two-stage aggregation |
| • Exactly-once via idempotency + checkpoints | • Fraud/Duplicate clicks → Probabilistic filters (Bloom/Cuckoo) |
| • In-memory aggregation before write | • Late arrivals → Watermarking |
Architect's Summary
“Exactly-once stream aggregation pipeline with partitioning by AdID and two-stage counting.”
Problem Statement
Design a system that returns a list of nearby venues (restaurants, etc.) based on user location.
Requirements
| Functional | Non-Functional |
|---|---|
| • Search by location/radius | • Low latency search |
| • Venues management | • High availability |
| • Reviews & Ratings | • Read-heavy |
| • Scalability |
Capacity Estimation
| Millions of venues |
| 100K+ search QPS |
| Static-ish venue data |
Core Components & Database
| Core Components | Database Choice |
|---|---|
Search APIGeo Index StoreVenue ServiceReview Service | Relational for Venues. Redis/Elasticsearch with Geo-support for indexing. |
Scaling & Bottlenecks
| ↑ Scaling Strategy | ⚠ Bottlenecks & Solutions |
|---|---|
| • Shard index by Geohash | • Density skew (NYC vs Desert) → Quadtree (dynamic split) |
| • Multi-level caching | • Cold start → Bulk index load |
| • Read-replicas for popular regions | • Static vs Dynamic data partition |
Architect's Summary
“Density-aware Quadtree indexing for venues combined with geo-partitioned read-shards.”
Problem Statement
Design a full-stack system to collect, aggregate, and visualize infrastructure metrics with alerting.
Requirements
| Functional | Non-Functional |
|---|---|
| • Data collection (Push/Pull) | • Extreme reliability (Don't monitor with a system that breaks) |
| • Aggregation | • Low latency query |
| • Alerting | • Scalability |
| • Dashboarding | • Staleness tolerance |
Capacity Estimation
| Millions of metrics/sec |
| Retention periods |
| Cardinality management |
Core Components & Database
| Core Components | Database Choice |
|---|---|
Exporters/AgentsCollector/AggregatorTSDBAlert ManagerGrafana | TSDB (optimized for time-series). KV for Alert settings. |
Scaling & Bottlenecks
| ↑ Scaling Strategy | ⚠ Bottlenecks & Solutions |
|---|---|
| • Sharding by metric name | • Cardinality explosion → Dynamic sampling |
| • Hierarchical aggregation | • Storage bloat → Downsampling |
| • Federation (multi-cluster monitoring) | • Query performance → Pre-computed aggregates |
Architect's Summary
“Hybrid push/pull collection feeding a sharded TSDB with hierarchical aggregation and alerting.”
Problem Statement
Design a system that suggests personalized content or products based on user behavior and preferences.
Requirements
| Functional | Non-Functional |
|---|---|
| • Personalized suggestions | • Latency vs Accuracy trade-off |
| • User behavior tracking | • Scale to millions of users/items |
| • Trending/Popular filters | • Freshness |
| • Diversity |
Capacity Estimation
| Billions of user-item interactions |
| Real-time preference updates |
| Batch model training |
Core Components & Database
| Core Components | Database Choice |
|---|---|
Event TrackerFeature StoreModel Training (Batch)Candidate RetrieverRanking Model (Online) | Vector Database (Milvus/Pinecone) for embeddings. Wide-column for interaction history. |
Scaling & Bottlenecks
| ↑ Scaling Strategy | ⚠ Bottlenecks & Solutions |
|---|---|
| • Approximate Nearest Neighbor (ANN) for candidate retrieval | • Real-time inference → Simple models for ranking |
| • Precompute popular item sets | • Data sparsity → Matrix factorization |
| • Feature-side sharding | • Exploration vs Exploitation → Epsilon-greedy strategies |
Architect's Summary
“Multi-stage vector retrieval and ML-ranking pipeline using offline-trained embeddings and online inference.”
Win the room, not just the whiteboard. These meta-strategies separate L5 from L6 candidates.
| Tip | Details |
|---|---|
| Mastering the Ambiguity | Don't wait for your interviewer to give you constants. Propose them. If you assume 100M active users, explain why. This shows you're ready to lead projects, not just take tickets. |
| Design for Failure | Assume every service will go down. Mention Circuit Breakers, Retries with Exponential Backoff, and Dead Letter Queues without being prompted. |
| No Buzzword Bingo | Never say “I'll use Kafka” just because. Say “I need a message queue to decouple the write-heavy ingest from the slow indexing pipeline.” |
Once you're ready, search for engineering roles that match your updated skills and level.
Browse open jobsMd Rashid
Software engineer and career coach with 6+ years in the tech industry. Writes about interview prep, developer careers, and tech job markets.
The Complete SQL Cheat Sheet 2026
Every SQL command, function, and pattern you need — from basic SELECT queries to advanced window functions, CTEs, indexes, and transactions. Clean, runnable examples for PostgreSQL, MySQL, and SQL Server.
Top 30 Node.js Interview Questions and Answers (2026 Edition)
Ace your next backend interview with this comprehensive guide covering the event loop, streams, clustering, async/await, Express.js, JWT authentication, caching, rate limiting, and graceful shutdown.
Top 30 Most Asked SQL Interview Questions and Answers (2026 Edition)
Master the most asked SQL interview questions and answers for 2026. Covers Joins, CTEs, Window Functions, Normalization, ACID properties, and database design.
The Complete Linux Commands Cheat Sheet 2026
Every essential Linux command defined with clean, practical examples. Covers file navigation, system monitoring, user permissions, networking, package management, and shell scripting.
