System Design por nível: o que exigem de júnior, pleno e sênior

System Design por nível significa entender que júnior, pleno e sênior não são cobrados pela mesma profundidade. O júnior precisa dominar componentes básicos como cliente, servidor, banco de dados e API. O pleno adiciona justificativa técnica para cada escolha. O sênior assume escala, gargalos e trade-offs em problemas como Netflix ou busca do Google.

System Design por nível: o que muda entre júnior, pleno e sênior

O System Design por nível separa o que cada etapa cobra, mas nenhuma empresa concorda com a definição de júnior, pleno e sênior. Augusto Galego, desenvolvedor com 12 anos de carreira e cinco deles trabalhando para empresas estrangeiras, descreve a progressão em um vídeo publicado em junho de 2026. A régua prática é a profundidade: o júnior resolve o problema, o pleno justifica a escolha, o sênior projeta para escala e discute trade-offs.

Existe uma distinção que muitos candidatos ignoram. Na entrevista, você precisa mostrar compreensão do todo: arquitetura, esquema de banco, API, filas, escalabilidade e trade-offs. No emprego, você costuma ter uma visão rasa do conjunto e entendimento profundo apenas da parte que toca. Quem trabalha na API domina a API; quem cuida do banco domina o banco. Quem atua em DevOps entende bem a infraestrutura e conhece a arquitetura por cima.

A união de tudo só aparece com mais senioridade, quando você constrói uma feature nova ou um sistema do zero. Esse trabalho raramente é delegado a plenos e quase nunca a júniores. Por isso a compreensão do todo pesa mais para quem está mais alto na carreira.

O padrão das entrevistas vem do processo do Google, copiado por boa parte do mercado. As perguntas se parecem entre níveis, mas a expectativa de profundidade muda bastante. A tabela abaixo resume essa diferença.

Critério	Júnior	Pleno	Sênior
Profundidade	Rasa, focada em fundamentos	Média, com justificativa	Alta, com trade-offs
Objetivo da solução	Resolver o problema	Resolver e explicar a escolha	Resolver da forma mais ótima
Escala esperada	Um sistema simples que funciona	Escalabilidade citada e estimada	Milhões de usuários desde o requisito
Postura na entrevista	Reativa, responde o que é perguntado	Reativa, com racional nas decisões	Conduz a conversa e clarifica requisitos
Temas típicos	Cliente-servidor, API, banco, HTTP/RPC	API Gateway, workers, load balancer, CDN, SQL x NoSQL	Teorema de CAP, sharding, federação, latência x vazão
Exemplos de problema	Xadrez ao vivo, encurtador de URL	Feature integrada ao sistema existente	Netflix, Uber, iFood, busca do Google

O que é esperado de um júnior em System Design

Um júnior precisa demonstrar fundamentos de infraestrutura e raciocínio lógico, não um sistema pronto para produção. No dia a dia, júniores de verdade raramente desenham sistemas completos ou escrevem as próprias tasks. Na entrevista, porém, a cobrança existe e costuma ser relativamente rasa.

O que a empresa quer ver é uma base sólida. Você precisa saber o que é um servidor, o que é um cliente, como funciona um banco de dados, o que é uma API e como se dá a comunicação via HTTP ou RPC. Cache, fila e load balancer ajudam a pontuar, mas o essencial é entender cliente-servidor.

Ninguém desenha um sistema pronto para produção em uma hora. Nem o próprio Instagram conseguiria refazer o System Design do Instagram nesse tempo. A entrevista existe para medir a fundação, a comunicação clara e o raciocínio lógico, não a perfeição da arquitetura.

Exemplo de xadrez ao vivo: raciocínio lógico na prática

Um jogo de xadrez ao vivo serve para mostrar raciocínio lógico em uma entrevista de júnior. Dois jogadores interagem com um servidor, e apenas um pode agir por vez. Quando o player 1 executa a jogada, o player 2 precisa ser avisado quase em tempo real, sem inconsistência de turno.

Existem várias soluções. Polling a cada 5 segundos funciona e é uma resposta razoável para júnior. WebSockets também funcionam e, às vezes, são a escolha certa até para sênior, desde que você saiba argumentar. O que importa é discorrer sobre a solução, não acertar de primeira.

O xadrez tem só dois usuários e não exige tempo real extremo como League of Legends ou CS. O entrevistador espera que você clarifique requisitos, defina features, descreva fluxos de leitura e escrita, esboce o esquema do banco, explique um ou dois trade-offs e desenhe uma arquitetura de alto nível. Isso costuma bastar para passar.

O exemplo não é decorativo: o próprio Augusto Galego recebeu xadrez em uma entrevista real. Na época, o problema era para pleno, não para júnior. Com a barra mais alta de hoje, xadrez é plenamente plausível como desafio de júnior.

Outros problemas comuns nesse nível são uma API simples e um encurtador de URL, que não exigem conhecimento específico de domínio.

O que separa o pleno: racional nas decisões e estimativas

