System Design é uma das habilidades mais importantes para quem deseja evoluir como engenheiro de software, arquiteto ou profissional de tecnologia.

É aqui que começamos a transformar ideias em componentes reais.

Até agora, pensamos em algo como:

Problema
↓
Objetivos
↓
Arquitetura

Agora vamos evoluir para:

Problema
↓
Requisitos
↓
Componentes
↓
Fluxos
↓
System Design

Neste artigo você aprenderá:

• O que é System Design.
• A diferença entre arquitetura e System Design.
• O que são requisitos funcionais.
• O que são requisitos não funcionais.
• O que são restrições arquiteturais.
• Como transformar requisitos em componentes.
• Como preparar a construção de uma arquitetura real.

O Que é System Design?

System Design é o processo de transformar requisitos em uma solução técnica organizada.

Muitas pessoas associam System Design a diagramas com caixas, setas, bancos de dados, APIs e serviços.

Mas o diagrama é apenas o resultado final.

O mais importante é o raciocínio por trás dele.

Em termos simples:

Problema
↓
Sistema

System Design é o caminho entre uma necessidade de negócio e uma solução técnica capaz de atendê-la.

O Que o System Design Define?

Um bom System Design define:

• Componentes do sistema
• Responsabilidades de cada componente
• Fluxos principais
• Comunicação entre partes
• Armazenamento de dados
• Integrações externas
• Estratégias de escala
• Estratégias de falha

Ele responde perguntas como:

• Quais partes o sistema precisa ter?
• Como essas partes conversam?
• Onde os dados ficam?
• Como o sistema escala?
• Como ele lida com falhas?
• Como o sistema será operado?

Um Exemplo Simples de System Design

Imagine um aplicativo de delivery.

O problema de negócio é simples:

Um cliente quer pedir comida.

Antes de pensar em tecnologia, precisamos entender o fluxo:

• Como o cliente escolhe o restaurante?
• Como visualiza o cardápio?
• Como adiciona itens ao carrinho?
• Como cria o pedido?
• Como realiza o pagamento?
• Como acompanha a entrega?

A partir dessas perguntas, começamos a identificar componentes:

Catálogo
Carrinho
Pedido
Pagamento
Entrega

Perceba que ainda não falamos de linguagem, framework, cloud ou banco de dados.

Estamos falando de responsabilidades.

Essa é a essência do System Design.

System Design é transformar necessidades em componentes organizados.

Arquitetura vs System Design

Uma das maiores confusões da área é tratar arquitetura e System Design como se fossem exatamente a mesma coisa.

Eles estão relacionados, mas não são iguais.

Arquitetura de Software

Arquitetura define os princípios e a organização geral do sistema.

Ela responde perguntas como:

• Como o sistema será organizado?
• Quais responsabilidades existem?
• Como o sistema deve evoluir?
• Quais atributos de qualidade são importantes?
• Quais decisões estruturais precisam ser tomadas?

Exemplos de decisões arquiteturais:

Separação de responsabilidades
Baixo acoplamento
Escalabilidade
Observabilidade
Monólito modular
Fonte única de verdade

System Design

System Design transforma esses princípios em componentes concretos.

Por exemplo, se a arquitetura diz:

Separar responsabilidades

O System Design pode criar:

Frontend
Backend
Banco de Dados
Gateway de Pagamento
Módulo de IA

Analogia Simples

Arquitetura é o projeto geral de uma casa.

System Design é a definição prática dos cômodos, corredores, instalações elétricas, hidráulicas e pontos de conexão.

Na Lumina Store, podemos pensar assim:

Arquitetura:

Monólito Modular
Fonte única de verdade
Separação de domínios

System Design:

Catalog
Cart
Orders
Payments
Support
AI

Arquitetura define princípios. System Design transforma esses princípios em componentes.

Requisitos Funcionais

Antes de desenhar qualquer sistema, precisamos entender o que ele deve fazer.

Essas capacidades são chamadas de requisitos funcionais.

O Que São Requisitos Funcionais?

Requisitos funcionais descrevem funcionalidades observáveis pelo usuário ou pelo negócio.

Eles respondem à pergunta:

O que o sistema precisa fazer?

