Google System Design Interview Questions (And Answers)

Free Coding Questions Catalog

Boost your coding skills with our essential coding questions catalog. Take a step towards a better tech career now!

Google’s system design interviews are known to challenge candidates to design large-scale systems from scratch.

Each interview (about 45 minutes) usually focuses on one complex product or service (for example, “Design YouTube”).

Interviewers expect candidates to be familiar with Google’s products and to demonstrate strong fundamentals in system architecture. In these rounds, you might get 1–2 such questions depending on the role.

What Do Interviewers Look for?

They want to see a structured thought process and breadth of technical knowledge. This means clearly defining requirements, proposing a sensible high-level architecture, discussing scalability, and addressing trade-offs (e.g. consistency vs availability).

Rather than just naming off-the-shelf solutions, Google interviewers prefer when you explain how you would build core components (databases, caches, load balancers) yourself. The key is to cover both functional and non-functional aspects and communicate your reasoning effectively.

Learn how to prepare for Google system design interview.

10 Common Google System Design Interview Questions (And Answers)

Below we discuss 10 frequent system design questions in Google interviews and outline how to approach each with a structured solution:

1. Design Google Maps

Requirements: Map display, location search, route planning (with live traffic). Needs high availability & low latency.
Architecture: Geospatial database (roads and places), a routing engine for path calculations, and backend API servers (behind load balancers) to serve map data and directions to users.
Scalability: Partition map data by region; cache map tiles & routes; add servers and load balancing to handle growing user load.
Data: Process updates asynchronously (eventual consistency is OK for new road data). Replicate databases across regions so the service remains available if one area fails.
Security: Secure APIs (authentication, encryption) to protect user data. Use redundant servers and failover mechanisms for reliability (no single point of failure).

2. Design YouTube

Requirements: Video upload, storage, and streaming platform. Must handle huge traffic (millions of concurrent viewers) with minimal buffering.
Architecture: Microservices (for uploading, encoding, storage, streaming). Video files are stored in a distributed storage system, and a CDN (Content Delivery Network) caches popular videos for global delivery. Metadata (video info, user data) is stored in databases.
Scalability: Offload bandwidth via the CDN for popular content. Scale out backend services horizontally by adding encoding and streaming servers. Shard the metadata database and cache frequent queries (e.g. popular video lists) to handle read load.
Data: Replicate video content across data centers for fault tolerance. Use NoSQL databases for high-volume data like view counts or comments (where eventual consistency is acceptable), and SQL for critical data like user accounts. The system favors availability – users should be able to watch videos even if a few analytics updates lag.
Security: Enforce access control (e.g. private or unlisted videos only accessible to authorized users). Serve content over HTTPS to protect data in transit. Store multiple copies of each video (no single copy loss) and monitor the system for any failures or content violations.

Learn how to design YouTube.

3. Design Google Drive

Requirements: Cloud file storage service for uploading, downloading, and sharing files. Should scale to millions of users and ensure high durability (no data loss).
Architecture: Uses a distributed file system: a metadata service (tracking file directories, versions, permissions) and storage nodes that store file chunks. Clients interact via an API server which coordinates file uploads/downloads using these components.
Scalability: Shard files across multiple storage servers (e.g. by user ID or file ID) so each server handles a subset of files. Add storage nodes as data volume grows. Cache hot files and metadata to speed up frequent accesses.
Data: Strong consistency for metadata (to avoid conflicting updates when users edit or move files). File data is replicated to multiple servers – eventual consistency for those replicas is acceptable as long as the latest version is retrieved on access. The design favors consistency for file updates, but uses replication and failover so that service stays available even if a node goes down.
Security: Encrypt files at rest and in transit to protect user data. Enforce sharing permissions and authentication for file access. Maintain multiple replicas and regular backups of each file so no single failure causes data loss. Fault-tolerance (failover to backup servers) ensures reliability.

Learn how to design Dropbox.

4. Design a Web Search Engine

