System Design Interview Questions & Prep (from FAANG experts)

4-Step System Design Answer Framework: Walk-through

System design interview questions are meant to be vague. It appears like they're trying to ask you to boil an ocean when they ask you a question like “Design Twitter” or “Design YouTube.” It’s a whole company; how can one engineer design that?

Think of it this way: the interviewer's responsibility is to give you a question that’s very vague and complicated, while your responsibility as a candidate is to make sure that it is as simplified as possible.

Step 1: Clarifying requirements

So now, how do you simplify the problem? That is the first skill interviewers try to evaluate in a system design interview.

When an interviewer asks you to design a calendar, what do they mean by a calendar? How big of an organization? If it's for a small organization, do you need to worry about each other's calendars or about meeting rooms? It’s how you break down the problem. This is where you say you are “clarifying or simplifying the requirements.”

What does “simplifying the requirements” mean? For any software product, you need to collect information from wherever the sources are, and you need to give it back to the people who are asking for it. In more methodical terms, they call it defining your functional requirements and non-functional requirements.

Depending on your level, I would expect you to come up with these requirements intuitively. As a junior engineer, you might stop at functional requirements. As a staff-plus engineer, fun non-functional requirements are very critical. Interviewers want to know how many you can think of on your own. 

So, how do you know whether you got everything right or wrong? You would never know. Because that is not the intention. System design interviews are meant to grade people on a scaling level. 

Don't worry about whether you’ve completely defined your functional and non-functional requirements. Getting an agreement on it will help. List down your requirements and confirm them with your interviewers. Or, ask for a direct hint, like, “What are your most important requirements?”

Step 2: High-level design

Next is the high-level design. High-level design for 90% of the products will be the same:

• Client-side, which gives you the information
• Server-side, which is collecting the information
• Storage layer, which stores the information

Think about your write path and your read paths.  Now use your non-functional requirements: at what cadence it is coming through at high frequency, and how much distribution is coming through will determine what kind of storage layer you pick. 

Step 3: Drill down on your design (low-level design)

This is the point you ask your interviewer: Is there a particular area you want me to discuss further? That's where you drill down into your low-level design and let your expertise come into play. 

If you are applying for a data-focused role, focus on the storage layer. For a backend-focused role, you could discuss transactions per second. For a front-end-focused role, maybe talk about client-side handling. For an ML-focused role, your ranking algorithm, how that's going to be, and how adaptable it should be.

Step 4: Bring it all together

In the last few minutes of your interview, you’ll then want to check whether you’ve met the goals of the design, i.e., the functional and non-functional requirements.

If you have time, you can go into possible bottlenecks or issues, or ways to optimize or scale the system.

1. Ask clarifying questions

• Scope: Are we focusing only on one-to-one text messaging or should we also support groups, media, voice/video, etc.?
• Functional requirements: Sending, receiving, reading messages. Should we handle message delivery acknowledgements (delivered/read status)?
• Non-functional requirements:
  • Scale: Expected 10B messages/day, doubling in a year.
  • Latency: < a few hundred ms for 90–95% of requests.
  • Availability: “Always available” (5 nines if possible).
  • Consistency: Eventual consistency acceptable

• Constraints: Mobile-first application, backend focus, APIs as entry points.

2. Design high-level

• Clients: Mobile/web apps interact with system via APIs.
• APIs: Core set — SendMessage, CheckMessages, ReadMessage, MarkAsRead.
• Traffic management: Load balancer in front to distribute requests.
• Application/API servers: Horizontally scalable, stateless, ~50–100 servers initially.
• Data storage: NoSQL database (e.g., DynamoDB/Cassandra) to handle large scale and eventual consistency.
• Message distribution: Background service (message distributor) ensures undelivered messages are routed to correct recipients.
• Core entities:
  • Messages (messageId, senderId, recipientId, timestamp, status, text).
  • Users (userId, metadata, sent messageIds, unread messageIds).

3. Drill down on your design

• Database choice:
  • SQL pros: complex queries; cons: poor scalability at petabyte scale.
  • NoSQL pros: horizontal scaling, high throughput, fits simple access patterns.
  • DynamoDB chosen for managed scaling + partition key/range key support.

• Sharding strategy: Consistent hashing to partition user/message space across servers (built-in for DynamoDB).
• Message distributor:
  • Continuously scans undelivered messages.
  • Adds message IDs to recipient’s unread list.
  • Updates status → delivered.
  • Needs to scale horizontally to avoid bottleneck (multiple distributors partitioned by user space).

