System Design Interview Questions: 15+ Real Problems

You are preparing for a system design interview and wondering what questions actually come up. The answer depends on the company, but the question pool is surprisingly small. Most tech companies, from Google and Amazon to German scale-ups like Zalando or Delivery Hero, draw from the same 15 to 20 core problems. They vary the scope, the constraints, and the expected depth, but the underlying problems repeat.

This guide contains 15+ real system design interview questions, grouped by category. For each question, you will learn what the interviewer is really testing, which components you should discuss, what mistakes are common, and which companies typically ask it. At the end, you will find a framework for structuring any 45-minute system design session, plus an overview of how Google, Amazon, and Meta weight their interviews differently.

The 45-Minute Framework for Any System Design Question🔗

Before diving into individual problems, you need a structure that works for every question. Interviewers evaluate not just your solution but how you arrive at it. The following five phases have become the industry standard.

Phase 1: Clarify Requirements (5 Minutes)🔗

Ask questions before you draw. Clarify the functional requirements: What features should the system have? What is the most important use case? Then the non-functional requirements: How many users? What latency is acceptable? What availability is expected?

A concrete example: For “Design a chat system,” you ask: “Are we talking about 1-to-1 chat or also group chat? Do messages need to be persistently stored? Do we need read receipts? How many concurrent users do we expect?” These questions show the interviewer that you can scope a problem instead of building blindly.

Candidates who skip this step often solve a different problem than what the interviewer had in mind. That costs you the entire rest of the interview.

Phase 2: High-Level Design (10 Minutes)🔗

Draw the main components and their connections. Start with the simplest design that satisfies the requirements: client, API gateway, application server, database. Define the key APIs (which endpoints, what data flows) and sketch the data model.

Resist the urge to talk about caching, sharding, or message queues immediately. Build the foundation first. The interviewer wants to see that you work systematically, not that you drop as many buzzwords as possible.

Phase 3: Deep Dive (20 Minutes)🔗

This is the core of the interview. The interviewer will either go deeper into an area they find particularly relevant, or you propose where you want to dive deeper. Typical deep-dive topics are the database schema, the scaling strategy, the caching concept, or consistency guarantees.

Depth matters here, not breadth. A candidate who thinks through the sharding concept for the chat message database, including how messages are distributed across partitions and what happens when a shard fails, makes a stronger impression than someone who superficially touches five components.

Phase 4: Bottlenecks and Trade-offs (5 Minutes)🔗

Identify the weaknesses in your design. Where is the single point of failure? Which component becomes the bottleneck under load? How would you set up monitoring? What happens during a datacenter outage?

The ability to critically evaluate your own design is one of the strongest signals of senior-level competence. Junior candidates present their design as finished. Senior candidates show where it would break.

Phase 5: Summary (5 Minutes)🔗

Summarize what you built, what decisions you made, and why. This is your chance to tie the narrative together and show the interviewer you maintained the big picture. Also mention what you would address given more time.

If you want to test this framework under real time pressure, a mock system design interview is the most effective way. 45 minutes under realistic conditions reveal weaknesses that self-study cannot uncover.

Classic System Design Questions🔗

The following problems form the foundation of nearly every system design interview catalog. If you master these five, you are prepared for the majority of interviews.

1. URL Shortener (like bit.ly)🔗

What is being tested: API design, data modeling, hashing strategies, read-heavy scaling.

You design a system that converts long URLs into short aliases and resolves them. The problem sounds simple but tests depth: How do you generate unique short URLs? Do you use Base62 encoding, hash functions, or a counter-based approach? How do you handle collisions?

Key components: API layer (POST to create, GET to resolve), key-value store or relational database, cache layer for frequently accessed URLs, analytics service.

Common pitfall: Candidates jump straight to the hash function without first clarifying scale requirements. At 100 million URLs per day, you need a different strategy than at 1,000.

Typical at: Google, Amazon, Meta, Stripe, nearly every tech company as a starter question.

2. Rate Limiter🔗

What is being tested: Distributed systems, consistency vs. performance, algorithm knowledge (Token Bucket, Sliding Window, Fixed Window).

Design a system that limits the number of API calls per user or IP address. The challenge lies in distributed execution: How do you ensure the limit is correctly enforced across multiple servers?

Key components: Rate-limiting middleware, distributed counter (Redis or in-memory), configuration layer for per-endpoint rules, response headers with limit status.

Common pitfall: Ignoring the distributed aspect. A rate limiter on a single server is trivial. The question is how you ensure consistency across 50 servers without ruining latency.

