O que é System Design e como estudar para entrevistas

A pessoa que entrevista pede para você desenhar um encurtador de links. Em menos de um minuto, já tem um banco de dados no quadro, antes de qualquer pergunta sobre quantos usuários o sistema vai atender ou quanto tempo um link precisa durar.

Esse começo apressado é um dos erros mais frequentes em entrevistas de system design, a etapa que avalia como você projeta sistemas grandes. Ela costuma pesar em vagas de back-end, principalmente a partir do nível pleno.

Neste guia, você vai entender o que é system design, como a entrevista funciona, quais conceitos estudar e como montar uma rotina de preparação, inclusive com a ajuda da inteligência artificial.

O que a entrevista de system design avalia?

Uma entrevista de system design, ou projeto de sistemas, avalia a sua capacidade de transformar um problema amplo e aberto em uma arquitetura que escale, funcione com confiabilidade e tenha uma estrutura clara.

Como não existe uma única resposta certa, quem entrevista observa o caminho até a solução. Entram na avaliação a forma como você toma decisões, identifica gargalos e justifica os trade-offs, ou seja, o que ganha e o que perde com cada escolha.

Por isso, a conversa importa tanto quanto o diagrama. Como mostramos no artigo sobre como a IA está mudando os processos seletivos em tech , a seleção passou a valorizar quem explica as próprias escolhas. O system design é a etapa em que essa cobrança fica mais evidente.

O que é system design?

System design é o processo de definir como as partes de um sistema se organizam para atender aos requisitos de um produto. Envolve escolher componentes, como servidores, bancos de dados, filas e caches, e decidir como eles se comunicam por meio de APIs.

O tema conversa com a arquitetura de software, mas olha para uma escala maior. A pergunta central é como o sistema se comporta quando o número de usuários, de dados ou de requisições cresce muito.

Vale um alerta para quem pesquisa o assunto: system design é diferente de design system, a biblioteca de componentes visuais usada por times de produto e de front-end. Os nomes parecem, mas os temas são bem distintos.

Requisitos funcionais e não funcionais

Todo projeto parte de dois tipos de requisito. Os funcionais descrevem o que o sistema faz, como criar um link curto e redirecionar quem clica nele.

Os não funcionais descrevem como ele precisa se comportar: tempo de resposta, disponibilidade, segurança e custo. O framework Well-Architected da AWS organiza essas preocupações em seis pilares, entre eles confiabilidade, eficiência de desempenho e otimização de custos.

Como funciona a entrevista de system design?

Essa etapa costuma ocupar uma sessão inteira do processo técnico e aparece com mais frequência em vagas de nível pleno e sênior. Em seleções para estágio e júnior, a tendência é uma versão menor, focada em modelagem de dados ou no desenho de uma API.

O formato é aberto. Você recebe um problema genérico, como um sistema de mensagens, um feed de notícias ou um encurtador de links, e conduz a conversa desenhando em um quadro, físico ou virtual.

Quem entrevista participa o tempo todo. Faz perguntas, muda requisitos no meio do caminho e pede detalhes de um componente específico, para ver como você reage a mudanças.

Há variações por área. Vagas de front-end podem pedir o desenho de uma aplicação do lado do cliente, com gerenciamento de estado e desempenho. Em dados, o foco costuma ser o fluxo de pipelines.

A conversa também testa comunicação. Narrar o raciocínio, confirmar hipóteses e admitir o que não sabe contam pontos, assim como a forma de conduzir a entrevista desde a apresentação, assunto do artigo sobre como se apresentar em entrevista [LINK PENDENTE: slug proposto para o artigo 3/8].

Alt-text: Duas pessoas sentadas lado a lado diante de um notebook analisam um esboço de diagrama no papel, e uma delas aponta um trecho com a caneta.

Legenda: Esboçar a arquitetura enquanto explica o raciocínio aproxima o estudo do formato da entrevista.

Quais conceitos estudar para system design?

Alguns conceitos aparecem em quase toda entrevista. Dominar cada um deles, com exemplos de quando usar e quando evitar, dá repertório para qualquer problema.

Escalabilidade e balanceamento de carga

Escalar verticalmente significa dar mais recursos a uma máquina. Escalar horizontalmente significa adicionar máquinas, o que exige um balanceador de carga para distribuir as requisições entre elas.

Em ambientes de cloud, a escala horizontal costuma ser automatizada, com ferramentas de orquestração de contêineres como o Kubernetes.

Bancos de dados, replicação e particionamento

