System Design Interview Questions With Worked Answers

System design interview questions test how you turn an ambiguous problem into a defensible architecture. A strong answer makes assumptions visible, follows requests through the system, and adds complexity only when a requirement demands it. This question bank gives you a repeatable framework, then applies it to a complete URL shortener system design.

What system design interview questions actually test#

Interviewers evaluate your design process more than your ability to guess a preferred architecture.

A useful discussion demonstrates six skills:

• Requirement discovery: You separate required behavior from optional features.
• Decomposition: You divide the system into components with clear responsibilities.
• Interface design: You define APIs, events, and boundaries between components.
• Data modeling: You choose entities, keys, indexes, and storage around access patterns.
• Bottleneck analysis: You identify what fails or slows down as load grows.
• Communication: You explain decisions, alternatives, and uncertainty as you work.

The goal is not to reproduce an architecture that the interviewer already knows. Many designs can satisfy the same requirements. Your task is to make each important choice traceable to a requirement.

Expectations vary with the role. A less experienced engineer may focus on a coherent request flow and basic failure handling. A senior candidate may need to discuss ownership boundaries, migrations, operational risks, and how the system evolves. Infrastructure roles often go deeper on reliability. Product-focused roles may spend more time on APIs and user-visible behavior.

A framework for answering any system design question#

A reliable system design interview framework moves from requirements to interfaces, then from a simple design to justified refinements.

Use this sequence:

1. Clarify behavior. What must users be able to do? What is excluded?
2. Characterize the workload. Ask about users, request mix, object size, retention, and traffic spikes.
3. Define quality requirements. Establish latency, availability, consistency, durability, and failure tolerance.
4. Write the interfaces. Define the main API calls or events.
5. Model the data. Identify entities, keys, relationships, and access patterns.
6. Draw the simplest complete design. Follow one request from entry to response.
7. Find pressure points. Examine storage, compute, network, contention, and dependencies.
8. Refine selectively. Add caches, queues, replicas, or partitions only when they solve a stated problem.
9. Summarize trade-offs. State what the design optimizes and what it gives up.

Check assumptions throughout. Say, “I am assuming redirects may be briefly stale after an update. Is that acceptable?” This turns an invisible guess into a design decision.

Foundational system design interview questions#

Foundational prompts surface recurring concepts such as API boundaries, state, caching, and asynchronous processing.

Design a URL shortener#

Concepts: key generation, read-heavy access, caching, expiration, redirects, and abuse controls.

Clarify: Are custom aliases supported? Can links change? Must expired aliases become reusable? Which redirect status should the service return?

Follow-ups: Cache popular redirects, partition by alias, replicate link records, and recover when the primary datastore is unavailable.

Design a rate limiter#

Concepts: counters, time windows, atomic updates, distributed coordination, and degraded behavior.

Clarify: Is the limit per user, API key, IP address, or endpoint? Must limits be exact across regions?

Follow-ups: Compare token bucket and sliding-window mechanisms. Discuss hot keys, local allowances, shared state, and failure policy when the counter store is unavailable.

Design a notification service#

Concepts: queues, channel adapters, user preferences, retries, and deduplication.

Clarify: Which channels exist? Are notifications transactional, scheduled, or best effort? Does ordering matter?

Follow-ups: Partition queues by recipient, apply retry backoff, route failed work to a dead-letter queue, and prevent duplicate delivery where possible.

Design a file storage service#

Concepts: metadata, object storage, multipart upload, permissions, and content delivery.

Clarify: What file sizes are expected? Is versioning required? Can users share files?

Follow-ups: Use object storage for bytes and a database for metadata. Discuss checksums, resumable uploads, replication, garbage collection, and authorization.

Design a real-time chat system#

Concepts: persistent connections, message ordering, presence, fan-out, and offline delivery.

Clarify: Is this direct chat, group chat, or both? What ordering guarantee applies? Are read receipts required?

Follow-ups: Partition conversations, store messages before delivery, queue offline work, and reconcile clients after reconnects.

Backend and data-intensive design questions#

Data-intensive prompts test whether you can match storage and processing mechanisms to concrete access patterns.

Search autocomplete#

Use a trie, ranked prefix index, or search index for prefix queries. Clarify update frequency, personalization, and acceptable staleness. Follow-ups include caching common prefixes, rebuilding indexes, and handling a prefix that receives disproportionate traffic.

Activity feed#

Ask whether feeds are generated on write, on read, or through a hybrid. An event log can preserve activity events. A key-value store can hold materialized feeds. Discuss celebrity-style fan-out, ranking, pagination, deduplication, and delayed processing.

Job scheduler#

Define execution time, recurrence, cancellation, and retry semantics. A relational database fits job metadata and state transitions. Workers can claim jobs with leases. Use idempotency keys because a crashed worker may execute work before losing its lease.

Metrics pipeline#

Agents batch measurements into a durable event log. Consumers aggregate by time window and write results to a time-series or analytical store. Discuss late events, ordering within a partition, retention, cardinality, backpressure, and what producers do when ingestion slows.

Payment workflow#

A relational database fits balances, payment state, and audit relationships that require transactions. Treat external requests as uncertain: a timeout does not prove failure. Persist an idempotency key, record every state transition, retry safely, and reconcile local state with the payment provider.

These software architecture interview questions are not storage-product quizzes. Explain why a mechanism fits:

