SYSTEM DESIGN

INTERVIEW
TEMPLATE
A step-by-step guide to
System Design Interviews
 Step 1. Clarify Requirements
Start by clarifying functional and non-functional
requirements. Here are things to consider:

Functional Requirements:
What are the core features that the system
should support?
Who are the users (eg.. customers, internal teams
etc.)?
How will users interact with the system (eg.. web,
mobile app, API, etc.)?
What are the key data types the system must
handle (text, images, structured data, etc).
Are there any external systems or third-party
services the system needs to integrate with?

Non-Functional Requirements:
Is the system read heavy or write heavy and
what’s the read-to-write ratio?
Can the system have some downtime, or does it
need to be highly available?
Are there any specific latency requirements?
How critical is data consistency?
Should we rate limit the users to prevent abuse of
the system?
Why It Matters — Step 1 — Clarify Requirements
Added notes explaining how each point on the previous page contributes to a well-rounded system design.

Functional Requirements
• What are the core features that the system should support?
■ Why it matters: This defines the scope of the problem. A perfect design is scoped correctly — too broad and
you'll run out of time and dilute the depth of your answer; too narrow and you'll miss requirements the interviewer
expected you to cover.

• Who are the users (e.g., customers, internal teams, etc.)?

■ Why it matters: Different user types have different access patterns, security needs, and scale. Knowing who
you're designing for lets you prioritize the right features and trade-offs instead of guessing.

• How will users interact with the system (e.g., web, mobile app, API, etc.)?
■ Why it matters: The interaction channel affects protocol choice, payload size, latency tolerance, and
offline/connectivity handling — all of which ripple into your API and network design.

• What are the key data types the system must handle (text, images, structured data, etc.)?
■ Why it matters: Data type drives storage choice. Structured data points you toward relational stores; large
binary blobs point toward object storage/CDNs. Getting this right avoids redesigning your storage layer later.

• Are there any external systems or third-party services the system needs to integrate with?
■ Why it matters: External dependencies introduce latency, failure modes, and rate limits outside your control.
Identifying them early lets you design for graceful degradation and retries instead of treating them as an
afterthought.

Non-Functional Requirements
• Is the system read heavy or write heavy, and what's the read-to-write ratio?
■ Why it matters: This single ratio quietly decides your architecture: read-heavy systems lean on caching and
read replicas, write-heavy systems lean on write-optimized stores, queues, and sharding strategies.

• Can the system have some downtime, or does it need to be highly available?
■ Why it matters: Availability requirements determine how much redundancy, failover, and complexity is justified.
Over-engineering for five-nines when the business tolerates downtime wastes interview time and real-world
budget alike.

• Are there any specific latency requirements?

■ Why it matters: Latency targets tell you where caching, CDNs, edge compute, or in-memory stores are
mandatory versus optional — a perfect design spends complexity only where the latency budget demands it.

• How critical is data consistency?

■ Why it matters: This decides where you sit on the CAP trade-off. Strong consistency needs (e.g., banking) push
you toward synchronous replication and locking; eventual consistency needs (e.g., social feeds) unlock much
higher scalability.

• Should we rate limit the users to prevent abuse of the system?

■ Why it matters: Rate limiting protects backend capacity, keeps costs predictable, and prevents a small number
of bad actors from degrading the experience for everyone else — a hallmark of a production-grade design.
 Step 2. Capacity Estimation

Estimate capacity to get an overall idea about how

big a system you are going to design.

This can include things like:

How many users are expected to use the system
daily and monthly and maximum concurrent
users during peak hours?
Expected read/write requests per second.
Amount of storage you would need to store all
the data.
How much memory you might need to store
frequently accessed data in cache.
Network bandwidth requirements based on the
estimated traffic volume and data transfer sizes.

Note: Check with the interviewer if capacity

estimation is necessary.
Why It Matters — Step 2 — Capacity Estimation
Added notes explaining how each point on the previous page contributes to a well-rounded system design.