Em um e-commerce como a Lumina Store, podemos identificar os seguintes requisitos funcionais.

RF01 — Catálogo

O sistema deve permitir:

• Listar produtos
• Visualizar detalhes dos produtos
• Consultar disponibilidade

RF02 — Carrinho

O sistema deve permitir:

• Adicionar produtos ao carrinho
• Remover produtos
• Alterar quantidades

RF03 — Checkout

O sistema deve permitir:

• Criar pedidos
• Identificar o cliente
• Iniciar o pagamento

RF04 — Pagamento PIX

O sistema deve permitir:

• Gerar QR Code
• Receber confirmação de pagamento
• Atualizar o status do pedido

RF05 — Pagamento com Cartão

O sistema deve permitir:

• Processar pagamento
• Receber confirmação
• Atualizar pedido

RF06 — Atendimento com IA

O sistema deve permitir:

• Receber perguntas dos clientes
• Responder dúvidas
• Consultar uma base de conhecimento

RF07 — Atendimento Humano

O sistema deve permitir:

• Transferir conversas para uma pessoa
• Manter histórico de atendimento
• Permitir continuidade do atendimento

RF08 — Painel Administrativo

O sistema deve permitir:

• Visualizar pedidos
• Visualizar conversas
• Acompanhar métricas

Como Saber Se Um Requisito é Central?

Uma boa pergunta para avaliar requisitos é:

Se eu remover essa funcionalidade,
o produto ainda continua sendo o mesmo produto?

Por exemplo:

Se removermos o pagamento de um e-commerce, ele ainda seria um e-commerce completo?

Provavelmente não.

Isso mostra que pagamento é uma capacidade central.

Requisitos funcionais definem as capacidades do produto.

Requisitos Não Funcionais

Nem todos os requisitos dizem respeito ao que o sistema faz.

Alguns dizem respeito a como o sistema deve funcionar.

Esses são os requisitos não funcionais.

O Que São Requisitos Não Funcionais?

Requisitos não funcionais descrevem qualidades do sistema.

Eles respondem à pergunta:

Como o sistema deve se comportar?

Eles têm grande impacto nas decisões arquiteturais.

RNF01 — Performance

A aplicação deve responder rapidamente.

Exemplos:

• Catálogo rápido
• Checkout rápido
• APIs rápidas

RNF02 — Disponibilidade

A aplicação deve permanecer operacional mesmo diante de falhas.

Exemplos:

• Provedor de IA indisponível
• Gateway de pagamento fora do ar
• Banco de dados com instabilidade

RNF03 — Segurança

A aplicação deve proteger:

• Usuários
• Pagamentos
• Dados sensíveis
• Credenciais
• Integrações

RNF04 — Escalabilidade

A aplicação deve suportar crescimento.

Exemplos:

• Mais clientes
• Mais pedidos
• Mais acessos simultâneos
• Mais conversas com IA

RNF05 — Observabilidade

Precisamos conseguir responder perguntas como:

• O que aconteceu?
• Onde falhou?
• Quando falhou?
• Qual componente foi afetado?

Para isso usamos:

• Logs
• Métricas
• Traces
• Alertas

RNF06 — Manutenibilidade

O sistema deve permitir evolução contínua.

Exemplos:

• Adicionar funcionalidades
• Corrigir erros
• Trocar integrações
• Melhorar módulos existentes

RNF07 — Custo

Em projetos modernos, especialmente com IA, custo também é um atributo de qualidade.

A arquitetura precisa ser economicamente sustentável.

Exemplos:

• Custo por chamada ao LLM
• Custo de armazenamento vetorial
• Custo de infraestrutura cloud
• Custo de observabilidade
• Custo de tráfego

SLOs: Tornando Requisitos Mensuráveis

Em projetos profissionais, requisitos não funcionais precisam ser mensuráveis.

Não basta dizer:

O sistema deve ser rápido.

É melhor dizer:

O catálogo deve responder com P99 abaixo de 500ms.

Outros exemplos:

A aplicação deve ter 99.5% de uptime mensal.

A resposta da IA deve ocorrer em menos de 3 segundos.

O checkout deve processar pedidos em até 2 segundos.

Esses objetivos são chamados de SLOs.

