Building Blocks de System Design: guia essencial

Building blocks de System Design são os componentes básicos que você precisa dominar antes de desenhar qualquer sistema em uma entrevista técnica. Neste guia, você encontra os blocos essenciais: bancos de dados, filas, load balancer, API gateway, serverless, microsserviços, WAF, rate limiting, eventos, DNS, blob store, cache e CDN, com os trade-offs que cada um carrega.

O que são building blocks de System Design

Building blocks de System Design são os componentes arquiteturais básicos que você combina para resolver um problema de escala em entrevistas técnicas. Em vez de desenhar o Spotify inteiro em uma hora, o candidato usa banco de dados, fila, cache e CDN para atender milhões de usuários em um problema pequeno como um encurtador de URL.

A ideia central é preparação de base. Augusto Galego, engenheiro de software e criador do canal Algoritmos e Estruturas de Dados, relata ter feito mais de 20 entrevistas em vários países e passado em cinco delas — em quatro dessas cinco, a etapa de System Design foi cobrada. Esse dado é experiência pessoal do autor do vídeo, não uma estatística de mercado.

O vídeo publicado em 2026 serve como mapa de estudos. Cada bloco abaixo responde a uma pergunta que aparece naturalmente durante a entrevista: onde guardar os dados, como desacoplar processamento, como distribuir carga e como entregar conteúdo rápido.

Você não precisa saber tudo com profundidade de especialista. Precisa saber o suficiente para escolher com critério e justificar o trade-off diante da regra de negócio.

Banco de dados: SQL e NoSQL com critério

O banco de dados é o bloco que quase sempre aparece numa entrevista, então você precisa escolher entre SQL e NoSQL com base no problema, não por preferência. Bancos relacionais como PostgreSQL e MySQL oferecem garantias ACID: atomicidade, consistência, isolamento e durabilidade.

No lado NoSQL, MongoDB é um banco de documentos e DynamoDB é um armazenamento chave-valor oferecido pela AWS. A Cassandra é orientada a colunas e costuma entrar quando o volume de escrita por segundo é o gargalo.

O PostgreSQL também pode armazenar vetores, o que permite atender buscas semânticas sem adicionar um banco vetorial específico. Conhecer essa alternativa evita a resposta automática de que vector database é sempre obrigatório quando o assunto é RAG.

Você não precisa decorar diferenças entre PostgreSQL e MySQL: na prática, eles resolvem problemas muito parecidos. O que importa é saber quando usar cada família e quais garantias você abre mão.

Comparação entre SQL e NoSQL

Banco	Modelo de dados	Garantia	Quando usar
PostgreSQL ou MySQL	Relacional	ACID	Transações financeiras e dados com relacionamentos
MongoDB	Documentos	BASE	Dados semiestruturados com esquema flexível
DynamoDB	Chave-valor	BASE	Acesso por chave com latência previsível em escala
Cassandra	Colunar	BASE	Escrita intensa distribuída em várias regiões

Você pode combinar SQL e NoSQL no mesmo sistema. Esse padrão misto costuma escalar melhor do que forçar um único banco a resolver tudo.

Particionamento e sharding

Quando uma máquina não dá mais conta do volume, o próximo passo é particionar. Você pode particionar na vertical, separando colunas, ou na horizontal, dividindo linhas entre réplicas.

Também existe a diferença entre partição e shard. É possível ter um banco particionado dentro de uma única instância, sem shards separados. Muita gente no mercado trata os dois como sinônimos, o que nem sempre é preciso.

A estratégia de distribuição mais simples usa o módulo do identificador: com duas partições, IDs ímpares vão para uma e pares para outra. Existem alternativas por faixa e por hash consistente, com trade-offs diferentes conforme o padrão de acesso.

Filas e processamento assíncrono

Filas desacoplam produtores de consumidores quando a produção e o consumo acontecem em velocidades diferentes. Um web crawler produz páginas continuamente, e o processamento posterior consome essas páginas em outro ritmo. A fila no meio absorve essa diferença sem derrubar o sistema.

Usos comuns incluem envio de e-mail, processamento de imagem e vídeo, comunicação interna entre serviços e rotinas de segundo plano. Em todos esses casos, o usuário não precisa esperar a conclusão para receber resposta.

Um ponto que costuma aparecer na entrevista é que fila não deixa o sistema mais rápido. Ela deixa o sistema mais barato e mais resiliente, ao custo de um pouco mais de latência na requisição. Se o processo precisa ser síncrono e imediato, a fila atrapalha.

As garantias de entrega são um trade-off clássico. Você escolhe entre exatamente uma vez, pelo menos uma vez e no máximo uma vez, e cada opção muda o desenho do consumidor.

Garantias de entrega de uma fila