Requirements: Crawl the web, index webpages, and serve user search queries with relevant results. Must handle billions of pages indexed and millions of queries per second with very low latency.
Architecture: The system is split into a web crawler (fetches pages and follows links), an indexing pipeline (processes pages and builds an inverted index of terms -> documents), and query servers that handle search requests by looking up the index and ranking results. Supporting components include a ranking algorithm and a cache for popular queries.
Scalability: Use many crawler instances in parallel to cover the web quickly (distributed crawling). Partition the index across many servers (shard by terms or by document ID ranges) so that queries can be processed in parallel. Deploy query servers in multiple data centers globally and load balance queries among them. Use caching for frequent search queries to reduce load and latency.
Data: The index is updated continuously as new pages are crawled – this is an eventually consistent process (some newest pages might not appear immediately). The system prioritizes availability: it should return some results even if a portion of the index is temporarily unreachable or slightly stale . Distributed storage systems (like Bigtable or similar NoSQL stores) hold the index to allow horizontal scaling.
Security: Use HTTPS for search queries to protect user privacy. Employ safeguards in the crawler (e.g. sandboxing or filtering) so that malicious pages do not harm the system. Ensure reliability by replicating index data and having multiple redundant query servers – if one server or data shard fails, others take over so the search service remains up.

5. Design a URL Shortener

Requirements: Service to create short links that redirect to long URLs. It is a read-heavy system (lots of redirects) with comparatively fewer writes (URL creations). It should be extremely fast and able to handle very high QPS for redirects.
Architecture: A simple web service with an application layer and a database. When a user submits a URL to shorten, the service generates a unique short code (e.g. by incrementing an ID or using a hash) and stores the mapping {code -> original URL} in a database. For redirection, a request to the short URL looks up the mapping in the database (possibly via a cache) and issues an HTTP redirect to the original URL.
Scalability: Introduce a cache for popular short URLs so repeated redirects don’t hit the database every time (improving latency and throughput). Partition the database or use multiple database servers if the number of stored URLs becomes very large (e.g. shard by code range). Deploy multiple instances of the application service behind a load balancer to handle many concurrent requests. Use a robust unique ID generator (perhaps pre-allocating ID blocks to each server) to avoid collisions when generating short codes.
Data: Ensure consistency in the code-to-URL mapping – each short code should always map to the correct original URL (use transactions or locks when inserting new entries to avoid duplicates). Given the critical mapping data is relatively small, a single relational database can suffice (ensuring ACID properties). For high availability, replicate this database to a secondary (read replica); if the primary goes down, the system can still perform read operations (redirects) from the replica. The data store is a single source of truth, so backups are taken regularly in case of corruption.
Security: Validate and sanitize URLs on input (to prevent malware or JavaScript injections via data URIs). Implement rate limiting on the URL creation API to prevent abuse (e.g. someone mass-generating links or trying to flood the system). Use HTTP status codes (301/302) correctly for redirects. For reliability, maintain database backups and consider a failover mechanism to a secondary data center — so even if the main database is down, existing short links continue to work (perhaps via a cached copy or replica).

Learn how to design URL Shortener.

Requirements: Users post content (status updates, photos, etc.), and their friends/followers see these posts in a news feed. The system must handle a high volume of writes (posts, likes) and deliver updates to users’ feeds with low latency (near real-time experience).
Architecture: Core components include a User service (manages user profiles and follow relationships), a Post service (handles creating and storing posts), and a Feed service (aggregates posts for each user’s feed). Two common approaches for feed generation: push (fan-out) – where the system pushes new posts to all followers’ feed storage when a post is made, or pull – where each user’s feed is computed on-the-fly when they request it. In practice, a hybrid is used. Data is stored in a posts database and a feed database (which might store lists of post IDs for each user).
Scalability: Use asynchronous processing for fan-out. For example, when a user with many followers posts, put the fan-out tasks into a queue and have worker servers update followers’ feeds in the background. shard users across multiple feed generation servers (e.g. by user ID) to spread the load of feed updates. Employ caching for feeds that are accessed frequently (e.g. cache the timeline for active users so it doesn’t need to be recalculated often). Scale the system horizontally by adding more workers and feed servers as the user base grows.
Data: The feed data can be eventually consistent – it’s okay if a new post appears in your followers’ feeds after a few seconds. The system prioritizes availability and throughput over absolute immediacy. Use a NoSQL datastore for feed entries to handle high write rates (e.g. appending post IDs to many feeds) and to allow easy horizontal scaling. Ensure that within each user’s feed, posts are in the correct order (usually chronological or by rank). To be reliable, duplicate data across data centers or use distributed databases with replication – so if one server fails, the feed data isn’t permanently lost and can be served from elsewhere.
Security: Enforce privacy settings – e.g. if a user’s posts are friends-only, ensure that only their connections have those posts in their feeds. All feed read and write requests should be authenticated (a user can fetch only their own personalized feed). For reliability, implement monitoring on the feed distribution pipeline – if feed updates are lagging or a queue is backing up, engineers should be alerted. Also have fallback logic: if the push model is delayed, the app can fetch some posts on demand (pull) to avoid completely stale feeds.