• Performance considerations:
  • ~0.5M requests/sec at peak.
  • 100-byte avg message size → ~1 TB/day → ~365 TB/year → ~1 PB in ~3 years.
  • Need monitoring of latency percentiles (95th/99th).

• Bottleneck handling:
  • Potential overload in scanning undelivered messages.
  • Solution: separate undelivered/delivered tables OR efficient DB queries with filters.

• Reliability/availability:
  • Auto-scaling servers
  • Replicated storage
  • Monitoring system availability in terms of “number of nines”

4. Bring it all together

• Start from scope reduction: one-to-one text messages, exclude groups/media.
• Expose APIs for message operations, behind a load balancer and horizontally scalable API servers.
• Use NoSQL (DynamoDB/Cassandra) for message/user storage, leveraging partition/range keys for fast lookups.
• Introduce a message distributor service to handle delivery asynchronously with eventual consistency.
• Plan for scaling (50–100 API servers, auto-scaling DB, multi-distributor setup).
• Monitor latency, throughput, and availability as success metrics.
• Acknowledge open issues/future extensions: group messaging, multimedia, locking/contention handling.

1. Ask clarifying questions

• Functional requirements
  • Users need to be able to: 
    • Create a profile
    • Follow other profiles
    • Post (let’s stick to just text)
    • Share and comment on posts
    • See other posts in newsfeed
• Non-functional requirements
  • Do some key estimates to work out scalability requirements:
    • How many users do we need to serve - 100 million?
    • How many profiles does each person follow on average - let’s say 300
    • How many posts does each user create on average - let’s say 2 per day.
• Work out the transactions per second - how are you going to meet this with your design? (for traditional backend SWE candidates, this will probably be your main concern)
• Consider special users: 5% of users will have a lot of followers and their posts will receive thousands of comments and millions of likes. 

2. Design high-level

Most users will use the web app, so let’s design that.

We’d use a load balancer.

• Message queue: 
  • The content will be coming in continuously, so we’d want a queuing system to avoid missing anything 
  • The data will come through the message queue
• Data storage layers: 
  • Different data storage layers for different pieces of the information 
  • This data layer has to store quite a bit of user follower network, user following network, and the content
• Ranking mechanism: 
  • On the read path, we need a ranking mechanism to make sure that we have what content to be given to the users when they're logged. 
  • Ranking algorithm to work out what content a user would be most interested in. 
  • Algorithm takes into account newness of content, who it’s by (need to be very up-to-date, hot content)
  • Include this as a black box
  • If you’re an ML candidate, you’d need to go into more detail on this.

3. Drill down on your design 

• Storage layer 
  • Include separate databases for user data, follower networks, and content
  • User information and follower relationships are stored in a relational database, with sharding if needed. 
  • The follower network could scale to 10 billion records. 
• Split content storage 
  • Metadata is kept in a relational database (sharded by timestamp)
  • Actual media content is stored in a NoSQL key-value store
  • Recent content (last week or month) is prioritized for quick access
• Ranking algorithm 
  • Selects the top 20 tweets for each user based on their network and trending content, caching the results for efficiency.

4. Bring it all together

• Consider: does the final design meet the functional and non-functional requirements you established at the start? Are there any bottlenecks?

1. Ask clarifying questions

• Functional requirements:
  • Upload/download photos/videos
  • Search (by title)
  • Follow functionality
  • News feed
• Out of scope: Likes, comments, tags, stories, messaging.
• Non-functional requirements:
  • High availability
  • Globally distributed user base
  • News feed latency < 1 second
  • High reliability, minimal tolerance for data loss
• Scale assumptions:
  • 1B total users
  • 250M DAUs (~25%)
  • ~25K read requests/sec (mainly news feed)
  • ~250 uploads/sec (10% of DAUs post daily, avg. 200 KB/photo)
  • Storage: ~5 TB/day → ~100+ TB/year

2. Design high-level

• APIs (versioned, read/write split):
  • Reads
    • GET /download/{id} (download media)
    • GET /search?q=title
    • GET /feed
  • Writes
    • POST /upload (upload media)
    • POST /follow/{id}
