Phase 01 — System Design Foundation | Topic 02
One of the most common mistakes developers make is starting to write code too early.
A requirement comes in:
“Build an Order Management System.”
And the first thought is often:
“Okay, which table should I create?”
But that is not the first question we should ask.
Before thinking about controllers, services, entities, databases, or APIs, we need to understand what problem the system is actually solving.
That is where System Design starts.
Why Is Understanding Requirements Important?
Imagine you receive this requirement:
“Develop an Order Management System where customers can place orders, view their order history, and cancel orders. Admin can manage orders and update order status. The system should send email notifications for order confirmation.”
It looks simple.
But if we start coding immediately, many questions remain unanswered:
Who are the users?
What can each user do?
What exactly happens when an order is placed?
Can an order be cancelled after shipment?
Who can update order status?
When should the email be sent?
What happens if email sending fails?
How many users will use the system?
What data needs to be stored?
These questions affect our APIs, database design, business logic, and architecture.
IMPORTANT:
A good system design starts with understanding the problem, not choosing the technology.
Step 1 — Read the Requirement Carefully
Don't read the requirement only once.
Read it and identify the important information.
For our example:
“Develop an Order Management System where customers can place orders, view order history, and cancel orders. Admin can manage orders and update order status. The system should send email notifications for order confirmation.”
We can immediately identify:
System: Order Management System
Users: Customer, Admin
Customer actions:
Place Order
View Order History
Cancel Order
Admin actions:
Manage Orders
Update Order Status
System action:
This simple breakdown already gives us a basic understanding of the system.
Step 2 — Identify the Problem
Before designing the solution, ask:
What problem are we trying to solve?
For this example:
Customers need a system to place and manage their orders, while administrators need a system to manage those orders.
That's the actual business problem.
The technology comes later.
We don't start with:
“Let's use ASP.NET Core Web API and SQL Server.”
We start with:
“What does the business need?”
Then we decide how technology can solve it.
Step 3 — Identify the Users
Next, identify who will interact with the system.
For our Order Management System:
Order Management System
|
-------------------
| |
Customer Admin
Customer
The customer may:
Place an order
View order history
Cancel an order
Admin
The admin may:
View orders
Update order status
Manage orders
This is important because different users usually have different permissions.
For example:
Customer
↓
Can place an order
Admin
↓
Can update order status
A customer should not automatically have permission to perform administrative operations.
This later becomes part of our Authentication and Authorization design.
Step 4 — Identify the System Actions
Now ask:
What actions should the system perform?
For example:
Customer
|
├── Place Order
├── View Order History
└── Cancel Order
Admin
|
├── View Orders
└── Update Order Status
System
|
└── Send Confirmation Email
This is the beginning of our use-case mapping.
We are converting a simple business requirement into actions that the software must support.
Step 5 — Convert Requirements Into Use Cases
Let's create a simple mapping.
User | Use Case |
|---|
Customer | Place Order |
Customer | View Order History |
Customer | Cancel Order |
Admin | View Orders |
Admin | Update Order Status |
System | Send Confirmation Email |
Now the requirement is becoming much clearer.
Instead of having one large paragraph, we have individual responsibilities.
This makes the next design steps easier.
Step 6 — Ask What Happens Behind Each Action
This is where a developer starts thinking like a system designer.
Consider:
Place Order
What actually happens?
A simple flow could be:
Customer
↓
Place Order
↓
ASP.NET Core API
↓
Validate Request
↓
Create Order
↓
Save Order
↓
Send Confirmation
↓
Response
But even this raises more questions.
What if the database is unavailable?
What if email sending fails?
Should the customer wait for the email operation?
What if the customer clicks Place Order twice?
These questions eventually lead us to topics such as:
Transactions
Idempotency
Background Processing
Message Queues
Retry
Resilience
This is why System Design is not just about drawing architecture diagrams.
Step 7 — Think About the Data
Once we understand the actions, we can start thinking about the data.
For example:
Customer
Customer
---------
Id
Name
Email
Order
Order
---------
Id
CustomerId
OrderDate
Status
TotalAmount
Order Item
OrderItem
---------
Id
OrderId
ProductId
Quantity
Price
Notice something important.
We didn't start by designing these tables.
We first understood:
Problem → Users → Actions → Use Cases → Data
This is a much better approach.
Step 8 — Think About Business Rules
Requirements often contain hidden business rules.
For example:
Customer can cancel an order.
But can the customer cancel any order?
Probably not.
Maybe:
Pending → Can Cancel
Confirmed → Can Cancel
Shipped → Cannot Cancel
Delivered → Cannot Cancel
Cancelled → Cannot Cancel
Now we have a business rule.
This rule should be implemented in the appropriate business/service layer rather than simply placing everything inside a controller.
For example:
public async Task CancelOrderAsync(int orderId)
{
var order = await _orderRepository.GetByIdAsync(orderId);
if (order == null)
throw new Exception("Order not found.");
// Business rule:
// Only pending or confirmed orders can be cancelled.
if (order.Status != OrderStatus.Pending &&
order.Status != OrderStatus.Confirmed)
{
throw new InvalidOperationException(
"This order cannot be cancelled.");
}
order.Status = OrderStatus.Cancelled;
await _orderRepository.UpdateAsync(order);
}
The important point is not the exact code.
The important point is that requirements become business rules, and business rules become application logic.
Step 9 — Think About Non-Functional Requirements
Functional requirements tell us:
What should the system do?
But we also need to understand:
How should the system behave?
For example:
How many users will access it?
How many orders can be created per second?
How quickly should the API respond?
Should the system be available 24/7?
How secure should customer data be?
What happens if an external service fails?
These are Non-Functional Requirements.
For example:
Functional Requirement
↓
Customer can place an order
Non-Functional Requirement
↓
Order API should respond quickly
and support high traffic
We will explore Functional and Non-Functional Requirements in the upcoming topics.
A Simple Requirement-to-Design Process
As a developer, you can follow this simple process whenever you receive a new requirement:
Understand the Requirement
↓
Identify the Problem
↓
Identify the Users
↓
Identify User Actions
↓
Create Use Cases
↓
Identify Business Rules
↓
Identify Data
↓
Identify Functional Requirements
↓
Identify Non-Functional Requirements
↓
Start System Design
↓
Start Coding
This process prevents us from jumping directly into implementation.
A Real .NET Developer's Perspective
Let's say someone gives you this requirement:
“Build a Leave Management System.”
Don't immediately create:
LeaveController
LeaveService
LeaveRepository
LeaveDbContext
Instead, ask:
Who uses it?
Employee
Manager
HR
Admin
What can they do?
Employee
├── Apply Leave
├── View Leave Balance
└── View Leave History
Manager
├── View Team Leave
├── Approve Leave
└── Reject Leave
HR
├── Manage Leave Policies
└── View Reports
Now the system is becoming clearer.
Only after understanding these requirements should we start thinking about:
APIs
Database
Authentication
Authorization
Services
Caching
Notifications
Background jobs
Architecture
This is the difference between simply writing code and designing a system.
A Small Checklist Before You Start Coding
Before creating your first controller, ask yourself:
Requirement
Users
Who will use the system?
What can each user do?
Actions
Business Rules
Data
System Behaviour
How many users are expected?
How fast should the system respond?
What happens when something fails?
If you can answer these questions, you are already moving from coding thinking toward system design thinking.
IMPORTANT Takeaway
Don't start System Design with:
“Which technology should I use?”
Start with:
“What problem are we solving?”
Then move step by step:
Problem → Users → Actions → Use Cases → Business Rules → Data → Requirements → Design → Code
The better you understand the requirements, the better decisions you can make about your APIs, database, architecture, scalability, and overall system.
Keep learning. Keep designing. Keep building.
Join the conversation! Your thoughts help the community grow.