Typical at: Cloudflare, Stripe, Amazon, Google Cloud.

3. Chat System (like WhatsApp/Slack)🔗

What is being tested: Real-time communication, persistent connections (WebSockets), message delivery guarantees, presence system.

This problem is rich because it can branch in many directions: 1-to-1 chat, group chat, offline message delivery, end-to-end encryption, typing indicators, read receipts.

Key components: WebSocket server for real-time connections, message queue for asynchronous delivery, message storage (NoSQL for chat history), presence service, push notification service for offline users.

Common pitfall: No clear strategy for offline message delivery. What happens when a user is offline? How do you ensure they receive all messages when they come back online? Most candidates think only about the happy path.

Typical at: Meta (WhatsApp, Messenger), Slack, Google (Google Chat), Zoom.

4. News Feed (like Facebook/LinkedIn)🔗

What is being tested: Fan-out strategies (push vs. pull), ranking algorithms, caching for personalized content, eventual consistency.

Design a system that shows each user a personalized feed of posts from their connections. The central design decision: push model (update every follower’s feed when a new post is created) or pull model (assemble the feed only when requested)?

Key components: Post service, fan-out service, feed cache (per user), ranking service, media storage, notification service.

Common pitfall: Ignoring the celebrity problem. A user with 10 million followers cannot be handled via push model, that would be 10 million cache updates per post. Hybrid approaches (push for regular users, pull for celebrities) are the expected solution.

Typical at: Meta, LinkedIn, Twitter/X, TikTok.

5. Notification System🔗

What is being tested: Asynchronous processing, message queues, template systems, prioritization, delivery guarantees across multiple channels.

Design a system that delivers notifications via email, push, SMS, and in-app. The complexity lies in orchestration: When is which channel chosen? How do you prevent duplicates? How do you handle user preferences and throttling?

Key components: Event ingestion (what triggers a notification), routing service (which channel), template engine, delivery services per channel (SMTP, APNs, FCM, SMS gateway), delivery status tracking.

Common pitfall: Designing for only one channel. Interviewers expect you to approach this as a multi-channel system and explicitly address the routing logic.

Typical at: Amazon (SNS team), Twilio, Airbnb, Uber.

Infrastructure and Data System Questions🔗

These questions test your understanding of the infrastructure layer. They come up especially at senior-level positions and at companies with their own platform infrastructure.

6. Distributed Cache (like Redis/Memcached)🔗

What is being tested: Consistent hashing, cache eviction policies (LRU, LFU), replication, cache invalidation, hot-key problem.

Design a distributed cache service that spreads data across multiple nodes and remains available during node failures. The problem forces you to think about data hashing, replication, and the infamous cache invalidation problem.

Key components: Cache nodes, consistent hash ring, replication manager, client library with routing logic, health check and failover.

Common pitfall: Mentioning consistent hashing but not being able to explain why it is better than modulo hashing when nodes change.

Typical at: Amazon (ElastiCache), Redis Labs, Google, infrastructure teams at scale-ups.

7. Search Engine (like Google Search)🔗

What is being tested: Inverted index, crawling pipeline, ranking algorithms, indexing at billions of documents.

This is one of the most challenging problems because it encompasses many subsystems. Normally the interviewer focuses on one aspect: How do you build the index? Or: How do you rank results? Make sure you clarify which part they want to go deep on.

Key components: Crawler, document processor (parsing, tokenization), inverted index, query parser, ranking engine, result cache.

Common pitfall: Trying to build Google in 45 minutes. Focus on the slice the interviewer chooses. If they want the crawler, go deep into crawl scheduling, politeness, and deduplication.

Typical at: Google, Amazon (product search), Elasticsearch, Algolia.

8. Payment System (like Stripe)🔗

What is being tested: Transaction safety, idempotency, eventual consistency, reconciliation, compliance.

Design a system that processes online payments. This is about correctness, not performance. Every transaction must be processed exactly once, even during network failures, server crashes, or timeouts.

Key components: Payment gateway, transaction ledger (double-entry bookkeeping), idempotency layer, fraud detection service, reconciliation engine, audit trail.

Common pitfall: Not building in idempotency from the start. If a client sends a payment, the server processes it, but the response is lost and the client retries, the payment must not be executed twice. You need to address this problem before the interviewer asks about it.

Typical at: Stripe, PayPal, Amazon, Adyen, Klarna, SumUp.

9. Video Streaming (like YouTube/Netflix)🔗

What is being tested: CDN architecture, video encoding pipeline, adaptive bitrate streaming, content delivery across geographically distributed infrastructure.