• Relational database: transactions, constraints, and relationship-heavy queries.
• Key-value store: direct lookup by a stable key.
• Object storage: large immutable blobs.
• Search index: token, prefix, ranking, and filtering queries.
• Event log: ordered, replayable streams of state changes.

Worked answer: design a URL shortener#

A good URL shortener system design starts with the redirect contract, not a diagram full of infrastructure.

Requirements and exclusions#

Assume the service must:

• Create a short link for a valid destination URL.
• Redirect an alias to its destination.
• Support optional expiration and custom aliases.
• Reject reserved or abusive aliases.
• Keep redirects available during routine component failures.

Clarify whether links are editable, whether analytics are required, and whether expired aliases can be reused. Assume analytics are asynchronous and expired aliases remain reserved.

APIs and data model#

POST /links
{
  "destination_url": "...",
  "custom_alias": "...",
  "expires_at": "..."
}

201 Created
{
  "alias": "aZ81k",
  "short_url": "/aZ81k"
}

GET /{alias}
302 Location: destination_url

The link record contains:

alias
destination_url
created_at
expires_at
owner_id
status

Index the record by alias, because every redirect performs that lookup. A custom alias uses conditional insertion so concurrent requests cannot claim the same value.

For generated aliases, allocate a unique integer and encode it with a URL-safe alphabet. This avoids random collisions but exposes approximate creation order unless you transform the identifier. Random identifiers hide ordering but require collision detection and retry. State that trade-off rather than claiming one strategy is universally correct.

Initial architecture#

Start with four components:

1. A load balancer routes requests to stateless application instances.
2. The application validates creation requests and writes link records.
3. A durable datastore serves alias lookups.
4. A cache stores frequently requested alias-to-destination mappings.

The redirect path is simple:

1. Look up the alias in the cache.
2. On a miss, read the datastore.
3. Reject missing, disabled, or expired records.
4. Populate the cache with an expiration no later than the link expiration.
5. Return the redirect.

Analytics events go to a queue after the redirect decision. Slow analytics processing should not delay users.

Failures and scale#

Collisions: Use conditional writes. Generate another alias after a conflict.

Cache misses: Read from the datastore and repopulate the cache. Negative caching can reduce repeated lookups for invalid aliases, but keep its lifetime short.

Popular links: Replicated cache nodes absorb repeated reads. A single hot alias may still create uneven load, so replicate rather than partition that one cached value.

Expired links: Check expiration in both the cache policy and application. Do not rely on cache eviction alone.

Database failure: Existing cached links may continue redirecting. Cache misses and new links fail unless a replica can take over. Decide whether stale reads are acceptable during failover.

Partitioning: Partition by a hash of the alias when one datastore group no longer handles the workload. Hashing spreads generated and custom aliases more evenly than prefix-based ranges.

Regional deployment: Regional caches reduce redirect latency. Replicated records improve read availability, but link creation and custom-alias uniqueness need a clear write authority or cross-region coordination.

A concise interview summary would be:

The design uses stateless application servers, an alias-keyed durable store, and replicated caches for the read-heavy redirect path. Creation uses conditional writes for uniqueness. Analytics are asynchronous. The main unresolved decisions are identifier predictability, stale-read tolerance, alias reuse, and cross-region write coordination.

How to handle capacity and scale questions#

Capacity estimates should test architectural decisions, not your ability to invent precise traffic.

Ask the interviewer for:

• Peak and normal request rates.
• Redirect-to-creation ratio.
• Average URL and metadata size.
• Retention period.
• Traffic burst shape.
• Geographic distribution.

If exact values are unavailable, define labeled assumptions and keep the arithmetic rough. For example:

stored records = creations per day × retention days
storage = stored records × average record size
redirect bandwidth = redirects per second × average response size

Then connect the result to a decision. Storage volume may justify partitioning. A read-heavy request mix may justify caching and replicas. Bursty writes may justify a queue. Large objects may belong in object storage rather than database rows.

Stop calculating once the estimate answers the architectural question.

Common system design mistakes and how to repair them#

Most weak answers can be repaired by returning to requirements and tracing one request.

• Premature microservices: Start with logical components. Split deployment units only when scaling, ownership, or isolation requires it.
• Unexplained technology choices: Replace “use Kafka” with “use a durable event log so consumers can process independently and replay events.”
• Missing APIs: Pause and define the inputs, outputs, errors, and idempotency behavior.
• Ignored failures: Choose one dependency and explain timeout, retry, fallback, and recovery behavior.
• Diagram without flow: Narrate creation, successful read, cache miss, and dependency failure.
• Hidden assumptions: State the assumption and ask the interviewer to confirm it.

When a new requirement invalidates your design, do not defend the old one. Restate the change, identify the affected component, and revise it. That is good system design work.

A practice plan for system design interviews#

Build practice from bounded services toward workflows with distributed state.

Use this order:

1. URL shortener, rate limiter, and file storage.
2. Notifications, chat, and job scheduling.
3. Feeds, autocomplete, and metrics ingestion.
4. Payments and multi-region workflows.

For every prompt, write the same artifacts: requirements, exclusions, APIs, data model, request flow, bottlenecks, failures, and trade-offs. Finish with a short verbal summary.

Algorithm practice still helps when a design depends on indexing, traversal, heaps, or partitioning. Use the algorithm pattern reference to review those mechanics, or work through the NeetCode 150 list. The broader LeetCode reference is useful when a system design discussion exposes a coding topic you need to tighten.