System Design Interview Questions for Senior Engineers (2026)

Why System Design Matters in Senior Engineering Interviews

System design interviews are the single most weighted signal for senior and staff engineering candidates at top technology companies. Unlike coding interviews that test algorithmic thinking in isolation, system design rounds evaluate your ability to make architectural decisions under uncertainty, communicate trade-offs clearly, and demonstrate the breadth of experience expected at the senior level.

Interviewers are not looking for a single correct answer. They want to see how you decompose ambiguous problems, how you navigate competing requirements, and whether you can defend your choices with concrete reasoning. A strong system design interview demonstrates that you can own the technical direction of a product area and mentor other engineers through complex architectural decisions.

At companies like Google, Meta, Amazon, and Microsoft, the system design round often carries more weight than any individual coding round for senior-level candidates. Preparing effectively means building a mental library of design patterns, understanding the fundamental trade-offs in distributed systems, and practicing structured communication. For a complete preparation strategy, see our system design interview guide and explore learning paths tailored to senior engineers.

1. How would you design a URL shortening service like Bitly?

What the interviewer is really asking: Can you handle a deceptively simple problem with depth, touching on hashing, storage, caching, analytics, and scale estimation?

Answer framework:

Start by clarifying requirements: read-heavy vs write-heavy ratio (typically 100:1), URL expiration policies, custom aliases, and analytics needs. Estimate scale: if the service handles 100M new URLs per month, that is roughly 40 URLs per second for writes and 4,000 per second for reads.

For the core shortening mechanism, discuss two approaches. First, a counter-based approach using a distributed ID generator like Snowflake IDs that converts the numeric ID to base62. Second, a hash-based approach using MD5 or SHA-256 of the long URL, taking the first 7 characters. Explain why the counter approach avoids collisions entirely while the hash approach requires collision detection.

For storage, a simple key-value store works well. Discuss database design choices: a relational database like PostgreSQL for ACID guarantees or a NoSQL store like DynamoDB for horizontal scalability. Partition by the short URL hash for even distribution.

Add a caching layer using Redis or Memcached in front of the database. Since URLs are immutable once created, cache hit rates will be extremely high (above 90 percent). Use an LRU eviction policy.

For analytics, log every redirect event to Kafka and process with a stream processing framework for real-time click counts, geographic data, and referrer tracking.

Common mistakes: jumping into the solution without clarifying requirements, ignoring the read-heavy nature of the system, and not discussing how to handle custom aliases that might collide with generated short codes.

Follow-up questions:

• How would you handle URL expiration at scale?
• What happens if your ID generator becomes a single point of failure?
• How would you design the analytics pipeline to handle 100x traffic spikes?

2. Design a distributed cache system

What the interviewer is really asking: Do you understand caching at a systems level, not just adding Redis but the actual mechanics of distributed caching, consistency, and eviction?

Answer framework:

Begin with requirements: expected cache size, read/write ratio, latency requirements (sub-millisecond reads), consistency needs (eventual vs strong), and fault tolerance requirements.

For data partitioning, explain consistent hashing in detail. A naive modulo-based approach breaks when nodes are added or removed because most keys get remapped. Consistent hashing limits remapping to K/N keys on average. Add virtual nodes (100-200 per physical node) to ensure even distribution.

Discuss eviction policies with specifics: LRU is the most common but has lock contention issues in concurrent environments. Approximate LRU (like Redis uses with random sampling of 5 keys) reduces contention. LFU works better for workloads with stable hot keys. TTL-based expiration handles temporal data.

For replication, discuss leader-follower replication for read scaling. The leader handles writes, followers handle reads. This introduces a consistency window. Discuss how CAP theorem applies here. For write-heavy workloads, consider sharding over replication.

Address cache stampede (thundering herd): when a popular key expires, hundreds of requests simultaneously hit the database. Solutions include mutex locks (only one request fetches, others wait), probabilistic early expiration (refresh before TTL), and background refresh for hot keys.

Discuss cache-aside vs write-through vs write-behind patterns. Cache-aside is the most flexible (application manages cache), write-through ensures consistency (every write goes to cache and DB), write-behind improves write performance (async DB writes) but risks data loss.