• Core services/components:
  • API Gateway – single entry point, handles auth, rate limiting.
  • Load balancer – geo-distributed routing to nearest servers.
  • Media service – handles uploads/downloads.
  • Message queue & uploader – async upload pipeline.
  • Object storage – photos/videos.
  • Relational DB – metadata (users, photos, follows).
  • NoSQL DB – news feed storage for fast retrieval.
  • Feed service – generates & serves news feed (uses cache).
  • Follower service – manages follow/unfollow relationships.
  • Search service – metadata search (title-based).
  • CDN – speeds up downloads for global users.

3. Drill down on your design

Design storage

• Object storage (photos/videos)
  • Replicated for durability and reliability.
  • Handles massive scale of media (billions of objects).
• Relational DB (metadata)
  • Stores user info, photo metadata, follow relationships.
  • Sharded by user_id for horizontal scaling.
  • Replicas for high availability.
• NoSQL DB (news feed)
  • Optimized for fast feed retrieval.
  • Stores precomputed feed entries with low-latency lookups.
• CDN
  • Serves popular photos/videos closer to end users globally.

Design upload/download

• Upload flow
  • User → API Gateway → Media service → Queue → Uploader → Object storage + Metadata DB.
  • Asynchronous upload pipeline prevents user from waiting.
  • Unique ID generator ensures global uniqueness of media IDs.
• Download flow
  • User → API Gateway → Media service → CDN (cache-first).
  • Fallback: CDN → Object storage → return to user.
  • Metadata lookup in relational DB ensures correct mapping of photo IDs to storage objects.

Design newsfeed

• ​​Feed service
  • Handles user requests for personalized feeds.
  • First checks cache (Redis/NoSQL).
  • If outdated, triggers feed generation service.
• Feed generation
  • Precomputes feeds periodically (e.g., every 15 min).
  • Pulls follower lists and recent posts from DBs.
  • Orders posts by recency/relevance, stores in NoSQL.

• Optimizations
  • Cache feeds for sub-second retrieval.
  • Power-user handling: selectively precompute feeds for subsets of followers to reduce compute load.
  • User activity table guides prioritization (e.g., only generate feeds for active users).

Design following

• Follower service
  • APIs for follow/unfollow events.
  • Writes relationships into relational DB (Follow(follower_id, followee_id)).
• Impact on feeds
  • Follow events trigger feed generator updates.
  • For power users, system selectively refreshes feeds of most active followers.
• Scalability
  • Sharded relational DB ensures queries like “who am I following?” remain efficient.

4. Bring it all together

• System supports billions of users with heavy reads and moderate writes.

• Achieves sub-second feed latency using caching, precomputation, and NoSQL.

• Ensures global availability with CDNs, replication, and geo-distributed load balancing.

• Uploads handled asynchronously for better UX; storage split between object, relational, and NoSQL for reliability and performance.

• Design leaves room for future optimizations: advanced feed ranking algorithms, sharding strategies, and adaptive caching for power users.

1. Ask clarifying questions

Define scope: Google Drive / Dropbox–like system.

• Functional requirements:
  • Upload files
  • Download files
  • Sync across devices
  • Notifications for updates
• Out of scope:
  • File previews (thumbnails, video playback)
  • Collaborative editing (Docs-style)
  • File sharing with external users
  • Versioning / backups
• Platforms: Desktop, mobile, and web
• Scale assumptions:
  • 100M registered users, 1M daily active users (DAU) 
  • 1 file uploaded per user per day (~5 MB average)
  • File size limit: 10 GB/file, 15 GB/account
  • Estimated storage: ~1.5 PB
  • QPS: ~11 average, ~20 peak
  • Daily data traffic: ~5 TB

2. Design high-level

• Core components:
  • Clients (desktop, mobile, web)
  • Load balancer (routes requests)
  • Application servers (API logic)
  • Cloud storage (e.g., S3 buckets for files)
  • Metadata database (e.g., MySQL via RDS)
  • Notification service (Pub/Sub or SNS)
• API Endpoints:
  • Upload (multi-part/resumable uploads)
  • Download (pre-signed temporary URLs)
  • Get file revisions (to check for latest version)
  • Flow overview:
    • Upload: Client → LB → API → Pre-signed URL → Upload to storage → Confirm via API → Update metadata DB → Trigger notification.
    • Download: Client → API → Pre-signed URL → Retrieve file from storage.
    • Notifications: API → Notification service → Clients receive update → Fetch changes.

3. Drill down on your design

• Client responsibilities: Compression, authentication, encryption (optional), direct S3 uploads/downloads.
• Database schema:
  • User (id, email, password hash, last login)
  • File (id, path, hash, owner_id)
  • FileVersion (id, file_id, version number, timestamp)
  • Device (id, user_id, device details)
