Durgesh Tiwari
Author
When solving a System Design problem, many beginners immediately start discussing databases, microservices, caching, and load balancers.
However, experienced engineers follow a different approach.
Before designing any architecture, they first understand what needs to be built.
This process is called Requirements Gathering.
Requirements gathering helps engineers identify business goals, user needs, system constraints, and expected scale before making technical decisions.
A well-designed system starts with clear requirements. Without them, even a technically strong architecture can solve the wrong problem.
Consider the following interview question:
Design a Notification System
Many candidates immediately start drawing components such as:
Databases
Message Queues
Cache Layers
Notification Services
This approach often leads to incorrect assumptions.
Before discussing architecture, you should first understand:
What types of notifications are supported?
Who receives notifications?
How many users will use the system?
Is real-time delivery required?
What are the business objectives?
The answers to these questions directly influence the final architecture.
In System Design, requirements are usually divided into two categories:
Functional Requirements
Non-Functional Requirements
The goal is to collect enough information to make informed design decisions.
By the end of this phase, you should clearly understand:
The problem being solved
Target users
Core features
Expected scale
Business constraints
Technical constraints
Success metrics
Once these details are clear, architecture design becomes significantly easier.
Start by understanding the business problem.
Ask questions such as:
What problem are we solving?
Who are the users?
What is the primary goal of the system?
Why does this system exist?
This helps define the scope of the discussion.
Functional requirements describe what the system should do.
For a chat application, functional requirements may include:
Send messages
Receive messages
Create groups
Share media files
Focus on the most important features first.
Additional features can be discussed later.
Non-functional requirements describe how the system should behave.
Examples include:
Low latency
High availability
Reliability
Scalability
Security
Durability
Example:
For a stock trading platform, low latency may be critical.
For a video streaming platform, scalability may be more important.
These requirements strongly influence architecture decisions.
Estimate the expected size of the system.
Questions may include:
How many users are expected?
Daily Active Users (DAU)?
Requests per second?
How much data will be stored?
Expected growth rate?
Scale determines:
Database choices
Caching strategies
Load balancing requirements
Infrastructure size
Every system operates within certain limitations.
Examples include:
Budget restrictions
Technology constraints
Compliance requirements
Development timelines
Regulatory requirements
Understanding constraints helps avoid unrealistic designs.
Understand how success will be measured.
Examples include:
Response time under 200 ms
99.99% availability
Less than 0.1% failed requests
Support 10 million users
Success metrics help evaluate whether the design meets business expectations.
Not every feature needs to be included in the initial design.
Clearly identify features that are excluded.
For example, when designing a chat application:
In Scope
One-to-one messaging
Group messaging
Out of Scope
Voice calls
Video calls
Screen sharing
Defining scope prevents unnecessary complexity.
Who will use the system?
How many users are expected?
What are the core features?
Which features are optional?
What is out of scope?
Expected traffic volume?
Expected storage requirements?
Is low latency important?
Is real-time communication required?
How much downtime is acceptable?
Can data loss occur?
Is authentication required?
Is sensitive user data involved?
Requirements gathering may produce the following information:
Functional Requirements
Send messages
Receive messages
Create groups
Share media
Non-Functional Requirements
Low latency
High availability
Reliable message delivery
Scale
Millions of active users
Billions of messages per day
Out of Scope
Video calling
Status updates
After gathering these requirements, you can confidently move to architecture design.
Avoid these mistakes:
Jumping directly into architecture
Making assumptions without clarification
Ignoring scale requirements
Ignoring business constraints
Focusing on technology before understanding the problem
Trying to design everything at once
