DEV Community: Italo Vinicius

System Design: o que é e por onde começar?

Italo Vinicius — Wed, 16 Sep 2026 17:06:46 +0000

Nos últimos meses, comecei a estudar um assunto que aparece cada vez mais na rotina de desenvolvedores: System Design.

Apesar de já trabalhar há alguns anos com desenvolvimento de software, percebi que existe uma diferença importante entre saber implementar funcionalidades e saber projetar um sistema como um todo.

Foi justamente essa diferença que me motivou a estudar o assunto.

O que é System Design?

De forma simples, System Design é o processo de definir como diferentes componentes de um sistema vão se organizar e se comunicar para atender determinados requisitos.

Quando desenvolvemos uma aplicação pequena, podemos pensar principalmente em coisas como:

Qual endpoint preciso criar?
Qual tabela preciso adicionar?
Qual componente preciso implementar?

Conforme o sistema cresce, outras perguntas começam a aparecer:

Quantas requisições o sistema precisa suportar?
Como os dados serão armazenados?
Como evitar que um único componente se torne um gargalo?
O que acontece quando um serviço fica indisponível?
Como escalar a aplicação?
Onde utilizar cache?
Quando utilizar filas?
Como monitorar o sistema?
Como garantir consistência dos dados?
Como lidar com picos de tráfego?

System Design está muito mais relacionado a essas decisões.

Um exemplo simples

Imagine uma aplicação de e-commerce.

Em uma primeira versão, poderíamos ter algo relativamente simples:

Cliente
   ↓
API
   ↓
Banco de Dados

Para uma aplicação pequena, isso pode ser suficiente.

Mas imagine que a aplicação cresça e passe a receber milhares de requisições simultâneas.

Agora podemos começar a introduzir novos componentes:

                    ┌──→ Cache
                    │
Cliente → Load Balancer → API → Banco de Dados
                    │
                    └──→ Message Queue → Workers

Cada componente resolve um problema específico.

O Load Balancer pode distribuir as requisições entre diferentes instâncias da aplicação.

O Cache pode evitar consultas repetitivas ao banco de dados.

Uma Message Queue pode permitir que determinadas operações sejam processadas de forma assíncrona.

Os Workers podem consumir essas mensagens e executar tarefas em segundo plano.

O banco de dados continua sendo importante, mas agora não precisa necessariamente ser responsável por todo o trabalho.

System Design não significa simplesmente adicionar tecnologias

Uma coisa que comecei a perceber estudando o assunto é que projetar sistemas não significa simplesmente adicionar Redis, Kafka, Kubernetes ou microsserviços porque são tecnologias populares.

Cada componente adiciona complexidade.

Se uma aplicação recebe poucas requisições e possui um domínio relativamente simples, introduzir dezenas de serviços pode criar mais problemas do que resolver.

Por isso, uma parte importante de System Design é entender trade-offs.

Por exemplo:

Devemos utilizar cache?

A resposta não é simplesmente “sim”.

Precisamos considerar:

O dado é consultado frequentemente?
Ele muda com muita frequência?
Podemos aceitar dados temporariamente desatualizados?
Qual será a estratégia de invalidação?
O custo de manter o cache compensa?

A mesma lógica vale para bancos SQL vs. NoSQL, monólito vs. microsserviços, processamento síncrono vs. assíncrono e diversas outras decisões.

Requisitos funcionais e não funcionais

Outro conceito importante é separar os requisitos do sistema.

Os requisitos funcionais descrevem o que o sistema precisa fazer.

Por exemplo:

Usuários podem criar uma conta.
Usuários podem realizar pedidos.
Administradores podem cancelar pedidos.

Já os requisitos não funcionais descrevem características relacionadas ao funcionamento do sistema.

Por exemplo:

Suportar 10.000 requisições por segundo.
Ter disponibilidade de 99,9%.
Responder às requisições em menos de 200 ms.
Permitir crescimento horizontal.

Essa distinção é importante porque os requisitos não funcionais influenciam diretamente as decisões de arquitetura.

Escalabilidade

Um dos conceitos mais associados a System Design é escalabilidade.

Existem duas formas comuns de pensar sobre isso.

Escalabilidade vertical significa aumentar os recursos de uma máquina:

4 CPU / 8 GB RAM
        ↓
16 CPU / 32 GB RAM

Já a escalabilidade horizontal significa adicionar mais máquinas ou instâncias:

             ┌→ API 1
Load Balancer├→ API 2
             └→ API 3

A escalabilidade horizontal costuma ser especialmente importante quando precisamos distribuir carga e evitar depender de uma única instância.

Mas novamente: isso não significa que horizontal seja sempre melhor. A decisão depende dos requisitos e das características do sistema.