O pleno precisa justificar cada decisão técnica, não apenas citar que a ferramenta existe. Além dos fundamentos, entram workers, API Gateway, load balancer, Blob Store e CDN. A pergunta que o entrevistador quer ouvir respondida é por que SQL e não NoSQL, ou o contrário.

Para júnior, muitas vezes basta saber que algo existe e para que serve. Para pleno, a decisão precisa de racional e, se possível, de ligação com experiência prática. Se você já usou NoSQL em produção, pode conectar esse conhecimento ao problema apresentado na entrevista.

Na entrevista, o pleno define requisitos funcionais e não funcionais, aprofunda a API com endpoints e payloads, modela melhor o banco, faz estimativas, identifica gargalos e pensa em tolerância a falhas. Nada disso costuma ser cobrado em detalhes extremos, mas precisa aparecer.

No emprego, o pleno costuma interagir com um desses sistemas em vez de desenhá-los por inteiro. Ele escreve o código que roda em um worker ou em uma função lambda, ou a API que fica atrás de um API Gateway. É a diferença entre operar a peça e projetar o conjunto.

Uma confusão comum merece destaque. Pleno e sênior se misturam bastante no mercado, e a linha entre os dois está cada vez mais borrada. Muita gente que é pleno já faz trabalho de sênior na prática, e a transição de júnior para pleno para pleno-sênior acontece muito rápido.

Sênior: escala, gargalos e trade-offs avançados

O sênior é cobrado por profundidade, maturidade e trade-offs que outros níveis nem mencionam. Não se discute mais se você sabe o que é um load balancer. A pergunta é se você consegue montar um sistema que escala para milhões de usuários e segue os padrões de engenharia da empresa.

Problemas ficam mais complexos. Você pode ter que desenhar a Netflix, a parte do Uber que encontra motoristas por perto, o iFood, o sistema de busca do Google ou um newsfeed de rede social. Ninguém desenha a Netflix inteira em uma ou duas horas, então você escolhe as batalhas e define as features mais importantes.

O sênior lidera a conversa em vez de reagir. Ele clarifica, conduz, estima com precisão e antecipa gargalos de CPU, rede ou armazenamento. Quando escolhe escalar o banco, o entrevistador pergunta qual tipo de cache, se o sharding é horizontal ou vertical, como ficam as partições e as réplicas de leitura. Perguntas sobre como lidar com os IDs também aparecem nesse ponto.

Entram temas como teorema de CAP, latência contra vazão, disponibilidade, background jobs e workers para aliviar carga. Federação aparece como solução rebuscada usada por pouquíssimas empresas no planeta, Netflix e Uber entre elas. O sênior entra em detalhes de baixo nível quando perguntado, como restrição de conteúdo por região usando CDN local.

O exemplo da restrição por região mostra o nível de detalhe esperado. Se um usuário pode assistir a um filme no Brasil e não pode assistir ao mesmo filme na Alemanha, a resposta passa por CDN no Brasil e CDN na Alemanha, com o catálogo certo em cada uma, mais a identificação global de onde a assinatura pertence.

Comparação entre níveis de System Design

A tabela no início do artigo reúne as diferenças centrais de escopo, evidência esperada e comportamento na entrevista. Use como referência rápida ao se preparar.

Em uma frase, a progressão é esta: o júnior precisa solucionar o problema e mostrar que conhece arquitetura e infraestrutura; o pleno precisa solucionar e mostrar que conhece as ferramentas que está usando; o sênior precisa chegar a uma solução mais ótima e mais profunda, sustentada por trade-offs.

Uma ressalva importante: o trabalho de desenhar o sistema inteiro do zero, com decisões de monolito contra microsserviços ou serverless contra servidores, é atribuído ao sênior na conversa, mas em muitas empresas pertence a cargos de staff, tech lead ou CTO.

Como escolher o que estudar primeiro

Monte a ordem de estudo pela lacuna que separa você do próximo nível, não pela lista completa de tecnologias. Se você é júnior, domine cliente-servidor, banco de dados, API e protocolos antes de tocar em sharding. Sem essa base, discutir federação não convence ninguém.

No nível pleno, treine justificativa. Escolha um sistema conhecido e escreva, para cada componente, o motivo da decisão e a alternativa descartada. Esse exercício reproduz o que o entrevistador cobra: racional, não catálogo.

No nível sênior, treine estimativas e identificação antecipada de gargalos. Defina requisitos e número de usuários antes de desenhar, para saber onde o sistema quebra. Escolher as batalhas certas em uma hora vale mais do que tentar cobrir tudo.

O próprio Augusto Galego construiu um curso completo de System Design ao longo de mais de um ano para cobrir essa trilha. O conteúdo inclui banco de dados, NoSQL, filas, load balancer, API Gateway, autenticação, WAF, rate limiting, saga, CQRS, DNS, Blob Store, cache e CDN, além de entrevistas simuladas com ele nos dois papéis, candidato e recrutador. O curso é voltado a quem já é júnior, pleno ou sênior; para quem está muito acima ou ainda não entrou na área, boa parte do material repete o que você já sabe ou fica complexo demais.