Follow-up questions:

• How do you handle hot keys that overwhelm a single cache node?
• What happens during a network partition between cache nodes?
• How would you implement cache warming for a new deployment?

3. Design a news feed system like Facebook or Twitter

What the interviewer is really asking: Can you reason about fan-out strategies, understand the trade-offs between push and pull models, and handle the complexity of ranked feeds?

Answer framework:

Clarify the type of feed: chronological (simpler) vs ranked (complex, ML-driven). Discuss the two fundamental approaches to feed generation.

Fan-out on write (push model): when a user publishes a post, immediately write it to all followers' feed caches. This gives fast reads (O(1) feed retrieval) but expensive writes. For a user with 10M followers, one post triggers 10M writes. This is how early Twitter worked.

Fan-out on read (pull model): when a user opens their feed, fetch posts from all users they follow, merge, and rank in real-time. This gives fast writes but slow reads, especially for users following thousands of accounts.

The optimal approach is a hybrid, as described in our news feed system design. Use fan-out on write for normal users (pre-compute feeds) and fan-out on read for celebrity users (millions of followers). This is the approach Twitter and Instagram adopted.

For storage, use Redis sorted sets for feed caches (score equals timestamp or ranking score, member equals post ID). Store the actual post content in a separate database and fetch by ID when rendering.

For ranking, discuss feature extraction (post age, engagement signals, author relationship, content type) and a lightweight ML model that scores each candidate post. The ranking service sits between the feed cache and the API response.

Address scalability concerns: feed caches consume massive memory. Limit stored feeds to the most recent 500-1000 posts per user. For older content, fall back to the pull model.

Follow-up questions:

• How would you handle a celebrity with 100M followers posting frequently?
• How do you ensure a newly published post appears immediately in the author's own feed?
• How would you implement seen tracking to avoid showing duplicate content?

4. Design a real-time messaging system like Slack

What the interviewer is really asking: Do you understand persistent connections, presence systems, message ordering, and the unique challenges of real-time communication at scale?

Answer framework:

Start with requirements: real-time message delivery (under 200ms), support for channels with thousands of members, message history search, file sharing, typing indicators, and online/offline presence.

For real-time communication, explain why WebSockets are preferred over HTTP polling. Each client maintains a persistent WebSocket connection to a gateway server. Use a connection registry (Redis) that maps user IDs to gateway server addresses so any service can route messages to the correct gateway.

For message ordering, discuss the challenge: in a distributed system, wall-clock timestamps are unreliable. Use Lamport timestamps or hybrid logical clocks for causal ordering within a channel. For total ordering, use a single-leader approach per channel where one server sequences all messages.

For channel message delivery, when a message arrives: (1) persist to the message store, (2) look up all channel members, (3) for each online member, find their gateway server and push the message, (4) for offline members, increment their unread counter and queue push notifications.

For presence (online/offline status), use a heartbeat mechanism. Clients send heartbeats every 30 seconds. If no heartbeat is received within 90 seconds, mark the user offline. Store presence state in Redis with TTL-based expiration.

For search, index messages in Elasticsearch asynchronously. Partition the search index by workspace to limit search scope and improve query performance.

Discuss message queues for decoupling: use Kafka to buffer messages between the API layer and downstream consumers (notification service, search indexer, analytics).

Follow-up questions:

• How do you handle message delivery when a user switches from offline to online?
• What happens when a gateway server crashes and how do clients reconnect?
• How would you implement end-to-end encryption for direct messages?

5. Design a distributed task scheduler like cron at scale

What the interviewer is really asking: Can you design a reliable system that handles time-based triggers, exactly-once execution, and failure recovery in a distributed environment?

Answer framework:

Clarify requirements: support one-time and recurring tasks, handle millions of scheduled tasks, guarantee at-least-once execution, support task priorities, and provide visibility into task status.

For task storage, use a database with a scheduled execution time index. Partition tasks by their next execution time bucket (per-minute buckets). This allows efficient range queries to find tasks due for execution.

For the scheduling architecture, use a two-tier approach. A set of scheduler nodes continuously poll for tasks due in the next time window. When tasks are found, they are claimed (using optimistic locking or distributed locks via Redis) and dispatched to a pool of worker nodes via a message queue.

