System Design is one of the most important skills for those who want to evolve as a software engineer, architect, or technology professional.

It's here that we start turning ideas into real components.

So far, we've thought of something like:

Problem
↓
Objectives
↓
Architecture

Now we're going to evolve to:

Problem
↓
Requirements
↓
Components
↓
Flows
↓
System Design

In this article, you will learn:

What System Design is.
The difference between architecture and System Design.
What functional requirements are.
What non-functional requirements are.
What architectural constraints are.
How to transform requirements into components.
How to prepare the construction of a real architecture.

What is System Design?

System Design is the process of transforming requirements into an organized technical solution.

Many people associate System Design with diagrams with boxes, arrows, databases, APIs, and services.

But the diagram is just the final result.

The most important thing is the reasoning behind it.

In simple terms:

Problem
↓
System

System Design is the path between a business need and a technical solution capable of meeting it.

What does System Design Define?

Good System Design defines:

System components
Responsibilities of each component
Main flows
Communication between parts
Data storage
External integrations
Scaling strategies
Failure strategies

It answers questions like:

What parts does the system need to have?
How do these parts communicate?
Where do the data go?
How does the system scale?
How does it handle failures?
How will the system be operated?

A Simple Example of System Design

Imagine a delivery application.

The business problem is simple:

A customer wants to order food.

Before thinking about technology, we need to understand the flow:

How does the customer choose the restaurant?
How do they view the menu?
How do they add items to the cart?
How do they create the order?
How do they make the payment?
How do they track the delivery?

From these questions, we start to identify components:

Catalog
Cart
Order
Payment
Delivery

Notice that we still haven't talked about language, framework, cloud, or database.

We're talking about responsibilities.

This is the essence of System Design.

System Design is transforming needs into organized components.

Architecture vs System Design

One of the biggest confusions in the field is to treat architecture and System Design as if they were exactly the same thing.

They are related, but they are not equal.

Software Architecture

Architecture defines the principles and overall organization of the system.

It answers questions like:

How will the system be organized?
What responsibilities exist?
How should the system evolve?
What quality attributes are important?
What structural decisions need to be made?

Examples of architectural decisions:

Separation of responsibilities
Low coupling
Scalability
Observability
Modular monolith
Single source of truth

System Design

System Design transforms these principles into concrete components.

For example, if the architecture says:

Separate responsibilities

System Design can create:

Frontend
Backend
Database
Payment Gateway
AI Module

Simple Analogy

Architecture is the overall design of a house.

System Design is the practical definition of rooms, corridors, electrical installations, plumbing, and connection points.

In Lumina Store, we can think like this:

Architecture:

Modular Monolith
Single source of truth
Separation of domains

System Design:

Catalog
Cart
Orders
Payments
Support
AI

Architecture defines principles. System Design transforms these principles into components.

Functional Requirements

Before designing any system, we need to understand what it should do.

These capabilities are called functional requirements.

What are Functional Requirements?

Functional requirements describe functionalities observable by the user or the business.

They answer the question:

What does the system need to do?

In an e-commerce like Lumina Store, we can identify the following functional requirements.

RF01 — Catalog

The system must allow:

Listing products
Viewing product details
Checking availability

RF02 — Cart

The system must allow:

Adding products to the cart
Removing products
Changing quantities

RF03 — Checkout

The system must allow:

Creating orders
Identifying the customer
Starting payment

RF04 — PIX Payment

The system must allow:

Generating QR Code
Receiving payment confirmation
Updating order status

RF05 — Card Payment

The system must allow:

Processing payment
Receiving confirmation
Updating order

RF06 — AI Support

The system must allow:

Receiving customer questions
Answering doubts
Consulting a knowledge base

RF07 — Human Support

The system must allow:

Transferring conversations to a person
Keeping a history of support
Allowing continuity of support

RF08 — Administrative Panel

The system must allow:

Viewing orders
Viewing conversations
Tracking metrics

How to Know if a Requirement is Central?

A good question to evaluate requirements is:

If I remove this functionality,
is the product still the same product?

For example:

If we remove payment from an e-commerce, is it still a complete e-commerce?

Probably not.

This shows that payment is a central capability.

Functional requirements define the product's capabilities.

Non-Functional Requirements

Not all requirements relate to what the system does.

Some relate to how the system should behave.

These are the non-functional requirements.

What are Non-Functional Requirements?

Non-functional requirements describe qualities of the system.

They answer the question:

How should the system behave?

They have a great impact on architectural decisions.

RNF01 — Performance