Design a system for video upload, processing, and streaming. The challenge is volume: videos must be transcoded into different resolutions and formats, distributed via a CDN, and delivered with adaptive bitrate.

Key components: Upload service, transcoding pipeline (parallel for different resolutions), object storage (S3 or GCS), CDN for delivery, metadata service, recommendation engine.

Common pitfall: Treating the transcoding pipeline as a single step. In reality, this is a distributed workflow with parallel tasks, progress tracking, and error handling for failed transcodes.

Typical at: YouTube (Google), Netflix, Amazon Prime Video, TikTok.

10. Key-Value Store (like DynamoDB)🔗

What is being tested: Partitioning, replication, consistency models (strong vs. eventual), write-ahead log, compaction.

Design a distributed key-value store that can handle millions of reads and writes per second. This problem tests your understanding of distributed storage systems at a fundamental level.

Key components: Partition manager (consistent hashing), storage engine (LSM-tree or B-tree), replication protocol (leader-follower or leaderless), conflict resolution, compaction process.

Common pitfall: Not being able to clearly distinguish between strong consistency and eventual consistency and not naming the trade-offs (latency, availability).

Typical at: Amazon (DynamoDB team), Google (Bigtable), Apple, Databricks.

Web-Scale and Platform Questions🔗

These problems test whether you can design systems that serve millions of users and orchestrate multiple subsystems.

11. Ride-Sharing (like Uber)🔗

What is being tested: Location-based services, real-time matching, geospatial indexing, ETA calculation.

Design a system that matches drivers and riders in real time. The core challenge is geolocation: How do you efficiently find the nearest available driver? How do you update driver positions in real time?

Key components: Location service (geospatial index with QuadTree or Geohash), matching engine, ETA service, trip service, payment integration, pricing engine (surge pricing).

Common pitfall: Treating geolocation as simple distance calculation. In reality, you need a geospatial index that can efficiently query millions of constantly changing positions.

Typical at: Uber, Lyft, Delivery Hero, FREE NOW, Bolt.

12. E-Commerce Platform (like Amazon)🔗

What is being tested: Inventory management, eventual consistency, shopping cart design, order processing pipeline.

Design an e-commerce system with a product catalog, shopping cart, and order processing. The challenge: How do you handle race conditions when 1,000 users simultaneously try to buy the last item?

Key components: Product catalog service, inventory service (with reservation logic), shopping cart service, order service, payment service, fulfillment service.

Common pitfall: Treating inventory decrement as a simple UPDATE. You need a reservation system with a timeout, otherwise shopping carts that never check out block inventory for other users.

Typical at: Amazon, Zalando, Otto, Shopify, eBay.

13. Distributed Task Scheduler (like Airflow/Cron)🔗

What is being tested: Job scheduling, idempotency, retry logic, dependency management, distributed locking.

Design a system that executes millions of time-triggered or event-triggered tasks. How do you ensure a task is executed exactly once, even if the worker crashes?

Key components: Scheduler (cron parsing, event triggers), task queue (priority queue with delay), worker pool, execution tracker, retry manager with backoff, dead letter queue.

Common pitfall: Promising exactly-once execution. In a distributed system, exactly-once is extremely hard to guarantee. The interviewer wants to see that you can explain the difference between exactly-once and at-least-once with idempotency.

Typical at: Google (Cloud Scheduler), Amazon (Step Functions), Airbnb, LinkedIn.

ML System Design Questions🔗

ML system design is a growing interview trend, especially at FAANG and ML-heavy companies. These questions test not just ML knowledge but primarily how you design an end-to-end ML pipeline.

14. Recommendation System (like Netflix/Spotify)🔗

What is being tested: Feature engineering, collaborative filtering vs. content-based filtering, model serving architecture, A/B testing framework.

Design a system that gives users personalized recommendations. The challenge: How do you balance relevance (what the user is likely to enjoy) against exploration (discovering new content)?

Key components: Feature store (user features, item features, interaction features), training pipeline (offline), model serving (online with low latency), candidate generation, ranking model, A/B testing framework.

Common pitfall: Discussing only the ML algorithm and ignoring the infrastructure. The interviewer wants to know how you compute features, train the model, deploy it, and measure results. The algorithm itself is often the easiest part.

Typical at: Netflix, Spotify, Amazon, YouTube, TikTok, LinkedIn.

15. Spam/Fraud Detection🔗

What is being tested: Real-time vs. batch processing, feature engineering under time pressure, model retraining, false positive management.

Design a system that detects spam messages or fraudulent transactions in real time. The challenge: false positives are expensive (legitimate users get blocked), but false negatives are even more expensive (fraud goes through).