• How many users are expected to use the system daily and monthly, and what is the maximum
concurrent users during peak hours?
■ Why it matters: User counts translate directly into server, database, and load balancer sizing. Without this
number you can't credibly argue for horizontal scaling, sharding, or a particular instance count.

• Expected read/write requests per second.

■ Why it matters: Throughput requirements determine how many application server instances you need and
whether a single database can keep up or whether you need read replicas, caching, or sharding to absorb the
load.

• Amount of storage you would need to store all the data.

■ Why it matters: Storage volume over time informs whether you need a single database instance, horizontal
partitioning, or cold/hot data tiering — and it drives real cost estimates.

• How much memory you might need to store frequently accessed data in cache.
■ Why it matters: Cache sizing tells you whether an in-memory cache like Redis can hold your hot dataset
entirely, or whether you need eviction policies and a multi-tier caching strategy.

• Network bandwidth requirements based on the estimated traffic volume and data transfer sizes.
■ Why it matters: Bandwidth estimates reveal whether you need a CDN, compression, or regional deployments to
avoid becoming network-bound rather than compute-bound.
 Step 3. High-Level Design

Sketch out a simple block diagram that outlines the

major system components like:

1. Clients: User-facing interfaces (eg.. mobile, pc)

2. Application Servers: To process client requests.
3. Load Balancers: To distribute incoming traffic
across multiple servers.
4. Services: Specialized components performing
specific functions.
5. Databases: To store user information and
metadata.
6. Storage: To store files, images or videos.
7. Caching: To improve latency and reduce load on
the database.
8. Message Queues: If using asynchronous
communication.
9. External Services: If integrating with third-party
APIs (e.g., payment gateways).
Why It Matters — Step 3 — High-Level Design
Added notes explaining how each point on the previous page contributes to a well-rounded system design.

• Clients: user-facing interfaces (e.g., mobile, pc).

■ Why it matters: Naming the client explicitly reminds you to consider device constraints — battery, intermittent
connectivity, screen real estate — which shape API design and payload size.

• Application Servers: to process client requests.

■ Why it matters: This is where business logic lives. Keeping it stateless is what makes horizontal scaling and
easy failover possible later.

• Load Balancers: to distribute incoming traffic across multiple servers.

■ Why it matters: Load balancers remove any single application server as a bottleneck or single point of failure,
which is essential for both scalability and availability.

• Services: specialized components performing specific functions.

■ Why it matters: Splitting responsibilities into services lets each part scale, deploy, and fail independently — a
core enabler of resilience in larger systems.

• Databases: to store user information and metadata.

■ Why it matters: The database is usually the hardest component to scale after the fact, so flagging it explicitly up
front forces you to think about it early rather than bolting it on later.

• Storage: to store files, images, or videos.

■ Why it matters: Separating blob storage from your primary database keeps the database small and fast, and
lets you use storage systems (e.g., object storage + CDN) purpose-built for large files.

• Caching: to improve latency and reduce load on the database.

■ Why it matters: Caching is often the single highest-leverage addition for latency and cost — it converts
expensive database reads into cheap memory reads.

• Message Queues: if using asynchronous communication.

■ Why it matters: Queues decouple producers from consumers, smooth out traffic spikes, and let you retry failed
work — all of which improve both reliability and perceived latency.

• External Services: if integrating with third-party APIs (e.g., payment gateways).

■ Why it matters: Calling out external services on the diagram is a reminder that they are a dependency outside
your SLA — you'll need timeouts, retries, and fallbacks around them.
 Step 4. Database Design
This steps involve modeling the data, choosing the
right storage for the system, designing the database
schema and optimizing the storage and retrieval of
data based on the access patterns.

Data Modeling

Identify the main data entities or objects that the

system needs to store and manage (e.g., users,
products, orders).
Consider the relationships between these
entities and how they interact with each other.
Determine the attributes or properties
associated with each entity (e.g., a user has an
email, name, address).
Identify any unique identifiers or primary keys
for each entity.
Consider normalization techniques to ensure
data integrity and minimize redundancy.
Why It Matters — Step 4 — Database Design (Data Modeling)
Added notes explaining how each point on the previous page contributes to a well-rounded system design.