Exactly-once execution is the hardest challenge. Discuss the impossibility of true exactly-once in distributed systems, then explain practical approaches: use a distributed lock with a lease timeout so that if a worker crashes, the lock expires and another worker picks up the task. Use idempotency keys so that duplicate executions produce the same result.

For recurring tasks, after successful execution, compute the next execution time from the cron expression and insert a new task record. Handle clock skew across nodes using NTP synchronization and building tolerance into the scheduling window.

Discuss fault tolerance: what happens when a scheduler node crashes? Other scheduler nodes pick up its work since they all poll the same database. What about worker crashes? The lease on claimed tasks expires, and they return to the ready queue.

For observability, track task execution latency, success/failure rates, queue depth, and scheduling delay (difference between scheduled time and actual execution time).

Follow-up questions:

• How would you handle a task that needs to run at exactly midnight across multiple time zones?
• What if a recurring task's execution takes longer than the recurrence interval?
• How would you implement task dependencies where task B runs only after task A completes?

6. Design a content delivery network (CDN)

What the interviewer is really asking: Do you understand how CDNs actually work: PoP architecture, cache hierarchies, origin shielding, and cache invalidation strategies?

Answer framework:

Start with the core problem: serving static and dynamic content to globally distributed users with minimal latency. A CDN places copies of content at edge locations close to users.

For architecture, describe a three-tier hierarchy: edge PoPs (Points of Presence) closest to users, regional mid-tier caches, and the origin server. When a user requests content, DNS resolution directs them to the nearest edge PoP. If the edge has the content (cache hit), it serves immediately. On a cache miss, the edge requests from the mid-tier cache (origin shielding reduces origin load), which in turn fetches from the origin if needed.

Discuss DNS-based routing: use GeoDNS or Anycast to route users to the nearest PoP. GeoDNS maps client IP to geographic location and returns the IP of the closest PoP. Anycast uses BGP routing to naturally direct packets to the nearest PoP.

For cache invalidation, discuss the fundamental challenge: cache invalidation is one of the two hard problems in computer science. Approaches include TTL-based expiration (simple but stale content during TTL), purge APIs (immediate but requires explicit calls), and versioned URLs (append hash to filename, guarantees freshness, no invalidation needed).

Discuss cache key design: the URL alone is often insufficient. Include headers like Accept-Encoding and Accept-Language. Use Vary headers to indicate which request headers affect the response. Be careful with over-specific cache keys that reduce hit rates.

Address dynamic content acceleration: persistent connections between PoPs and origin, TCP optimization (larger initial congestion windows), TLS session resumption, and HTTP/2 multiplexing. Discuss load balancing across origin servers.

For security, discuss DDoS mitigation at the edge (rate limiting, IP reputation), WAF integration, and TLS termination at the edge vs end-to-end encryption.

Follow-up questions:

• How do you handle cache consistency when the origin updates content?
• How would you design the CDN to handle a flash crowd with a sudden 100x traffic spike?
• What metrics would you use to evaluate CDN performance?

7. Design a distributed search engine

What the interviewer is really asking: Do you understand inverted indexes, query processing, ranking algorithms, and the distributed systems challenges of search at scale?

Answer framework:

Break the problem into three phases: indexing, query processing, and ranking.

For indexing, explain the inverted index data structure: a mapping from each term to a sorted list of document IDs containing that term, along with metadata like term frequency and positions. The indexing pipeline: crawl or ingest documents, tokenize, normalize (lowercase, stemming), build inverted index. For scale, partition the index by document ID (document-based partitioning) or by term (term-based partitioning). Document-based is more common because it allows independent indexing and simplifies rebalancing.

For query processing, describe the query flow: parse query, expand terms (synonyms, spell correction), look up each term in the inverted index, intersect posting lists for AND queries, merge for OR queries. For phrase queries, use positional indexes. For distributed query execution, broadcast the query to all index shards, each shard returns its top-K results, and a coordinator merges results.