Learn how to design Twitter.

7. Design a Chat Service (Messenger)

Requirements: A real-time chat/messaging service for one-to-one and group conversations. It should support instant message delivery with very low latency and guarantee that messages are not lost. It also needs to handle a large number of simultaneous connections (potentially millions of users online).
Architecture: Use a persistent connection for each active user – typically via WebSockets or long-lived TCP connections. Clients connect to chat server instances which manage messaging sessions. A message router/service sits in the backend: when a user sends a message, the router finds the recipient’s active connection (which might be on another server) and delivers it; for a group chat, it replicates the message to all group members. A database stores messages and conversation history (so users can retrieve past messages or offline users can get messages when they come online).
Scalability: Since each server can only hold a certain number of active connections, the system scales by adding many chat servers. Users can be partitioned (sharded) by some ID hash or region so that each server handles a subset of users. Use a load balancer or connection gateway to direct a user’s connection to an appropriate server. For delivering messages across servers, use a publish/subscribe mechanism or a message queue – e.g. when a server receives a message for a user on another server, it publishes to a channel that the target server subscribes to (or makes a direct API call). The message database can be sharded by user or conversation ID to distribute writes and storage. Caching can also be used for recent messages or user presence info.
Data: Within a single chat conversation, message order and delivery must be consistent. Commonly, a sequence ID or timestamp is attached to each message, and messages for a conversation might be routed through the same server (sticky routing) to maintain order. The system opts for availability: if one chat server goes down, users connected there should reconnect to a backup server and continue – they might temporarily lose connection, but the messages should be queued or retried. Use acknowledgements: the client or server acknowledges each message delivery, and if an ack isn’t received, the message is retried (to prevent loss). Message data is replicated to ensure it’s not lost (e.g. write to two datastores or to primary and backup data centers). Some eventual consistency is acceptable (for example, if two users are in different regions, one might see a message a second later due to cross-region replication, but it’s delivered).
Security: Use TLS encryption for all connections to protect messages in transit. Optionally, implement end-to-end encryption so that even the servers can’t read message content (this adds complexity in key management). All users must authenticate (e.g. via tokens) to connect and send messages, and authorization checks ensure you can only join chats you’re a member of. To further ensure reliability, implement mechanisms to prevent spam or abuse (rate limiting messages, allowing users to block others). Monitor connection stability and message delivery latency – the system should alert if messages start getting delayed or dropped.

Learn how to design Messenger.

8. Design a Distributed Web Cache

Requirements: A caching layer to store frequently accessed web content (e.g. database query results, HTML fragments, images) in memory to reduce latency and offload backend databases. The cache should handle very high request rates and provide fast lookups and writes. It should also allow cache entries to expire or be invalidated when data changes.
Architecture: Use a distributed in-memory cache cluster. This could be based on something like Memcached or Redis but scaled out to many nodes. Data is cached as key-value pairs. A consistent hashing mechanism maps each key to one of the cache nodes, which allows the cache to scale horizontally (and minimizes key redistribution when nodes are added or removed). Application servers first check the cache; on a cache hit, the value is returned quickly; on a cache miss, the app fetches from the database (or downstream service), then stores the result in the cache for next time. Optionally, each application server might also have a small local cache (L1 cache) while the distributed cluster acts as an L2 cache.
Scalability: To scale, simply add more cache nodes. Consistent hashing ensures new nodes can be added with minimal disruption (keys get remapped evenly). If read throughput is extremely high on some keys, you can replicate those keys on multiple nodes or use a hierarchical cache (where multiple cache servers can serve the same data). Deploy cache clusters in multiple regions (such as one cluster per data center) so users fetch data from a nearby cache. Also, tune item TTL (time-to-live) values and memory limits to balance between hit rate and cache size.
Data: Consistency: A cache is typically an eventually consistent layer – if the underlying data changes, a cached value might be stale for a short time. To mitigate this, use short TTLs or have the application explicitly invalidate cache entries when there are writes to the database (write-through or write-around cache strategies). For critical data that must be fresh, it might bypass the cache or use cache validation. Availability: The caching system should be built to favor availability – if the cache cluster experiences a problem or a node is down, the application can still retrieve data from the source (though slower). Partition tolerance is important: if network partitions occur, some cache nodes might not be reachable, in which case those requests will be cache misses and go to the database. The system should continue functioning (with perhaps higher latency) rather than fail.
Security: Restrict access to the cache servers – only application servers should be able to query them (to prevent unauthorized access or poisoning of cache entries). If sensitive data is cached, ensure it’s handled appropriately (for instance, in some cases data might be encrypted in cache, or not cached at all). For reliability, monitor cache performance metrics (hit rate, latency, memory usage). Have routines to handle node failures (e.g. auto-detect a failed cache node and redistribute its keys among the remaining nodes). A cache failure should not bring the whole system down – it will just increase load on the database, so ensure your database can handle that traffic temporarily or have a fallback strategy.