Data Modeling
• Identify the main data entities or objects that the system needs to store and manage (e.g., users,
products, orders).
■ Why it matters: A clear list of entities is the foundation of the schema — missing an entity here means reworking
the design mid-interview when a requirement surfaces that has nowhere to live.

• Consider the relationships between these entities and how they interact with each other.
■ Why it matters: Relationships (one-to-many, many-to-many) determine whether you need join tables, foreign
keys, or denormalized references, and they directly affect query complexity.

• Determine the attributes or properties associated with each entity (e.g., a user has an email, name,
address).
■ Why it matters: Concrete attributes let you reason about row size, indexing needs, and validation rules instead
of leaving the schema abstract and untestable.

• Identify any unique identifiers or primary keys for each entity.

■ Why it matters: Primary keys are what make sharding, replication, and efficient lookups possible — choosing
them thoughtfully (e.g., UUID vs. auto-increment) avoids hotspotting at scale.

• Consider normalization techniques to ensure data integrity and minimize redundancy.

■ Why it matters: Normalization prevents update anomalies and keeps data consistent; knowing when to
deliberately denormalize later (for read performance) shows you understand the trade-off rather than applying
rules blindly.
 Choose the Right Storage

Evaluate the requirements and characteristics of

the data to determine the most suitable database
type.
Consider factors such as data structure,
scalability, performance, consistency, and query
patterns.
Relational databases (e.g., MySQL, PostgreSQL)
are suitable for structured data with complex
relationships and ACID properties.
NoSQL databases (e.g., MongoDB, Cassandra) are
suitable for unstructured or semi-structured
data, high scalability, and eventual consistency.
Consider using a combination of databases if
different data subsets have distinct
requirements.
Why It Matters — Step 4 — Database Design (Choose the Right
Storage)
Added notes explaining how each point on the previous page contributes to a well-rounded system design.

Choose the Right Storage

• Evaluate the requirements and characteristics of the data to determine the most suitable database
type.
■ Why it matters: Matching the storage engine to the data's actual shape (relational, key-value, document, graph,
column) avoids fighting the database later for queries it wasn't built to serve.

• Consider factors such as data structure, scalability, performance, consistency, and query patterns.
■ Why it matters: These five factors are the real decision criteria interviewers listen for — citing them shows you're
choosing a database deliberately, not just because it's popular.

• Relational databases (e.g., MySQL, PostgreSQL) are suitable for structured data with complex
relationships and ACID properties.
■ Why it matters: Reach for relational stores when transactions must be atomic and consistent — e.g., financial
transfers or inventory counts where correctness beats raw throughput.

• NoSQL databases (e.g., MongoDB, Cassandra) are suitable for unstructured or semi-structured data,
high scalability, and eventual consistency.
■ Why it matters: Reach for NoSQL when you need to scale writes horizontally or the schema will evolve quickly
— you trade some consistency guarantees for elasticity and throughput.

• Consider using a combination of databases if different data subsets have distinct requirements.
■ Why it matters: Polyglot persistence — e.g., relational for orders, key-value for sessions, search index for
full-text — lets each part of the system use the tool best suited to it instead of forcing one database to do
everything.
 Step 5. API Design
Define how different components of the system
interact with each other and how external clients can
access the system's functionality.

List down the APIs you want to expose to external

clients based on the problem.

Select an appropriate API style based on the

system's requirements and the clients' needs (eg..
RESTful, GraphQL, RPC).

Choose Communication Protocols:

HTTPS: Commonly used for RESTful APIs and

web-based communication.
WebSockets: Useful for real-time, bidirectional
communication between clients and servers (e.g.,
chat applications).
gRPC: Efficient for inter-service communication
in microservices architectures.
Messaging Protocols: AMQP, MQTT for
asynchronous messaging (often used with
message queues).
Why It Matters — Step 5 — API Design
Added notes explaining how each point on the previous page contributes to a well-rounded system design.

Choose Communication Protocols

• HTTPS: commonly used for RESTful APIs and web-based communication.
■ Why it matters: HTTPS is the default choice for public-facing APIs because of its ubiquity, caching support, and
broad tooling — pick it unless a requirement (real-time, high-performance internal calls) argues otherwise.