A escolha entre bancos relacionais e não relacionais depende do formato dos dados e do tipo de consulta. As diferenças estão no artigo sobre SQL e NoSQL. Já o guia de banco de dados cobre os fundamentos.

Em escala, entram a replicação, que copia os dados para outras máquinas e aumenta a disponibilidade, e o particionamento, que divide os dados entre servidores para distribuir a carga.

Cache e CDN

O cache guarda em memória o resultado de consultas frequentes para responder mais rápido. Ferramentas como o Redis são comuns nesse papel. A CDN faz algo parecido com arquivos estáticos, servindo o conteúdo de servidores próximos de quem acessa.

Na entrevista, o ponto importante é saber quando o dado em cache fica desatualizado e como invalidá-lo.

Filas e processamento assíncrono

Filas de mensagens permitem que uma parte do sistema entregue uma tarefa e siga em frente, enquanto outra processa no seu ritmo. Há um exemplo prático no artigo sobre mensageria com Amazon SQS.

Esse desenho combina com arquiteturas de microsserviços, assunto do artigo sobre microsserviços ou monolito, e ajuda a absorver picos de acesso sem derrubar o sistema.

Consistência, disponibilidade e o teorema CAP

O teorema CAP, proposto por Eric Brewer em 2000, diz que um sistema distribuído não consegue garantir ao mesmo tempo consistência, disponibilidade e tolerância a partições de rede. Quando a rede falha, é preciso priorizar uma das duas primeiras.

Na prática, um sistema de pagamentos tende a priorizar consistência, enquanto uma rede social aceita mostrar um contador de curtidas atrasado em troca de ficar no ar. O livro de SRE do Google, aberto para leitura on-line, aprofunda como grandes empresas lidam com confiabilidade.

Para entender como esses serviços funcionam na nuvem, vale assistir a este episódio do nosso canal no YouTube:

https://www.youtube.com/watch?v=wev9fMrg-TU

Como responder a uma pergunta de system design?

Ter um roteiro evita o começo apressado da cena do início. Os passos abaixo funcionam para a maioria dos problemas e deixam claro para quem entrevista como você pensa.

1. Esclareça os requisitos

Pergunte o que o sistema precisa fazer e o que fica fora do escopo. No encurtador de links, vale saber se os links expiram, se haverá links personalizados e se a empresa quer estatísticas de cliques.

2. Estime a escala

Faça contas aproximadas em voz alta. Em um cenário hipotético de 100 milhões de links novos por mês e 100 leituras para cada link criado, o sistema recebe cerca de 40 escritas e 4 mil leituras por segundo.

Se cada registro ocupar 500 bytes, cinco anos de dados somam perto de 3 terabytes. Os números não precisam ser exatos, mas mostram que você considera volume antes de escolher tecnologia.

3. Desenhe a visão geral

Monte os blocos principais e o caminho de uma requisição: o cliente chama a API, o serviço gera o código curto e grava no banco, e a leitura passa por um cache. Fundamentos de algoritmos ajudam aqui, por exemplo na forma de gerar códigos curtos sem colisão.

Defina também os endpoints principais, como uma requisição para criar o link e outra que redireciona a partir do código curto.

4. Aprofunde um componente

Escolha, com quem entrevista, uma parte para detalhar. Pode ser o modelo de dados, a estratégia de cache ou a forma de distribuir os links entre servidores.

No encurtador, o cache é um bom candidato. Se a maior parte dos acessos se concentrar em poucos links populares, guardar esses redirecionamentos em memória alivia o banco de dados.

5. Discuta gargalos e trade-offs

Feche apontando o que pode falhar e como o sistema reage. Diga o que você trocaria se a escala dobrasse e quais custos cada escolha traz, porque é aí que a avaliação de trade-offs aparece de forma mais clara.

Um exemplo: códigos curtos sequenciais são simples de gerar, mas facilitam adivinhar links de outras pessoas. Códigos aleatórios evitam o problema, ao custo de checar colisões a cada criação.

O episódio abaixo, também do nosso canal, reúne dicas para entrevistas de vagas com Java, uma das linguagens mais comuns em back-end:

https://www.youtube.com/watch?v=vqkmbUyXrXc

Como estudar system design para entrevistas?

O estudo rende mais em fases. Avançar para estudos de caso sem os fundamentos costuma levar a respostas decoradas, que desmoronam na primeira pergunta de aprofundamento.

Fase 1: fundamentos