9. Design an Online Advertising System

Requirements: A system to serve relevant advertisements (for example, on search results pages or websites). It should match user queries or page context with ads in real time and conduct an auction to pick the best ads. Non-functional needs: extremely low latency (ads must be returned in a few milliseconds so as not to slow down page loads), the ability to handle a huge number of requests, and accurate tracking of clicks and impressions for billing.
Architecture: Key components include an Ad inventory database (storing ads, campaigns, targeting keywords, bids, budgets), an indexing and matching service to retrieve candidate ads for a given query or user context (similar to a search engine for ads), an auction engine to rank those ads (based on bid and ad quality score) and select winners, and an ad delivery service to return the ad content/links to the user. There is also a logging and reporting pipeline to record each ad impression and any clicks (for billing and analytics). When a user makes a request (e.g. a search query), the system matches relevant ads, runs the auction, and outputs the top ads all within a few milliseconds.
Scalability: Partition the ad index to handle scale – for instance, index ads by keyword such that queries can be looked up in parallel on multiple servers (each handling a subset of keywords). Use caching for popular queries and ads. The auction process must be very fast; it can be distributed by having each index server pre-score its top candidates, then a central aggregator picks the final winners. Deploy the ad serving system across multiple data centers worldwide to reduce latency for users and provide redundancy. The system should be horizontally scalable – as the number of advertisers and traffic grows, add more index servers and auction servers. Streaming systems handle updates (like budget changes or new ads) to propagate to the serving nodes in near real-time.
Data: Consistency vs availability is critical because of money involved. Consistency: Ensure that actions like budget deduction and click counting are accurate – these likely use strongly consistent transactions (often on SQL databases or transactional systems) to avoid overcharging or overspending. However, the ad selection path leans toward availability – it’s better to show an ad that might be slightly out-of-date (e.g. an advertiser just paused it a second ago) than to show no ad at all, since an outage means lost revenue. Thus, the system might use eventual consistency for propagating ad updates to all serving nodes (an ad might run for a short time after being paused, but that’s usually acceptable). All impression and click events are logged to durable storage (and often to multiple systems for backup) to ensure billing data is safe. The system also needs to uphold the business rules (like not exceeding an advertiser’s budget – which is a consistency challenge achieved by centralized budget accounting or frequent synchronization).
Security: Protect against misuse and fraud – for example, ensure that the ad content delivered doesn’t contain malware, and implement click fraud detection (to identify bots or malicious repeated clicks). Safeguard user privacy – if the system uses user data for ad targeting, it must comply with privacy policies (e.g. not logging sensitive query data inappropriately). In terms of reliability, design for no single point of failure: use redundant servers for each component (multiple matchmaking servers, multiple auction servers, etc.), and have failover strategies if one data center goes down (traffic can be routed to another region’s ad servers). Constant monitoring is required – both for technical issues (latency spikes, error rates) and for business metrics (an unusual drop in ad impressions might indicate a serving problem).

10. Design an Email Service (e.g. Gmail)