• WebSockets: useful for real-time, bidirectional communication between clients and servers (e.g., chat
applications).
■ Why it matters: WebSockets avoid the overhead of repeated polling, which is essential when latency for live
updates (chat, live scores, collaborative editing) needs to be near-instant.

• gRPC: efficient for inter-service communication in microservices architectures.

■ Why it matters: gRPC's binary protocol and strict schemas (via protobuf) make internal service-to-service calls
faster and less error-prone than JSON-over-HTTP, which matters at high internal call volumes.

• Messaging Protocols: AMQP, MQTT for asynchronous messaging (often used with message queues).
■ Why it matters: These protocols support fire-and-forget or publish/subscribe patterns, which is what lets you
decouple services and absorb traffic spikes asynchronously rather than blocking callers.

Define the API Surface

• List down the APIs you want to expose to external clients based on the problem.
■ Why it matters: Enumerating concrete endpoints forces you to verify that every functional requirement from Step
1 actually has a corresponding way for a client to trigger it.

• Select an appropriate API style based on the system's requirements and the clients' needs (e.g.,
RESTful, GraphQL, RPC).
■ Why it matters: The right style reduces over-fetching (GraphQL for flexible clients), keeps things simple and
cacheable (REST for standard CRUD), or minimizes latency for tightly coupled internal calls (RPC) — matching
style to need is what separates a thoughtful API from a default one.
 Step 6. Dive Deep into Key
Components
Your interviewer will likely want to focus on specific
areas so pay attention and discuss those things in
more detail.
It can differ based on the problem.

For example: if you are asked to design a url

shortener, the interviewer will most likely want you
to focus on the algorithm for generating short urls.

And, if the problem is about designing a chat

application, you should talk about how the messages
will be sent and received in real time.

Here are some more common areas of deep dives:

Databases: How would you handle a massive
increase in data volume? Discuss sharding
(splitting data across multiple databases),
replication (read/write replicas).
Application Servers: How would you add more
servers behind the load balancer for increased
traffic?
Caching: Where would you add caching to reduce
latency and load on the database and how would
you deal with cache invalidation?
Why It Matters — Step 6 — Dive Deep into Key Components
Added notes explaining how each point on the previous page contributes to a well-rounded system design.

• Databases: how would you handle a massive increase in data volume? Discuss sharding (splitting
data across multiple databases) and replication (read/write replicas).
■ Why it matters: Sharding and replication are the two levers that let a database scale past a single machine's
limits — sharding scales writes and storage, replication scales reads and adds redundancy.

• Application Servers: how would you add more servers behind the load balancer for increased traffic?
■ Why it matters: Explaining how stateless app servers scale horizontally behind a load balancer shows the
design can absorb traffic growth without a full architectural rewrite.

• Caching: where would you add caching to reduce latency and load on the database, and how would
you deal with cache invalidation?
■ Why it matters: Cache placement determines how much latency you save; a solid invalidation strategy (TTL,
write-through, event-based) is what prevents stale data from becoming a bug in production.

• Match your deep dive to the problem — e.g., focus on the short-URL generation algorithm for a URL
shortener, or real-time message delivery for a chat application.
■ Why it matters: Tailoring the deep dive to the problem's unique hard part — rather than a generic checklist — is
exactly what distinguishes a strong candidate from one reciting a template.
 Step 7. Address Key Concerns
This step involves identifying and addressing the
core challenges that your system design is likely to
encounter.

These challenges can range from scalability and

performance to reliability, security, and cost
concerns.

Addressing Scalability and Performance Concerns:

Scale vertically (Scale-up) by increasing the

capacity of individual resources (e.g., CPU,
memory, storage).
Scale horizontally (Scale-out) by adding more
nodes and use load balancers to evenly distribute
the traffic among the nodes.
Implement caching to reduce the load on
backend systems and improve response times.
Optimize database queries using indexes.
Denormalize data when necessary to reduce join
operations.
Use database partitioning and sharding to
improve query performance.
Utilize asynchronous programming models to
handle concurrent requests efficiently.
Why It Matters — Step 7 — Address Key Concerns (Scalability &
Performance)
Added notes explaining how each point on the previous page contributes to a well-rounded system design.