Key components: Real-time feature computation, rule engine (fast, manual rules), ML model (slower, more accurate detection), feedback loop (human review that improves the model), action service (block, flag, allow).

Common pitfall: Ignoring the latency requirement. Spam detection must decide in milliseconds, not seconds. That means: precomputed features, lightweight models for the first stage, and heavier models only on suspicion.

Typical at: Google (Gmail spam), Meta (content moderation), Stripe (Radar), PayPal, Amazon.

16. Search Ranking with ML🔗

What is being tested: Feature engineering for search relevance, learning-to-rank, online/offline feature consistency, evaluation metrics (NDCG, MRR).

Design an ML system that ranks search results by relevance. This differs from the classic search engine question in that the focus is on ML ranking, not index infrastructure.

Key components: Query understanding (intent classification, query expansion), feature computation (query-document features, user features), learning-to-rank model, online serving with feature store, offline evaluation pipeline.

Common pitfall: Thinking only about text relevance. Modern search systems use dozens of features: click-through rate, freshness, user history, location. The interviewer wants to see that you think beyond the text layer.

Typical at: Google, Amazon Product Search, LinkedIn, Booking.com, Airbnb.

What Google, Amazon, and Meta Evaluate Differently🔗

The problems overlap, but the evaluation criteria differ significantly. Knowing what your target company focuses on lets you weight your 45 minutes accordingly.

Google: Abstraction and Scale🔗

Google interviewers give deliberately vague problems and observe how you handle ambiguity. They expect you to independently define sensible constraints and discuss your design at billion-user scale. “What happens at 10x the current load?” is a typical follow-up. Google places particular emphasis on clean abstraction layers: your design should clearly separate application layer, service layer, and storage layer.

Amazon: Practicality and Trade-offs🔗

Amazon interviews are more closely tied to real products. “Design the order pipeline” or “Design the inventory system” are typical problems. The interviewer wants to see that you can name and justify concrete trade-offs: Why eventual consistency instead of strong consistency? Why DynamoDB instead of PostgreSQL? Amazon explicitly evaluates whether you incorporate the Leadership Principles into your design, especially “Dive Deep” and “Bias for Action.”

Meta: Social Scale and Real-time🔗

Meta questions often revolve around social networking problems: news feed, messaging, content distribution, live video. The focus is on real-time delivery, personalization, and handling extreme fan-out scenarios (a single post distributed to millions of followers). Meta interviewers pay particular attention to the discussion of caching strategies and the balance between latency and consistency.

What This Means for Your Preparation🔗

The differences are real, but the fundamentals are identical. Anyone who masters the 15+ problems in this guide and can confidently apply the 45-minute framework is well prepared for all three companies. The company-specific calibration comes in the final preparation step, ideally through a mock interview with someone who knows the specific company’s process.

How to Practice These Questions Effectively🔗

Knowledge about system design questions is the first step. The real challenge is communicating your solution clearly in 45 minutes and responding confidently to follow-up questions. Three practice strategies have proven effective.

Strategy 1: Practice out loud. Pick a problem, set a timer for 45 minutes, and explain your solution to an imaginary interviewer. Draw on a whiteboard or use a tool like Excalidraw. The goal is not the perfect solution but fluent communication under time pressure.

Strategy 2: Peer practice. Practice with another developer. One poses the problem and plays the interviewer, the other solves it. Switch roles after each session. This gives you the interviewer perspective, which sharpens your own understanding.

Strategy 3: Mock interview with feedback. Self-study and peer practice build foundations. What they cannot deliver is calibrated feedback from someone who has seen hundreds of system design interviews. An experienced interviewer recognizes patterns in your reasoning within 45 minutes that you cannot see yourself: skipped trade-offs, missing scaling discussions, or time allocation that cuts the deep dive short.

Prepare Your System Design Interview with CodingCareer🔗

CodingCareer’s FAANG Coaching includes mock system design interviews with former Google and Meta developers. In 45 minutes, you work through one of the problems described in this guide under realistic conditions with real-time feedback. Afterward, you receive 15 minutes of structured feedback: what was strong, where the gaps are, and what concrete steps will take you to the next level.

The coaching is tailored to the German and European tech market. That means: alongside FAANG-scale problems, you also practice practical problems like those asked at Zalando, Delivery Hero, or SAP. Your preparation is adapted to your target level and target companies, not a generic curriculum.

If you are ready to test your system design skills under realistic conditions: Book a mock system design interview or start with a free 15-minute diagnostic session to find out where you stand.