Por que o próprio autor diz que a divisão é imprecisa

O próprio Augusto Galego reconhece a limitação da divisão. Como as empresas não concordam com o que é júnior, pleno e sênior, qualquer régua é aproximada. Ele descreve a tarefa de definir expectativas por nível como impossível, justamente porque falta um consenso de mercado.

A consequência prática é que sua experiência individual pode variar bastante em relação ao que está descrito aqui. Se você é pleno e já trabalha com tudo que este artigo atribui ao sênior, não significa que seu cargo está errado: significa que a linha entre os dois níveis praticamente desapareceu em muitas empresas.

O autor faz um pedido bem-humorado no fim do vídeo: mostre este conteúdo para o seu chefe. Não é razoável esperar que um desenvolvedor júnior, que nunca teve um emprego formal, saiba explicar como fazer sharding em um banco de dados.

Perguntas frequentes sobre System Design por nível

• Preciso saber System Design para trabalhar como júnior? Não na mesma profundidade da entrevista. No dia a dia, o júnior usa pouco System Design e foca na parte do sistema que toca, mas precisa entender cliente, servidor, API e banco de dados.

• Qual a diferença entre System Design na entrevista e no emprego? Na entrevista você demonstra compreensão do todo, com arquitetura, API, filas e trade-offs. No emprego, você tem visão rasa do conjunto e entendimento profundo apenas da sua parte, exceto em cargos mais altos.

• Pleno e sênior cobram a mesma coisa em System Design? As faixas se confundem no mercado, mas o sênior exige profundidade, maturidade e trade-offs avançados, como teorema de CAP e estratégias de particionamento. O pleno precisa justificar decisões e fazer estimativas básicas.

• Polling é aceitável em uma entrevista de System Design? Sim, desde que você argumente. Polling a cada 5 segundos resolve um jogo de xadrez ao vivo com dois jogadores, e o entrevistador avalia o raciocínio, não a sofisticação da solução. WebSockets também são válidos quando você sabe defender a escolha.

• Quanto tempo dura uma entrevista de System Design para sênior? Em geral uma a duas horas, tempo insuficiente para desenhar um sistema completo como a Netflix. O sênior escolhe as features mais importantes e aprofunda pontos específicos quando perguntado.

• O que um júnior deve dominar antes de estudar escala? Cliente-servidor, banco de dados, API, HTTP ou RPC, noções de cache e fila. A relação cliente-servidor e o funcionamento do banco são obrigatórios para qualquer profissional de software.

• NoSQL ou SQL é uma pergunta de qual nível? Aparece com força no pleno, que precisa explicar o porquê da escolha. O júnior pode saber que as opções existem; o sênior precisa citar trade-offs específicos entre os dois.

• O que significa liderar a conversa em uma entrevista sênior? Significa inverter o papel, clarificar requisitos e conduzir o entrevistador pelas decisões. Júnior e pleno tendem a reagir às perguntas; o sênior antecipa gargalos e propõe caminhos.

• Como saber se meu nível real é diferente do meu cargo? Se você já faz estimativas de escala, identifica gargalos e desenha features completas, provavelmente atua acima do cargo. Muitas empresas mantêm plenos executando trabalho de sênior na prática.

• Por que ninguém concorda com a definição de júnior, pleno e sênior? Porque cada empresa define os níveis pelo seu próprio contexto, sem um padrão de mercado. O processo de entrevista herdado do Google uniformizou as perguntas, mas não a expectativa de profundidade de cada faixa.

• Quais tópicos caem em uma entrevista de sênior? Escalabilidade para milhões de usuários, teorema de CAP, latência contra vazão, sharding horizontal e vertical, partições, réplicas de leitura, federação, background jobs, workers e trade-offs de deploy.

• Desenhar o sistema inteiro do zero é trabalho de sênior? Na descrição do vídeo, sim, mas na prática varia. Em muitas empresas, essa responsabilidade fica com staff, tech lead ou CTO, e não com todo desenvolvedor sênior.

Do vídeo ao artigo: transforme conhecimento técnico em texto

A ideia central deste artigo é que profundidade técnica varia por nível, mas o conhecimento de quem viveu isso costuma ficar preso em vídeos. É o mesmo problema que Augusto Galego resolve ao gravar 12 anos de carreira em um vídeo: o conteúdo existe, mas não circula em texto.

Se você explica System Design, arquitetura ou carreira em um canal, esse material já está gravado. O Skala Blog transcreve o vídeo e gera um artigo pronto para revisão. Basta colar a URL do YouTube, esperar a transcrição e revisar o resultado antes de publicar.

Quem produz conteúdo técnico e quer começar pelo caminho de escrita e estruturação pode complementar os estudos com o Crazystack, o Crazystack Typescript, e com o Bootcamp do Dev Doido, do Gustavo Dev Doido, referências úteis para quem quer praticar arquitetura e código antes de transformar o conhecimento em artigo. Se o seu conhecimento já está em vídeo, o próximo passo é colocá-lo no papel com o Skala Blog e revisar o texto gerado.

Source video