Addressing Scalability and Performance Concerns

• Scale vertically (scale-up) by increasing the capacity of individual resources (e.g., CPU, memory,
storage).
■ Why it matters: Vertical scaling is the simplest first lever — no architectural change required — but knowing its
ceiling is what tells you when to reach for horizontal scaling instead.

• Scale horizontally (scale-out) by adding more nodes and using load balancers to evenly distribute
traffic among the nodes.
■ Why it matters: Horizontal scaling removes the hard ceiling of a single machine and, combined with load
balancing, is what lets a system grow to handle effectively unbounded traffic.

• Implement caching to reduce the load on backend systems and improve response times.
■ Why it matters: Caching cuts both latency and backend load at once, which is why it's usually the highest-return
optimization you can make before touching the database itself.

• Optimize database queries using indexes.

■ Why it matters: Proper indexing turns slow full-table scans into fast lookups, which is often the difference
between a database that scales and one that falls over under load.

• Denormalize data when necessary to reduce join operations.

■ Why it matters: Denormalization trades some redundancy and write complexity for much faster reads — the
right call when a system is read-heavy and joins are the bottleneck.

• Use database partitioning and sharding to improve query performance.

■ Why it matters: Partitioning keeps individual tables/indexes small enough to stay fast; sharding spreads load
across multiple machines so no single node becomes the bottleneck.

• Utilize asynchronous programming models to handle concurrent requests efficiently.

■ Why it matters: Async processing lets a server handle many in-flight requests without blocking threads on slow
I/O, which improves throughput and resource efficiency under concurrent load.
 Addressing Reliability

Analyze the system architecture and identify

potential single point of failures.
Design redundancy into the system components
(multiple load balancers, database replicas) to
eliminate single points of failure.
Consider geographical redundancy to protect
against regional failures or disasters.
Implement data replication strategies to ensure
data availability and durability.
Implement circuit breaker patterns to prevent
cascading failures and protect the system from
overload.
Implement retry mechanisms with exponential
backoff to handle temporary failures and prevent
overwhelming the system during recovery.
Implement comprehensive monitoring and
alerting systems to detect failures, performance
issues, and anomalies.
Why It Matters — Step 7 — Address Key Concerns (Reliability)
Added notes explaining how each point on the previous page contributes to a well-rounded system design.

Addressing Reliability
• Analyze the system architecture and identify potential single points of failure.
■ Why it matters: You can't fix what you haven't found — explicitly hunting for SPOFs is the first step toward a
design that keeps running when any one part fails.

• Design redundancy into the system components (multiple load balancers, database replicas) to
eliminate single points of failure.
■ Why it matters: Redundant components mean that when one instance fails, traffic simply routes to another —
turning a potential outage into a non-event for users.

• Consider geographical redundancy to protect against regional failures or disasters.

■ Why it matters: Multi-region deployment protects against outages that take down an entire data center or cloud
region, which single-zone redundancy alone cannot cover.

• Implement data replication strategies to ensure data availability and durability.

■ Why it matters: Replication means a copy of the data survives even if a node or disk is lost, protecting against
both downtime and permanent data loss.

• Implement circuit breaker patterns to prevent cascading failures and protect the system from
overload.
■ Why it matters: Circuit breakers stop calling a failing downstream service, giving it room to recover and
preventing one failure from cascading into a system-wide outage.

• Implement retry mechanisms with exponential backoff to handle temporary failures and prevent
overwhelming the system during recovery.
■ Why it matters: Backoff-based retries smooth over transient blips without hammering an already-struggling
service, which is what keeps recovery from turning into a self-inflicted second outage.

• Implement comprehensive monitoring and alerting systems to detect failures, performance issues,
and anomalies.
■ Why it matters: Monitoring and alerting turn silent failures into actionable signals, so problems get fixed in
minutes rather than being discovered by users hours later.