For ranking, discuss TF-IDF as the baseline: terms that appear frequently in a document (TF) but rarely across documents (IDF) are strong relevance signals. Then discuss modern ranking: BM25 as an improved TF-IDF, learning-to-rank models that combine hundreds of features (text relevance, document quality, freshness, user engagement), and two-phase ranking (cheap model for initial filtering, expensive model for top candidates).

Discuss scalability: each index shard should fit in memory for fast query processing. As the corpus grows, add more shards. Use replication for read scaling where each shard has multiple replicas, and queries are load-balanced across replicas.

Discuss index updates: real-time indexing vs batch indexing. Real-time uses a small in-memory buffer that is periodically merged with the main index. This ensures new documents are searchable within seconds.

Follow-up questions:

• How would you handle queries in multiple languages?
• How do you prevent one slow shard from slowing down every query?
• How would you implement autocomplete and typeahead suggestions?

8. Design a payment processing system

What the interviewer is really asking: Can you build a system where correctness and reliability are paramount, handling distributed transactions, idempotency, and regulatory compliance?

Answer framework:

Start with the unique constraints of payment systems: money cannot be created or destroyed (conservation), every transaction must be traceable (auditability), and failures must be handled gracefully (no double charges, no lost payments).

For the core flow: user initiates payment, payment service validates the request, creates a payment record with PENDING status, calls the payment gateway (Stripe, Adyen), receives result, updates status to SUCCEEDED or FAILED, notifies the user. Each step must be idempotent. Use client-generated idempotency keys so that retrying a request produces the same result.

Discuss the database design for the ledger: use double-entry bookkeeping where every transaction has a debit and a credit entry that must sum to zero. This is the foundation of financial data integrity. Use a relational database with ACID transactions for the ledger since this is one case where eventual consistency is not acceptable.

For fault tolerance, discuss the saga pattern for multi-step transactions. Example: an e-commerce purchase involves reserving inventory, charging the card, and creating the order. If the card charge fails after inventory is reserved, a compensating transaction releases the inventory. Use an orchestrator service that tracks the saga state.

Discuss reconciliation: periodically compare internal records with payment gateway records and bank statements. Flag discrepancies for manual review. This catches bugs, fraud, and edge cases that automated systems miss.

For security: PCI DSS compliance (never store raw card numbers, use tokenization), encryption at rest and in transit, fraud detection ML models that score transactions in real-time, and velocity checks (flag unusual spending patterns).

Address rate limiting and abuse prevention: limit payment attempts per user, implement CAPTCHA for repeated failures, and use device fingerprinting.

Follow-up questions:

• How do you handle a payment that succeeds at the gateway but your system crashes before recording the result?
• How would you design a refund system?
• How do you handle currency conversion in a multi-currency system?

9. Design a ride-sharing service like Uber

What the interviewer is really asking: Can you handle geospatial data, real-time matching, dynamic pricing, and the operational complexity of a marketplace?

Answer framework:

Identify the core services: rider app, driver app, matching service, pricing service, trip service, and payment service. Focus on the matching and geospatial components as the most technically interesting.

For geospatial indexing, discuss how to efficiently find nearby drivers. Options include geohashing (divide the world into grid cells, encode each cell as a string where nearby locations share prefixes), quadtrees (recursively subdivide space, efficient for non-uniform distribution), and S2 geometry (used by Google, maps the sphere to a Hilbert curve for efficient range queries). Store driver locations in an in-memory spatial index that updates every 3-4 seconds as drivers send GPS pings.

For the matching algorithm: when a rider requests a ride, query the spatial index for available drivers within a radius (start with 1km, expand if too few). Rank candidates by ETA (not straight-line distance, use a routing service for actual drive time), driver rating, and acceptance probability. Send the request to the best candidate with a 15-second timeout. If declined, try the next candidate.

For dynamic pricing (surge), monitor supply and demand per geographic zone. When demand exceeds supply by a threshold, apply a multiplier. Use a smoothing function to prevent price oscillation. Publish surge maps so riders can see pricing before requesting.

For the trip lifecycle: request, match, driver en route, pickup, in progress, dropoff, payment, rating. Store trip state in a database and publish state transitions to a message queue for downstream consumers (ETA service, analytics, notifications).

Discuss high availability: the matching service must be available 24/7. Use multiple availability zones, circuit breakers for downstream services, and graceful degradation (if the pricing service is down, use a default price rather than failing the request).