The application must respond quickly.

Examples:

Fast catalog
Fast checkout
Fast APIs

RNF02 — Availability

The application must remain operational even in the face of failures.

Examples:

Unavailable AI provider
Payment gateway down
Database instability

RNF03 — Security

The application must protect:

Users
Payments
Sensitive data
Credentials
Integrations

RNF04 — Scalability

The application must support growth.

Examples:

More customers
More orders
More simultaneous accesses
More AI conversations

RNF05 — Observability

We need to be able to answer questions like:

What happened?
Where did it fail?
When did it fail?
Which component was affected?

To do this, we use:

Logs
Metrics
Traces
Alerts

RNF06 — Maintainability

The system must allow for continuous evolution.

Examples:

Adding functionalities
Fixing errors
Changing integrations
Improving existing modules

RNF07 — Cost

In modern projects, especially with AI, cost is also a quality attribute.

The architecture needs to be economically sustainable.

Examples:

Cost per LLM call
Vector storage cost
Cloud infrastructure cost
Observability cost
Traffic cost

SLOs: Making Requirements Measurable

In professional projects, non-functional requirements need to be measurable.

It's not enough to say:

The system must be fast.

It's better to say:

The catalog must respond with P99 below 500ms.

Other examples:

The application must have 99.5% monthly uptime.

The AI response must occur in less than 3 seconds.

The checkout must process orders in up to 2 seconds.

These objectives are called SLOs.

SLO means:

Service Level Objective

In this course, we can work with simplified requirements, but in professional environments, it's essential to associate numbers with non-functional requirements.

Non-functional requirements shape the architecture.

Architectural Constraints

Not all architectural decisions depend solely on technology.

Many decisions are limited by context.

These limitations are called architectural constraints.

What are Constraints?

Constraints are factors that limit or direct technical choices.

They can come from:

Team size
Budget
Deadline
Technical knowledge
Product objective
Company stage
Operational complexity

Constraint 01 — Small Team

In this project, we're assuming a team of:

1 to 5 developers

This eliminates excessively complex architectures.

A small team will hardly be able to operate dozens of microservices with quality.

Constraint 02 — MVP

We're building the first version of the product.

That is, an MVP.

At this point, we don't need to solve global scaling problems.

We need to validate the product, deliver value, and maintain simplicity.

Constraint 03 — Low Operational Cost

We want to reduce:

Infrastructure
External services
Deployment complexity
Observability cost
Operational work

The lower the operational cost, the easier it is to maintain the product at the beginning.

Constraint 04 — Ease of Learning

Since this project also has a didactic objective, the architecture needs to be understandable.

A good architecture for teaching should show concepts without creating unnecessary complexity.

Constraint 05 — Future Evolution

The architecture needs to allow for growth.

But without paying today the cost of a scale that doesn't exist yet.

This is one of the most important decisions:

Prepare for evolution,
without over-engineering in the present.

Good architecture respects the constraints of the context.

How Architectures are Born

Now we can connect all the points.

An architecture doesn't come from the choice of tools.

It comes from a structured reasoning.

The complete flow is:

Business Problem
↓
Objectives
↓
Functional Requirements
↓
Non-Functional Requirements
↓
Constraints
↓
Architectural Decisions
↓
System Design
↓
Final Architecture

First, we understand the problem.

Then we identify objectives.

Next, we raise functional and non-functional requirements.

After that, we analyze constraints.

Only then do we start making architectural decisions.

Applying to Lumina Store

In Lumina Store, we know we need:

Catalog
Cart
Checkout
Payments
AI Support
Human Support
Administrative Panel

We also know we want:

Simplicity
Low cost
Easy operation
Good maintainability
Future evolution

And we know the project is an MVP.

With this, some decisions start to make sense:

Modular Monolith
PostgreSQL
pgvector
FastAPI
Next.js

These technologies don't appear out of fashion.

They appear as a consequence of the context.

Before designing the architecture, we need to understand why each decision exists.

This is the role of System Design.

Conclusion

System Design is an essential skill for transforming problems into real systems.

In this article, we saw:

What System Design is.
How it relates to architecture.
What functional requirements are.
What non-functional requirements are.
What architectural constraints are.
How requirements are transformed into components.
How an architecture begins to emerge.

The main message of this chapter is:

System Design is not about drawing boxes. System Design is about transforming requirements into organized components to solve a real problem.

In the next step, we can start building the System Design of Lumina Store in a practical way, starting from a blank page and adding components gradually, always justifying each decision.