Revise redes, bancos de dados, APIs e a diferença entre front-end e back-end. O curso Fundamentos da Arquitetura de Software Moderna, da Alura, cobre a evolução dos monólitos para arquiteturas modernas, requisitos não funcionais e a documentação de decisões.

Fase 2: componentes e padrões

Estude cada conceito da seção anterior com um exemplo real de uso. Para a parte de escolhas e consequências, o curso Decisões arquiteturais: ADRs, trade-offs e governança técnica aprofunda o registro e a análise de trade-offs.

Fase 3: estudos de caso

Pratique problemas clássicos, como encurtador de links, chat, feed de notícias e sistema de reservas. Blogs de engenharia de empresas de tecnologia contam como sistemas reais foram desenhados e são uma boa fonte primária.

Para cada caso, escreva requisitos, estimativas e um diagrama antes de comparar com soluções publicadas. A comparação mostra o que você deixou de considerar.

Fase 4: simulações

Treine em voz alta, com um quadro e um cronômetro. Um simulador de entrevista com IA pode fazer o papel de liderança técnica e questionar as suas escolhas. Uma simulação com alguém da área completa o treino.

Para quem já usa IA no trabalho, vale estudar também como ela muda a rotina de arquitetura. Em engenharia de software na era da IA, mostramos por que o julgamento técnico ganhou peso.

Quais erros evitar na entrevista de system design?

Alguns hábitos derrubam boas soluções técnicas:

• Pular os requisitos: começar pelo banco de dados antes de entender o problema leva a decisões sem justificativa.
• Decorar arquiteturas prontas: quem entrevista muda um requisito e a resposta decorada deixa de servir.
• Desenhar em silêncio: o raciocínio precisa aparecer em voz alta, mesmo quando você ainda está em dúvida.
• Ignorar falhas e custos: todo componente pode cair e tem um preço, e falar disso mostra maturidade técnica.
• Esquecer a segurança: autenticação, proteção de dados e limites de uso fazem parte do projeto, como mostra o guia de segurança da informação.

Prepare-se para a próxima entrevista técnica

System design se aprende com prática e com repertório de sistemas reais. As carreiras da Alura organizam os estudos de back-end e arquitetura. Já o guia sobre como construir carreira em TI ajuda a planejar a próxima etapa.

O Talent Lab, da Alura, oferece orientação de carreira, mentorias, curadoria de vagas e networking. Você pode conhecer o programa e ver como ele funciona.

Treine a conversa técnica no Modo Entrevista da Alura

O Modo Entrevista, da Alura, simula processos seletivos de tecnologia a partir da vaga que você quer disputar. Você informa o cargo e o foco da conversa, técnico ou comportamental, e pode colar a descrição de um anúncio real.

A entrevista se adapta às suas respostas e passa por histórico profissional, hard skills e soft skills, com a opção de responder em áudio. No fim, um relatório aponta acertos, falhas técnicas e comportamentais e pontos a explorar melhor.

É um bom lugar para ensaiar a explicação das suas decisões técnicas antes da entrevista de verdade. Experimente o Modo Entrevista e use o relatório para decidir o que estudar em seguida.

FAQ sobre system design

O que é system design?

System design, ou projeto de sistemas, é o processo de definir como os componentes de um sistema se organizam e se comunicam para atender aos requisitos de um produto, considerando escala, confiabilidade e custo.

Qual é a diferença entre system design e design system?

System design trata da arquitetura de sistemas, como servidores, bancos de dados e filas. Design system é uma biblioteca de componentes visuais e padrões de interface usada por times de produto e de front-end.

Quem precisa estudar system design?

Principalmente quem disputa vagas de back-end, full stack e infraestrutura de nível pleno ou sênior, em que a entrevista é mais comum. Para júnior, os fundamentos de banco de dados e APIs já ajudam bastante.

Quanto tempo leva para estudar system design?

Depende da base de cada pessoa. Quem já domina banco de dados e APIs costuma precisar de algumas semanas de estudo de conceitos e estudos de caso, além de simulações em voz alta antes da entrevista.

Preciso saber programar para a entrevista de system design?

Nem sempre se escreve código, mas a entrevista pressupõe experiência com desenvolvimento. É ela que permite justificar escolhas de banco de dados, filas e APIs com exemplos concretos.

Como treinar system design sozinho?

Escolha um problema clássico, siga o roteiro de requisitos, estimativas, visão geral, aprofundamento e trade-offs e explique em voz alta. Um assistente de IA pode fazer perguntas de aprofundamento. Antes da entrevista, uma simulação com alguém da área ajuda a validar a explicação.