Follow-up questions:

• How would you handle ride matching in a city with complex road networks?
• How do you prevent fraud such as fake rides and GPS spoofing?
• How would you design the system to support ride pooling with shared rides?

10. Design an online collaborative editor like Google Docs

What the interviewer is really asking: Do you understand conflict resolution in real-time collaborative systems, specifically OT or CRDTs, and can you handle the networking and UX challenges?

Answer framework:

The core challenge is concurrent editing: when two users type at the same position simultaneously, how do you ensure both see a consistent document? This is a fundamental problem in distributed systems.

Discuss two approaches to conflict resolution. Operational Transformation (OT): each edit is an operation (insert character at position X, delete character at position Y). When concurrent operations arrive, transform them against each other so the result is the same regardless of application order. Google Docs uses OT. The complexity is in the transformation functions, which must handle all combinations of insert/insert, insert/delete, delete/delete.

CRDTs (Conflict-free Replicated Data Types): design the data structure so that concurrent operations commute automatically with no transformation needed. For text, use a sequence CRDT like YATA or RGA that assigns each character a unique, ordered ID. CRDTs are simpler to reason about and work in peer-to-peer settings, but use more memory. Figma uses CRDTs.

For architecture, use WebSockets for real-time bidirectional communication. A document server maintains the authoritative document state. Clients send operations to the server, which transforms and validates them and broadcasts to all connected clients. For scalability, partition by document so each document is assigned to one server instance that holds its state in memory.

For persistence, periodically snapshot the document to a database. Also store the operation log for undo/redo and version history. Compress old operations by periodically creating checkpoints.

For presence features (cursors, selections), broadcast cursor positions to all users in the document using the same WebSocket channel. Throttle cursor updates to 10-20 per second to reduce network traffic.

Discuss offline editing: queue operations locally and sync when reconnection occurs. CRDTs handle this more naturally than OT.

Follow-up questions:

• How do you handle a document with 1,000 simultaneous editors?
• How would you implement commenting and suggestion mode?
• How do you handle large documents efficiently?

11. Design a monitoring and alerting system like Datadog

What the interviewer is really asking: Can you handle high-volume time-series data ingestion, efficient storage and querying, and build a reliable alerting pipeline?

Answer framework:

Break the system into three components: data ingestion, storage and querying, and alerting.

For data ingestion, agents on each host collect metrics (CPU, memory, disk, custom application metrics) and send them to a collection service. Use UDP for high-frequency metrics where occasional loss is acceptable, and TCP for critical metrics. The collection service buffers metrics and writes in batches. At scale (millions of hosts, each reporting hundreds of metrics per minute), the ingestion rate is billions of data points per minute. Use Kafka as a buffer between collection and storage.

For storage, discuss time-series database design. Data points are (metric_name, tags, timestamp, value). Use time-based partitioning where recent data goes in hot storage (SSD) and older data in cold storage (HDD/S3) with downsampled resolution. Compression techniques: delta encoding for timestamps (most metrics arrive at regular intervals), gorilla encoding for floating-point values (XOR with previous value). These achieve 12:1 compression ratios.

For querying, support aggregations over time ranges: avg, sum, max, min, percentiles. Pre-compute rollups at multiple resolutions (1 second, 1 minute, 1 hour, 1 day) to speed up queries over long time ranges. Use tag-based indexing for fast filtering.

For alerting, define alert rules as queries with thresholds (for example, average CPU above 90 percent for 5 minutes). The alert evaluation engine continuously runs queries against recent data. Use a state machine per alert: OK to PENDING to FIRING to RESOLVED. Require the condition to persist for a configurable duration before firing to prevent flapping.

Discuss fault tolerance for the alerting pipeline: alerting must be the most reliable component. Replicate alert evaluation across multiple nodes. Use consensus to prevent duplicate alerts.

Follow-up questions:

• How do you handle a noisy alert that fires and resolves repeatedly?
• How would you implement anomaly detection without predefined thresholds?
• How do you ensure alerts are delivered even when the monitoring system itself is under heavy load?

12. Design a recommendation engine