Garantia	Significado	Custo de implementação	Uso típico
Exatamente uma vez	O evento é processado uma única vez	Alto	Transações financeiras
Pelo menos uma vez	O evento chega ao menos uma vez, podendo duplicar	Médio	E-mails e notificações
No máximo uma vez	O evento pode ser perdido sem repetição	Baixo	Logs e métricas não críticas

Se o cenário exige pelo menos uma vez, o consumidor precisa ser idempotente. Esse endpoint evita que a mesma transação seja processada duas vezes quando a mensagem for reentregue.

Load balancer e API gateway: qual entra em cada camada

O load balancer distribui requisições entre servidores para evitar que uma máquina concentre toda a carga. Ele aparece em praticamente todo desenho de System Design que precisa escalar para milhões de usuários, e a banca espera que você saiba justificar a presença dele.

Os algoritmos mais citados são round-robin, menor tempo de resposta e menor número de conexões ativas. Round-robin alterna requisições entre servidores em sequência. Os outros dois escolhem o alvo com base em uma medição em tempo real.

Existem também diferenças entre balanceadores de camada de aplicação e de camada de rede. Você não precisa entrar em detalhes finos durante a entrevista, mas reconhecer que essa distinção existe ajuda quando o entrevistador aprofunda.

O API Gateway é parecido, mas não igual. Ele inspeciona parâmetros da requisição, normalmente a URI, e encaminha para o destino certo. Uma chamada para /users pode ir ao serviço de usuários, enquanto /produtos vai para outro serviço.

Serverless, microsserviços e monolitos: trade-offs reais

Serverless e servidor não são opostos absolutos, e microsserviços não são sinônimo de várias máquinas. Confundir essas dimensões é um erro comum em entrevistas, porque elas se cruzam de formas diferentes.

No modelo serverless, o provedor cobra por uso e escala sob demanda. Se não há requisição, o custo cai a zero. Em compensação, existe latência de inicialização, conhecida como cold start, e o ambiente fica ligado por um tempo antes de ser encerrado.

AWS Lambda popularizou esse modelo de computação sob demanda. Não confunda essa Lambda, serviço da AWS, com funções anônimas de linguagens como Python, que também são chamadas de lambda.

Servidores dedicados fazem sentido quando o tráfego é constante e a demanda por CPU é intensa. Nesse cenário, alugar máquina o tempo todo costuma sair mais barato do que pagar por requisição.

Já microsserviços e monolitos são outro eixo. É possível rodar vinte microsserviços dentro de uma única máquina, como acontece quando você sobe várias imagens Docker para trabalhar localmente. Na prática, porém, cada serviço tende a ocupar uma máquina ou uma função independente.

Entre as vantagens de microsserviços estão o deploy independente por equipe, a escolha de linguagem por serviço e a escala proporcional de cada parte. A complexidade operacional é enorme, e por isso empresas pequenas e médias costumam preferir monolitos pela simplicidade de setup.

WAF, rate limiting e arquitetura orientada a eventos

WAF significa Web Application Firewall e é uma peça de segurança que filtra requisições maliciosas antes de elas chegarem à sua aplicação. Provedores de nuvem como AWS, Cloudflare e Vercel oferecem esse tipo de proteção.

Não é preciso dominar regras específicas de WAF. Basta saber que ele existe e que costuma entrar na frente do sistema como camada de defesa contra tentativas de exploração de vulnerabilidades.

O rate limiting limita quantas requisições um usuário ou serviço pode fazer em um intervalo de tempo. É uma técnica de controle de recursos: assistir a um vídeo é razoável; abrir mil vídeos em paralelo, não.

Você pode implementar rate limiting de várias formas, com algoritmos diferentes. O ponto central, para a entrevista, é entender que ele protege sua infraestrutura de uso abusivo e de picos inesperados.

Arquitetura orientada a eventos é parente das filas, mas não é a mesma coisa. Nela, alguém publica um evento e vários interessados podem consumir. Um pedido de corrida em aplicativo de transporte ilustra bem: o evento é publicado e vários motoristas podem aceitá-lo.

Padrões como Saga, escolhido para lidar com transações distribuídas, e CQRS, que separa leitura de escrita, aparecem com frequência nesse tipo de arquitetura.

DNS, blob store, cache e CDN no desenho final

DNS, o Domain Name System, traduz o nome que você digita no navegador para o endereço IP da máquina real que responde à requisição. É conhecimento geral, mas indispensável: sem entender a resolução de nomes, você não explica como o tráfego chega ao seu sistema.

Blob store significa Binary Large Object store e guarda objetos binários grandes — músicas, filmes e fotos. Não é um banco de dados, embora PostgreSQL tenha suporte a binários. Para escala, Amazon S3 é o exemplo mais citado, e cada objeto recebe uma URL de acesso.

