Chapter 01 — System Design Foundation | Topic 05

A feature can work perfectly and still create a poor system.

Sounds strange, right?

Let's take a simple example:

Customer should be able to place an order.

We can implement this feature successfully.

But is that enough?

What if the API takes 10 seconds to respond?

What if an unauthorized user can place an order?

What if the system crashes when thousands of customers place orders together?

The feature works.

But the system doesn't work well.

This is why we need to understand the difference between Functional Requirements and Non-Functional Requirements.

The Simple Difference

The easiest way to remember it is:

Functional Requirement

What should the system do?

Non-Functional Requirement

How should the system work?

Both are important for building a real-world application.

Let's Take One Feature

Consider an Order Management System.

One requirement is:

Customer should be able to place an order.

Now let's look at this requirement from two different views.

Functional View — What Should Happen?

From the functional perspective, we ask:

What should the system do when a customer places an order?

For example:

  • Customer selects products

  • Customer submits the order

  • System validates the order

  • System creates the order

  • Order details are stored

  • Customer receives confirmation

These describe the actual behavior and functionality of the system.

So we can create an API such as:

POST /api/orders

The API may receive:

{
  "customerId": 101,
  "productId": 25,
  "quantity": 2
}

The requirement is about the feature:

Customer can place an order.

Non-Functional View — How Should It Work?

Now ask different questions.

Performance

How quickly should the order API respond?

For example:

95% of requests should respond within an acceptable response time.

Security

Who is allowed to place an order?

For example:

Only authenticated customers can place orders.

Scalability

What happens when the number of customers increases?

For example:

The system should support significantly higher traffic during peak periods.

Availability

What happens if one application instance fails?

For example:

The application should remain available with minimal interruption.

These are not new features.

They describe how well the feature should work.

Same Feature, Two Views

Let's put everything together.

Feature: Place an Order

Functional Requirements

  • Customer can place an order

  • System validates order details

  • System creates the order

  • System stores order information

  • Customer receives confirmation

Non-Functional Requirements

  • API should respond quickly

  • Only authorized users can place orders

  • System should handle increased traffic

  • Order data should be secure

  • System should remain available

Notice something important:

The feature is the same.

Only the perspective is different.

Why Does This Matter for System Design?

Suppose the functional requirement is:

Customer can place an order.

If we only think about functionality, we may create:

Controller
    ↓
Service
    ↓
Database

And the feature may work.

But now suppose the business says:

“During a sale, thousands of customers may place orders at the same time.”

Now the Non-Functional Requirements change our design thinking.

We may need to consider:

  • Database optimization

  • Indexes

  • Caching

  • Load balancing

  • Multiple application instances

  • Background processing

  • Message queues

  • Monitoring

The requirement didn't change the feature.

It changed how the system needs to support that feature.

Simple ASP.NET Core Example

Let's look at a small API:

[ApiController]
[Route("api/orders")]
public class OrdersController : ControllerBase
{
    [Authorize]
    [HttpPost]
    public async Task<IActionResult> PlaceOrder(
        OrderRequest request)
    {
        // Validate the incoming request
        // Apply business rules
        // Save the order
        // Return the result

        return Ok(new
        {
            Message = "Order placed successfully"
        });
    }
}

This small example represents both perspectives.

Functional Requirement

The API allows an authorized customer to place an order.

Non-Functional Requirement

[Authorize] helps enforce a security requirement.

But security is only one part.

For a production system, we may also need to think about:

  • Response time

  • Database performance

  • Scalability

  • Availability

  • Logging

  • Error handling

  • Monitoring

This is where System Design goes beyond simply creating an endpoint.

A Quick Comparison

Functional

Non-Functional

What the system should do

How the system should work

Features and behavior

Quality and constraints

Place an order

Respond quickly

Cancel an order

Remain available

View order history

Protect user data

Update order status

Handle high traffic

Send notification

Recover from failures

A simple memory trick:

Functional = What
Non-Functional = How

Why Both Matter

Imagine an application with excellent functionality but:

  • Very slow APIs

  • Frequent downtime

  • Weak security

  • Poor scalability

Users will still have a bad experience.

Now imagine an application that is:

  • Fast

  • Secure

  • Highly available

  • Scalable

But customers cannot place orders.

That system is also useless.

So a successful system needs both:

Correct functionality + Good system behavior

How Should a Developer Think?

When you receive a new feature, don't stop after asking:

“What should I build?”

Also ask:

“How should this feature behave in the real world?”

For every important feature, think about:

What?
→ Functional Requirement

How fast?
→ Performance

Who can access it?
→ Security

How much traffic?
→ Scalability

What happens when something fails?
→ Reliability / Availability

This mindset helps you move from simply implementing features to designing systems.

IMPORTANT Takeaway

Functional and Non-Functional Requirements are not competing requirements.

They complement each other.

Functional Requirements define what the system does.

Non-Functional Requirements define how well the system should do it.

A good system is not just one where the features work.

It is a system where those features work securely, reliably, efficiently, and at the required scale.

What's Next?

Now that we understand:

  • Requirements

  • Functional Requirements

  • Non-Functional Requirements

  • The difference between them

The next step is to understand another important part of System Design:

Chapter 01 — System Design Foundation | Topic 06 — Constraints: The Rules Behind Your Design

Because real-world systems are never designed with unlimited time, money, infrastructure, traffic capacity, or resources.