SLO significa:

Service Level Objective

Neste curso podemos trabalhar com requisitos simplificados, mas em ambientes profissionais é importante associar números aos requisitos não funcionais.

Requisitos não funcionais moldam a arquitetura.

Restrições Arquiteturais

Nem toda decisão arquitetural depende apenas da tecnologia.

Muitas decisões são limitadas pelo contexto.

Essas limitações são chamadas de restrições arquiteturais.

O Que São Restrições?

Restrições são fatores que limitam ou direcionam as escolhas técnicas.

Elas podem vir de:

• Tamanho da equipe
• Orçamento
• Prazo
• Conhecimento técnico
• Objetivo do produto
• Estágio da empresa
• Complexidade operacional

Restrição 01 — Equipe Pequena

Neste projeto, estamos assumindo uma equipe de:

1 a 5 desenvolvedores

Isso elimina arquiteturas excessivamente complexas.

Uma equipe pequena dificilmente conseguirá operar dezenas de microsserviços com qualidade.

Restrição 02 — MVP

Estamos construindo uma primeira versão do produto.

Ou seja, um MVP.

Neste momento, não precisamos resolver problemas de escala global.

Precisamos validar o produto, entregar valor e manter simplicidade.

Restrição 03 — Baixo Custo Operacional

Queremos reduzir:

• Infraestrutura
• Serviços externos
• Complexidade de deploy
• Custo de observabilidade
• Trabalho operacional

Quanto menor o custo operacional, mais fácil é manter o produto no início.

Restrição 04 — Facilidade de Aprendizado

Como este projeto também tem objetivo didático, a arquitetura precisa ser compreensível.

Uma boa arquitetura para ensino deve mostrar os conceitos sem criar complexidade desnecessária.

Restrição 05 — Evolução Futura

A arquitetura precisa permitir crescimento.

Mas sem cobrar hoje o custo de uma escala que ainda não existe.

Essa é uma das decisões mais importantes:

Preparar para evoluir,
sem superengenharia no presente.

Arquitetura boa respeita as restrições do contexto.

Como Arquiteturas Nascem

Agora podemos conectar todos os pontos.

Uma arquitetura não nasce da escolha de ferramentas.

Ela nasce de um raciocínio estruturado.

O fluxo completo é:

Problema de Negócio
↓
Objetivos
↓
Requisitos Funcionais
↓
Requisitos Não Funcionais
↓
Restrições
↓
Decisões Arquiteturais
↓
System Design
↓
Arquitetura Final

Primeiro entendemos o problema.

Depois identificamos objetivos.

Em seguida levantamos requisitos funcionais e não funcionais.

Depois analisamos restrições.

Só então começamos a tomar decisões arquiteturais.

Aplicando na Lumina Store

Na Lumina Store, sabemos que precisamos de:

• Catálogo
• Carrinho
• Checkout
• Pagamentos
• Atendimento com IA
• Atendimento humano
• Painel administrativo

Também sabemos que queremos:

• Simplicidade
• Baixo custo
• Facilidade operacional
• Boa manutenibilidade
• Evolução futura

E sabemos que o projeto é um MVP.

Com isso, algumas decisões começam a fazer sentido:

Monólito Modular
PostgreSQL
pgvector
FastAPI
Next.js

Essas tecnologias não aparecem por moda.

Elas aparecem como consequência do contexto.

Antes de desenhar a arquitetura, precisamos entender por que cada decisão existe.

Esse é o papel do System Design.

Conclusão

System Design é uma habilidade essencial para transformar problemas em sistemas reais.

Neste artigo vimos:

• O que é System Design.
• Como ele se relaciona com arquitetura.
• O que são requisitos funcionais.
• O que são requisitos não funcionais.
• O que são restrições arquiteturais.
• Como requisitos se transformam em componentes.
• Como uma arquitetura começa a nascer.

A principal mensagem deste capítulo é:

"

System Design não é desenhar caixas. System Design é transformar requisitos em componentes organizados para resolver um problema real.

No próximo passo, podemos começar a construir o System Design da Lumina Store de forma prática, partindo de uma página em branco e adicionando componentes gradualmente, sempre justificando cada decisão.