• Trade-offs and rationale:
  • Compression on client (saves bandwidth vs. CPU trade-off).
  • MySQL over NoSQL (consistency & simplicity).
  • S3 chosen for scalability, familiarity, and pre-signed URL support.
• Scalability considerations:
  • Sharding in S3 folder naming to avoid hotspots.
  • CDN integration for faster downloads and caching.
  • Regional replication (NA, EU, Asia data centers).
  • Database replicas (master-slave, read replicas).
• Conflict resolution: Duplicate file with timestamp if simultaneous updates.
• Additional features not implemented but possible:
  • Backups / versioning (leveraging S3).
  • Encryption (client-side to protect against breaches).

4. Bring it all together

• Recap flows: Upload → metadata DB + storage + notifications → download by other clients.
• Non-functional goals:
  • Simplicity & trust (easy to use, cross-platform).
  • High availability (regional redundancy).
  • Performance (low latency, CDN, compression).
  • Data integrity (encryption, conflict handling).
• Future improvements:
  • Premium features (file versioning, backup).
  • More sophisticated folder management.
  • Scaling strategies (multi-region deployments, CDN, DB replicas).

1. Ask clarifying questions

• Scope: What would be the constraints for today’s system design? Finding and playing music (exclude playlists, recommendations, podcasts, social features).
• Users: Assume ~1 billion users.
• Catalog size: ~100 million songs.
• Song size: Avg. ~5 MB per song.
• Storage needs: ~500 TB raw → ~1.5 PB with 3× replication.
• Metadata size: ~100 GB for songs, ~1 TB for user data.
• Non-functional requirements:
  • High availability (global users).
  • Scalability (handle billions of streams).
  • Low latency (seamless playback).

2. Design high-level

• High-level components
  • Clients: Spotify mobile and desktop apps (primary interface).
  • Entry Point: Global load balancers route users to nearest data center.
  • Web/Application Servers: Handle API requests (search, playback, metadata lookup).
  • Audio Storage: Blob/object store for MP3 files, replicated across regions.
  • Metadata Storage: Relational DB (e.g., MySQL/RDS) for songs, artists, albums, users.
  • Caching Layers:
    • CDN: Distributes and caches hot tracks near users.
    • In-memory caches: Reduce repeated DB hits for metadata and stream tokens.
    • Device cache: Offline/local caching for frequently played tracks.

3. Drill down on your design

• Database
  • Audio storage: Immutable MP3 files stored in blob storage (e.g., S3) with replication.
  • Metadata DB: Relational database (e.g., MySQL/RDS) for songs, artists, and user data.
  • Geo-distribution: Replicate both audio and metadata across multiple regions to serve global traffic efficiently.
• Use cases
  • Search:
    • Queries metadata DB for songs, artists, albums.
    • Returns lists of song IDs, metadata, and storage links.
  • Streaming:
    • Client requests a song through the app.
    • Web server retrieves file from blob store (or CDN) and streams in chunks.
    • Uses persistent connections (e.g., WebSockets/HTTP streaming).
  • Offline listening:
    • Mobile app caches recently played tracks for playback without network.
• Bottlenecks
  • Hot content spikes: Popular releases (e.g., BTS album) create massive simultaneous requests.
  • Metadata DB contention: High read volume during peak search queries.
  • Network throughput: Web servers can saturate network bandwidth faster than CPU.
• Cache
  • Device-level: Spotify app caches recently played tracks for offline playback.
  • Edge/CDN: Caches hot songs close to end users, absorbs traffic spikes.
  • Web server: In-memory cache avoids repeated DB lookups for metadata and frequently requested songs.

• Load balancing
  • Distributes client requests across web/application servers.
  • Metrics used: not just CPU, but also network bandwidth and number of active streams.
  • Elastic scaling: Spin up/down additional servers based on real-time demand.

4. Bring it all together

• System recap:
  • Spotify app → load balancer → web servers.
  • Metadata lookups → relational DB.
  • Audio streams → blob storage + CDN + cache layers.
• Key optimizations:
  • Multi-layer caching (device, web server, CDN).
  • Geo-aware replication for performance.
  • Smarter load balancing based on bandwidth.
• Non-functional goals met:
  • Scalability → CDN + blob storage + sharding.
  • Availability → 3× replication + geo-distribution.
  • Low latency → caching at multiple levels