O que estou estudando

Estou começando a organizar meus estudos de System Design em alguns conceitos fundamentais:

Arquitetura: monólitos, microsserviços e componentes distribuídos.

Bancos de dados: SQL, NoSQL, índices, replicação, particionamento e consistência.

Performance: caching, CDN, load balancing e otimização de consultas.

Comunicação: APIs, filas, eventos e processamento assíncrono.

Confiabilidade: redundância, tolerância a falhas, disponibilidade e recuperação.

Observabilidade: logs, métricas, tracing e monitoramento.

Segurança: autenticação, autorização, rate limiting e proteção de APIs.

Ainda estou no processo de aprofundar esses conceitos, mas uma das coisas que mais chamou minha atenção é que System Design não é sobre encontrar uma arquitetura perfeita.

É sobre entender os requisitos, identificar restrições e tomar decisões conscientes considerando os trade-offs envolvidos.

Conclusão

Para mim, estudar System Design representa uma mudança de perspectiva.

Como desenvolvedor, é natural pensar primeiro em código: classes, funções, endpoints, componentes e bancos de dados.

System Design força uma visão mais ampla.

Antes de perguntar “como vou implementar isso?”, começamos a perguntar:

“Como esse sistema precisa funcionar?”

“Quais problemas podem aparecer quando ele crescer?”

“Quais decisões arquiteturais fazem sentido para esses requisitos?”

System Design não é apenas desenhar caixas e setas. É entender o problema e tomar boas decisões técnicas diante das restrições existentes.

How I'm Using AI Agents in My Daily Dev Workflow

Italo Vinicius — Mon, 04 May 2026 02:03:04 +0000

I was skeptical at first.

Not about AI in general — but about whether it would actually fit into my workflow. I work mostly with legacy PHP and jQuery. The kind of codebase that was written before half the frameworks people talk about today even existed. Some Vue.js here and there in newer parts, but a lot of the core is raw PHP, procedural logic, and jQuery doing things you probably don't want to know about.

It's not glamorous. But it's real work, and it has its own kind of complexity.

When I started using Claude more seriously, I wasn't expecting much. Turns out I was wrong.

Reviewing code before committing

Before I push anything, I paste the relevant code and ask: does this look right? What am I missing?

Nine times out of ten, it finds something. Not always a bug — sometimes just a cleaner way to write something, a missing edge case, a condition that could silently fail with unexpected input. The kind of thing your brain skips when you've been inside the same file for two hours.

It's become a habit. Faster than asking a coworker, and it never makes you feel dumb for asking.

Writing tests for code that never had any

This one I started more recently.

Legacy codebases and test coverage don't usually go together. Ours was no different. I'd write the occasional test, but it was never a priority because, well, it takes time and the code wasn't exactly built with testability in mind.

What changed: I started pasting functions into Claude and asking it to write the test cases — happy path, edge cases, what happens when the input is garbage. I review, adjust where needed, and move on.

Coverage is actually growing now. That feels like a win.

Making sense of code nobody remembers writing

This is probably the one I use most in my day-to-day.

Legacy PHP is full of functions that made sense to someone at some point. No comments, variable names like $tmp2, business logic baked into places it shouldn't be. You spend more time figuring out what something does than actually changing it.

I paste the function and ask Claude to walk me through it — not just what it does, but why it might have been written that way, what could break, what assumptions it's making. It doesn't always get it perfectly, but it gets me 80% of the way there in 30 seconds instead of 20 minutes of archaeological digging.

Killing the repetitive stuff

Over time I've built up a set of prompts for things I do constantly:

Converting raw SQL queries to something more readable
Writing docblock comments for functions that have none
Generating boilerplate for repetitive patterns in the codebase

Individually, none of this is impressive. But it adds up. There's a certain type of low-effort, high-friction work that quietly drains your day, and removing it makes a real difference.

A few things I've noticed along the way

The quality of your output depends on the quality of your input. Vague prompts get vague answers. The more context you give — the stack, the constraints, what you've already tried — the more useful the response. It sounds obvious but it took me a while to internalize.

Explaining your code to AI makes you understand it better. There's something about having to describe a problem clearly enough for a language model that forces you to actually think it through. I've solved bugs mid-prompt just by writing the question.

It's slow to notice, then hard to imagine going back. The first week felt marginal. A few months in, I catch myself reaching for it automatically.

I'm still learning — recently started digging into the Claude API and AI subagents, curious where that leads. But even at the most basic level, having AI as part of my daily workflow has made me faster and, honestly, a bit less frustrated with legacy code.

Which is saying something.

What does your AI workflow look like? Drop it in the comments — always curious how other devs are using these tools.