What the interviewer is really asking: Do you understand recommendation algorithms, feature engineering, and the system architecture needed to serve recommendations at scale with low latency?

Answer framework:

Discuss the two fundamental approaches. Collaborative filtering: find users similar to the current user and recommend items they liked. Item-based CF is more common in practice because item similarity is more stable than user similarity. Use matrix factorization to decompose the user-item interaction matrix into latent factor vectors.

Content-based filtering: recommend items with attributes similar to items the user has liked. Build item feature vectors from metadata (genre, tags, description) and user profile vectors from their interaction history. Compute similarity using cosine distance.

Modern systems use a hybrid approach with a multi-stage pipeline. Candidate generation (fast, broad): use multiple generators including collaborative filtering, content-based, trending items, and geographic relevance. Each generates hundreds of candidates. Scoring and ranking (slower, precise): a neural network model scores each candidate using hundreds of features. Serving: rank by score, apply business rules (diversity, freshness, ads), and return the top N.

For the training pipeline, discuss event-driven architecture: log user interactions to Kafka, batch processing builds training datasets, model training on GPUs, model validation, model deployment to serving infrastructure.

For real-time personalization, maintain user feature vectors in a cache that updates in near-real-time as users interact. This allows the scoring model to use the latest signals.

Address the cold start problem: for new users, use popularity-based recommendations, ask onboarding preference questions, or use demographic-based recommendations. For new items, use content-based features until enough interaction data accumulates.

Follow-up questions:

• How do you handle the filter bubble problem?
• How would you A/B test recommendation algorithm changes?
• How do you balance relevance with business objectives?

13. Design a global-scale configuration management system

What the interviewer is really asking: Can you build a system that reliably distributes configuration to thousands of services with low latency, handles rollbacks, and prevents bad configs from causing outages?

Answer framework:

Requirements: store configuration key-value pairs per service and environment, propagate changes to all instances within seconds, support rollback, provide audit logging, and prevent bad configurations from causing outages.

For storage, use a strongly consistent data store like etcd or ZooKeeper. Configuration data is small but critical. Strong consistency prevents split-brain scenarios where different instances run with different configs. Store configs as versioned documents: each update creates a new version, enabling instant rollback to any previous version.

For distribution, discuss push vs pull. Push (using watches/subscriptions): clients register interest in specific config keys and receive updates immediately when values change. Low latency but requires persistent connections. Pull (polling): clients periodically fetch their config. Simpler but introduces latency equal to the polling interval. The optimal approach: use push for real-time updates with pull as a fallback safety net.

For safety mechanisms, implement canary deployments for config changes: first apply the change to 1 percent of instances, monitor error rates for 5 minutes, then gradually roll out to 100 percent. Implement config validation: define schemas and validation rules per config key, reject changes that fail validation. Implement kill switches: the ability to instantly revert a config change across all instances.

Discuss fault tolerance: what happens when the config service is unavailable? Clients must cache the last known good configuration locally. On startup, if the config service is unreachable, use the local cache. Include a TTL on the local cache.

Address multi-region concerns: replicate configuration across regions using consensus algorithms. Handle the trade-off between consistency and availability.

Follow-up questions:

• How do you prevent a bad configuration change from taking down the entire fleet?
• How would you handle feature flags as a special case of configuration?
• How do you test configuration changes before deploying them?

14. Design an e-commerce inventory management system

What the interviewer is really asking: Can you handle the consistency challenges of inventory, preventing overselling while maintaining high throughput during flash sales?

Answer framework:

The core challenge is preventing overselling: if 100 units remain and 200 orders come in simultaneously, exactly 100 should succeed and 100 should fail. This requires careful database design and concurrency control.

For the basic approach, use a database row per SKU with an available_quantity column. On purchase: UPDATE inventory SET available_quantity = available_quantity - 1 WHERE sku = ? AND available_quantity > 0. The WHERE clause provides atomic check-and-decrement. This works but creates a hot row bottleneck during flash sales.

For high-throughput scenarios, discuss inventory segmentation: split 10,000 units across 100 virtual buckets (100 units each). Each purchase request is routed to a random bucket, reducing contention by 100x. When a bucket runs out, requests are redirected to other buckets.