Requirements: A service for sending and receiving emails, with features like attachments, inbox search, and spam filtering. It must guarantee reliability (emails should never be lost), scale to a huge number of users and messages, and provide reasonable performance in delivering and retrieving mail.
Architecture: The system can be broken into Mail Transfer Agents (MTAs) – servers that handle sending and receiving emails over the internet via SMTP, Mail Delivery Agents (MDAs) – processes that route incoming mail to the proper user mailbox storage, and mail storage servers that hold users’ mailboxes (emails, folders, indexes). Users access their email via application servers (for webmail UI or IMAP/POP protocols) which fetch from the mail storage. There’s also a spam filter service that processes incoming mail to filter out junk, and a search indexing service that allows fast keyword search within emails.
Scalability: Distribute user mailboxes across many storage servers (for example, partition by user last name initial, or hash of username). Each mail storage server thus handles a subset of users, and we can add more servers as the user base grows. Use multiple MTA servers for sending/receiving mail concurrently (with MX records in DNS pointing to several servers for redundancy). Web and IMAP servers can be stateless and scaled out behind load balancers to handle many simultaneous users. The search index can be partitioned similarly (perhaps one index server per group of mailboxes). Caching can be employed for frequently accessed emails or user metadata to reduce load on storage.
Data: Emails must be stored durably – typically an email is written to at least two different storage servers (primary and replica) before the system acknowledges it as received, to protect against server crashes. Within a single mailbox, strong consistency is required (if you move an email to a folder, a refresh should immediately reflect that). However, the system overall uses eventual consistency for distributing data to backups or secondary data centers (for disaster recovery) – e.g. an email might be immediately stored in one data center and later synced to another. The system favors consistency when accepting or showing a user their mail (you should not lose or show duplicate emails), and uses high availability techniques like queueing: if a mailbox server is down, incoming emails for that server’s users can be queued on another server or retried later (so they aren’t lost). All sent/received events are logged so you can reconstruct if needed.
Security: Use TLS encryption for all connections (SMTP exchanges, IMAP/POP, and web) to prevent eavesdropping. Require user authentication for retrieving mail and sending (to avoid being an open relay). Store passwords securely (hashed) and support two-factor authentication for accounts. Integrate strong spam and virus filtering to protect users. For reliability, maintain multiple mail servers – if one goes down, others can accept incoming mail (so emails aren’t bounced). Each user’s mailbox has replicas; if the primary fails, a replica can take over as the new primary. Regular backups are performed, and an archival system might store emails in long-term storage. Monitoring is crucial: track mail delivery latency, queue lengths, server health, etc., and have alerts for anomalies (for instance, if emails aren’t being delivered or a server is down) so issues can be resolved quickly.

Discover Google system design interview tips.

Recommended Courses

Best Practices for Answering Google System Design Questions

When tackling system design questions in a Google interview, keep these tips in mind:

Start with Clarifying Questions: Begin by clarifying the scope and goals of the system. Identify the functional requirements (what features the system must provide) and the non-functional requirements (expected scale, latency, throughput, etc.) before jumping into design. This shows you think systematically about the problem.
Use a Structured Framework: Organize your answer by topics (e.g. requirements, architecture, scaling, data, reliability, etc.). This helps you cover all important aspects methodically. For example, first outline the high-level design, then discuss how to scale it, then talk about data storage choices, and so on.
Discuss Trade-offs and Alternatives: There is often more than one way to design a system. Explain the pros and cons of different approaches. For instance, would you use SQL or NoSQL for a particular component, and why? How would you balance consistency vs availability in that context (remember the CAP theorem) ? By discussing alternatives, you show deeper understanding.
Address Security & Reliability: Don’t neglect security, fault tolerance, and monitoring. Even if not explicitly asked, mention how you’d secure user data (authentication, encryption) and ensure the system is reliable (redundancy, backups, failover, metrics). This demonstrates that you’re considering the system in a real-world context where things can go wrong.

(Quick Reference Framework:)

Aspect	Key Points to Cover
Requirements	Functional (features, use cases) and Non-functional (scale, latency, uptime) needs. Clarify what problem the system must solve.
High-Level Design	Main components and their interactions (clients, servers, databases, external services). Consider using a simple diagram to illustrate data flow.
Scalability & Performance	How to handle growth: use horizontal scaling (more servers), sharding/partitioning data, load balancing, caching, and CDNs to meet performance targets.
Data (Storage & Consistency)	Storage technologies (SQL vs NoSQL, blob storage, etc.), data schema, and replication. Discuss how you’d ensure data consistency or tolerate eventual consistency (CAP theorem considerations).
Security & Reliability	Security measures (authentication, authorization, encryption) and reliability measures (redundant components, failover strategies, backups, monitoring).

Covering each of the areas above will help you deliver a well-rounded answer that touches on what Google interviewers expect.

Final Thoughts

Acing a Google system design interview comes down to structured thinking and practice.

Always start by clarifying requirements and constraints, then outline a high-level solution, and finally dive into specific considerations like scaling, data storage, and trade-offs.

Remember that the interviewer cares less about the exact solution and more about your reasoning process – they want to see that you can logically break down a complex problem.

Keep your explanations clear and concise. If you can explain a complicated system in simple terms, it shows true understanding.

Use the sample questions above to practice applying the same 5-step approach: Requirements → Architecture → Scalability → Data → Security.

By practicing different scenarios, you’ll build the confidence and flexibility to tackle any system design question. Good luck, and happy designing!