Na prática, o blob store funciona como fonte da verdade e a entrega acontece por CDN. A CDN, Content Delivery Network, mantém cópias próximas do usuário para reduzir latência em arquivos estáticos que mudam pouco.

O Redis é o cache mais citado em entrevistas. Ele guarda dados acessados com frequência e os mantém perto da aplicação para reduzir o tempo de resposta. A escolha do que entra em cache depende do padrão de acesso, não de espaço disponível.

Cache não é fonte da verdade. É uma cópia temporária, e por isso o problema de invalidação é uma dor recorrente em qualquer sistema que use CDN ou cache. Colocar tudo em cache deixa o sistema mais caro e mais lento, o oposto do que você quer.

Existem padrões diferentes de cache, como cache aside, read through, write through e write around. Entender quando aplicar cada um é o que separa uma resposta genérica de uma decisão bem fundamentada.

Como usar este guia na preparação

Este guia serve como referência para você identificar lacunas antes de uma entrevista. A preparação eficiente consiste em reconhecer cada bloco, saber o trade-off principal e conseguir justificar a escolha com base na regra de negócio do problema apresentado.

Você pode testar seu conhecimento com uma pergunta única: para cada bloco, qual é o custo que ele adiciona e qual o benefício que ele entrega? Se a resposta sair natural, você está pronto para o tópico. Se travar, o vídeo original e o curso de System Design do canal indicam o que estudar primeiro.

Uma dica prática: em quase toda entrevista, você vai mencionar um load balancer, um cache e um banco de dados. São os blocos com maior probabilidade de aparecer, e reconhecer isso direciona seus estudos para os tópicos de maior retorno.

FAQ sobre building blocks de System Design

• O que são building blocks de System Design? São os componentes básicos usados para montar qualquer arquitetura em entrevistas técnicas, como banco de dados, fila, load balancer, API gateway, cache e CDN. Você combina esses blocos para resolver um problema pequeno projetado para escalar a milhões de usuários.

• Preciso saber tudo sobre bancos de dados para uma entrevista? Não. O esperado é entender a diferença entre SQL e NoSQL, conhecer o trade-off de garantias ACID e BASE e saber escolher com base no padrão de acesso. Decorar diferenças entre PostgreSQL e MySQL é menos útil do que justificar sua escolha.

• Por que usar uma fila se ela deixa o sistema mais lento? A fila não acelera a requisição, mas desacopla produtores de consumidores e absorve picos. Ela deixa o sistema mais barato e mais resiliente, o que importa quando o processamento é assíncrono, como envio de e-mail ou processamento de imagem.

• Qual a diferença entre load balancer e API gateway? O load balancer distribui requisições entre servidores para equilibrar carga. O API gateway inspeciona parâmetros da requisição, geralmente a URI, e encaminha para o serviço correto. Os dois podem coexistir no mesmo desenho.

• Quando usar serverless em vez de servidor dedicado? Serverless faz sentido quando o tráfego é instável e tem picos, porque o custo acompanha o uso. Servidores dedicados atendem melhor tráfego constante e demandas intensas de CPU, já que a máquina está sempre disponível.

• Microsserviços precisam rodar em máquinas separadas? Não. É possível rodar vinte microsserviços em uma única máquina, como acontece em ambiente local com várias imagens Docker. Na prática, porém, cada serviço tende a ocupar uma máquina ou uma função independente para escalar de forma proporcional ao seu uso.

• Preciso saber sobre WAF e rate limiting? Sim. Saber que o WAF filtra requisições maliciosas e que o rate limiting limita o volume de chamadas de um usuário já permite citar as duas peças com segurança em uma entrevista de System Design.

• Cache e CDN resolvem o mesmo problema? Não exatamente. O cache guarda dados acessados com frequência perto da aplicação para reduzir latência de consulta. A CDN entrega conteúdo estático, como imagens e vídeos, a partir de servidores próximos do usuário.

• Onde encontrar mais conteúdo sobre System Design em português? O canal do Augusto Galego tem um curso específico de System Design, e comunidades como a Crazystack, com o Bootcamp do Dev Doido e o Crazystack Typescript, ajudam quem quer praticar arquitetura em projetos reais.

Transforme suas aulas em texto com o Skala Blog

Todo o conteúdo deste guia partiu de um vídeo que explica building blocks de System Design em uma sequência didática. Esse mesmo tipo de material, cheio de exemplos e trade-offs, costuma perder alcance quando fica restrito ao formato audiovisual.

Se você produz aulas, entrevistas ou explicações técnicas em vídeo, dá para transformar essa gravação em um artigo estruturado sem reescrever tudo do zero. O fluxo é simples: você cola a URL do vídeo, o sistema transcreve o conteúdo e gera um artigo pronto para revisão.

Skala Blog

Source video