Discuss reservation patterns: when a user adds an item to cart, create a soft reservation with a TTL (10 minutes). This prevents the item from being sold while the user completes checkout, but releases it if abandoned. Implement with Redis using key expiration.

For multi-warehouse fulfillment, the system must decide which warehouse fulfills each order based on proximity to the shipping address, warehouse stock levels, and shipping cost.

Address event-driven architecture: publish inventory change events to Kafka for downstream consumers including search index updates, recommendation engine, analytics, and replenishment alerts.

For the caching layer, cache approximate inventory counts for product display pages. Accept slight staleness for display but enforce exact counts at checkout.

Follow-up questions:

• How would you handle a flash sale where 1M users try to buy 1,000 units simultaneously?
• How do you reconcile inventory across online and physical store channels?
• What happens if a payment fails after inventory has been decremented?

15. Design a distributed file storage system like Google Drive

What the interviewer is really asking: Do you understand chunked storage, metadata management, sync protocols, and the consistency challenges of file systems?

Answer framework:

Break the system into metadata management and file storage. The metadata service stores the file hierarchy (folders, files, permissions, sharing) in a relational database. The file storage service handles actual file bytes.

For file storage, split files into fixed-size chunks (for example, 4MB). Each chunk is identified by its content hash (SHA-256). This enables deduplication where identical chunks across different files or users are stored only once. Store chunks in a distributed blob store with 3x replication across different failure domains.

For the sync protocol, discuss the challenge of keeping files consistent across multiple devices. Use a sync engine on each client that maintains a local database of file metadata. On a sync cycle: compare local metadata with server metadata, identify files that changed locally (upload) or remotely (download), detect conflicts (file changed on both sides since last sync).

For conflict resolution, save both versions and let the user choose (like Dropbox). For collaborative editing scenarios, integrate with an OT/CRDT system as discussed in the collaborative editor design.

For scalability, the metadata service is the bottleneck since every operation touches it. Use caching aggressively since file metadata changes infrequently. Shard by user ID.

Discuss bandwidth optimization: delta sync (only upload changed bytes within a chunk), compression before upload, and bandwidth throttling.

Follow-up questions:

• How would you handle a user uploading a 100GB file?
• How do you ensure consistency when the same file is edited on two offline devices?
• How would you implement version history and restore?

Common Mistakes in System Design Interviews

1. Jumping into components without clarifying requirements. Always spend the first 3-5 minutes understanding functional requirements, non-functional requirements, and scale. Ask about DAU, read/write ratio, latency requirements, and consistency needs.

2. Designing for Google scale from the start. A common trap is over-engineering. Start simple, then discuss how to scale specific bottlenecks. Interviewers want to see that you can identify bottlenecks, not that you can add Kafka to every diagram.

3. Ignoring trade-offs. Every design decision has a trade-off. When you choose eventual consistency, acknowledge what you sacrifice. When you add a cache, discuss invalidation challenges.

4. Not doing back-of-the-envelope estimation. Numbers ground your design in reality. Knowing that you need to handle 10,000 QPS vs 10M QPS leads to fundamentally different architectures.

5. Focusing only on the happy path. Senior engineers think about failure modes. Discuss graceful degradation, circuit breakers, and retry strategies.

6. Monologuing without checking in. System design is a conversation. Pause periodically and ask if the interviewer wants you to go deeper on a component.

How to Prepare for System Design Interviews

Develop a structured study plan over 6-8 weeks. Start by building a strong foundation in core distributed systems concepts including consistent hashing, CAP theorem, consensus protocols, and replication strategies.

Study 15-20 canonical system designs in depth. For each, understand the requirements, core architecture, key trade-offs, and failure modes. Practice designing each system from scratch within 35 minutes.

Practice communication: record yourself explaining designs, or practice with a peer. Study real-world architectures through engineering blogs from companies like Google and Meta.

For a comprehensive roadmap, see our system design interview guide and explore the learning paths. If you are targeting staff-level roles, read about the senior to staff engineer transition.

Related Resources

• System Design Interview Complete Guide
• Distributed Systems Fundamentals
• CAP Theorem Deep Dive
• Scalability Patterns
• Learning Paths
• Pricing