• Extensions:
  • Recommendations, playlists, podcasts.
  • Real-time collaborative features.
  • Advanced ranking/search infrastructure.

Google system design interview questions

• Design YouTube (ByteByteGo written solution)
• Design a distributed cache (written solution from Ravi Tandon)
• Design Google Maps (video solution from codeKarl)
• Design a news front page with source aggregation across newspapers
• Design Google Photos
• Design an online booking system for a restaurant
• Design an autocomplete feature with an efficient data structure
• Design a ticketing platform
• Design an elevator
• Design a Boggle solver
• How would you design a system for a robot to learn the layout of a room and traverse it?
• How would you deploy a solution for cloud computing to build in redundancy for the compute cluster?

Meta system design interview questions

• How would you design Instagram? (Download answer diagram)
• How would you design Twitter/X.com? (video solution)
• How would you design a chat system like WhatsApp? (ByteByteGo written solution)
• Design a live commenting system for posts
• Design Facebook status search
• How would you design an autocomplete service for a search engine?
• Design a travel booking system for Facebook users
• Design Instagram Stories
• How would you build Minesweeper?
• Design a system to prevent ads from foreign actors from interfering in domestic politics
• Design a distributed botnet
• Design a video upload and sharing app
• Design the API layer for Facebook chat
• How would you use a load balancer for memcache servers?
• How would you architect the Facebook newsfeed?
• Implement a typeahead feature

Amazon system design interview questions

• Design Snake / Chess / Tic-Tac-Toe / Poker / Boggle
• Design a parking lot
• Design a TinyURL service
• Design an API that would take and organize order events from a web store
• Design an elevator
• How would you design an electronic voting system?
• Design a deck of cards
• Design a system to optimally fill a truck
• Design a warehouse system for Amazon
• Design an online poker game
• Design a parking payment system
• Design a system to interview candidates
• Design a search engine autocomplete
• Design an airport
• Design the Prime Video home page
• Design a registration system for a restaurant
• Design a food delivery app at a global scale
• Design an inventory system
• Design a news website
• Design a shopping cart system
• Design a system to find friends on social media
• Design a Swiggy delivery system with a focus on optimizing for the shortest route
• Design a temperature identification system with geographically distributed sensors
• Design a ticketing system
• How would you design a system that reads book reviews from other sources and displays them on your online bookstore?
• Design a promotion mechanism which could give 10% cash back on a particular credit card
• How would you build software behind an Amazon pick up location with lockers?
• Design a distributed cache system (video solution)

OpenAI system design interview questions

• How would you build an LLM-powered enterprise search system?
• Design an in-memory database.
• Design a web hook system.

Microsoft system design interview questions

• How does buffer overflow work?
• How would you design an online portal to sell products?
• Design a new fitness wearable to measure heart rate
• Design a shopping cart

Uber system design interview questions

• Design a heat map for Uber drivers
• Design a system to match rider and driver
• Design TripAdvisor (written answer)
• Design Google Photos (video answer front-end)
• Design YouTube feed with API
• Design a search engine (video answer)

Apple system design interview questions

• Design a smart elevator system that optimizes travel efficiency by grouping similar destination requests, prioritizes accessibility needs, incorporates real-time adjustments based on user input, and ensures energy-efficient operations through idle movement minimization.
• Build a blackjack gaming site
• Build Netflix (written answer)

NVIDIA system design interview questions

• How would you design a chatbot service that provides users with a variety of information?
• How would you perform API modeling while managing multiple servers?
• Create a memory management system that allocates fixed-size blocks, in a constrained environment with limited memory. Avoid using malloc, free, new, or delete; instead, rely on a 'memory' function for both managing memory and allocating space for clients.
• How would you design a memory allocator?
• How would you design an interface for managing and running jobs on various GPUs?
• Here is our system (description provided). How would you design it?
• How would you design a platform like Facebook or Uber?
• How would you design a proximity server?
• How would you design a shared file system that stores files in the cloud?

Anthropic system design interview questions

• Design the Claude chat service.
• Design a distributed search system for 1 billion documents at 1 million QPS. Cover sharding, caching, and LLM inference scaling.
• Design a batched inference system where 100 requests take the same time as 1. Use a queue to batch requests.
• Design a system that enables a large language model to handle multiple questions in a single thread.
• Design APIs for developers to access Anthropic's AI models securely and efficiently.
• Design a file-sharing / distribution system.
• Design a high-concurrency inference API / parallel processing pipeline.