System design em fintechs brasileiras: o que esperar e como estruturar a resposta
Na entrevista de system design de fintechs e grandes empresas brasileiras, o que mais pesa não é o desenho bonito, e sim como você trata dinheiro, falhas e consistência: idempotência, filas, reprocessamento e trade-offs ditos em voz alta. Não existe um roteiro oficial publicado do Nubank ou do iFood; o que há são relatos de candidatos. Abaixo, uma estrutura de resposta que funciona em qualquer uma delas e o que está (e o que não está) confirmado.
O que se sabe (e o que não se sabe) sobre o processo do Nubank e do iFood
Nenhuma das duas empresas publica a lista de etapas de engenharia em suas páginas de carreiras que consegui abrir hoje: a página de carreiras do iFood mostra só o título, e o processo de cada vaga aparece na descrição da vaga. Tudo o que circula vem de relatos de candidatos e de guias de preparação, então trate como indício, não como regra.
- Nubank: um guia de preparação que reúne relatos de candidatos descreve, em ordem: conversa com recrutador, desafio de código online (por exemplo em plataforma como CodeSignal), live coding, system design em quadro online, pair programming com uma pessoa sênior em código real e entrevista comportamental. Segundo o mesmo guia, o quadro costuma ser algo como Miro ou Excalidraw, e os cenários vêm do domínio da própria empresa: ledger, pagamentos e detecção de fraude. Ele cita perguntas sobre modelos de consistência, idempotência e arquitetura orientada a eventos. Não confirmado pela empresa; a ordem e as etapas variam por vaga e por época.
- iFood: um guia de carreira de 2026 descreve uma sequência comum (triagem de currículo, recrutador, gestor, teste técnico ou case, pares, conversa final) e ele mesmo diz que isso muda conforme área, senioridade e urgência. Não há fonte oficial nele. Não confirmado.
Conclusão prática: na candidatura, pergunte ao recrutador quais etapas existem para aquela vaga, quanto tempo dura cada uma, se há quadro compartilhado e o que é permitido consultar. Essa é a única fonte que vale.
O que o entrevistador de system design quer ver
Em empresas que lidam com dinheiro, a entrevista de system design costuma testar três coisas além do conhecimento de componentes (banco, cache, fila, balanceador):
- Corretude antes de escala. Um saldo errado é pior que uma tela lenta. Mostre que você pensa primeiro em "o que não pode dar errado".
- Raciocínio sobre falhas. Timeout, retry, mensagem duplicada, serviço fora do ar, partição de rede. O que acontece com a transação no meio do caminho?
- Comunicação. Você pergunta requisitos, nomeia o trade-off e explica por que escolheu um lado. Silêncio de dez minutos desenhando caixas é o erro mais comum.
Se você ainda não tem um esqueleto de resposta, veja primeiro o nosso guia de live coding, que trata da comunicação em voz alta, e depois aplique à parte de arquitetura abaixo.
Roteiro de 45 minutos para responder
1. Requisitos e escopo (5 a 7 min)
Pergunte: quem usa, quantas operações por segundo (estime em voz alta, sem inventar um número "oficial"), qual o requisito de latência, o que é consistência obrigatória e o que pode ser eventual. Em um exemplo de transferência entre contas, o requisito forte é: o dinheiro nunca some nem duplica.
2. Interface e modelo de dados (5 min)
Defina os endpoints principais e as entidades. Para dinheiro, vale citar um modelo de lançamentos imutáveis (cada movimentação é um registro novo, o saldo é derivado), em vez de atualizar um número no lugar. Diga por quê: auditoria e reprocessamento.
3. Desenho de alto nível (10 min)
Cliente, API, serviço de domínio, banco, fila de eventos, consumidores. Desenhe o caminho feliz primeiro e deixe claro onde os dados persistem.
4. Aprofundamento em um ponto crítico (10 a 15 min)
O entrevistador costuma escolher um. Os mais prováveis em fintech: idempotência, consistência entre serviços, e fraude em tempo real. Veja as duas seções seguintes.
5. Gargalos, falhas e evolução (5 a 10 min)
Cache, particionamento, observabilidade, o que você monitoraria. Termine nomeando o que faria diferente com mais tempo.
Idempotência: o conceito que mais aparece
Idempotência significa que repetir uma operação não a executa duas vezes. É o que impede cobrar duas vezes quando o app reenvia a requisição por causa de um timeout. A documentação pública da Stripe descreve bem o mecanismo: o cliente gera uma chave única, o servidor guarda o resultado da primeira requisição com aquela chave e, em retentativas, devolve o resultado salvo. Na documentação da API v1, as chaves podem ser removidas após pelo menos 24 horas, e o sistema compara os parâmetros da nova requisição com os da original, devolvendo erro se forem diferentes.
Na entrevista, você pode reaproveitar a ideia em uma transferência:
- o cliente envia um identificador único da operação;
- o serviço grava a chave e o resultado na mesma transação do banco que registra o lançamento;
- uma retentativa com a mesma chave devolve a resposta anterior em vez de criar novo lançamento;
- chave igual com parâmetros diferentes é rejeitada.
Mencione também que o consumidor de fila precisa ser idempotente, porque a maioria dos brokers entrega "pelo menos uma vez".
Consistência, eventos e fraude
Consistência. Quando uma transferência atravessa mais de um serviço, uma transação distribuída única costuma ser cara. Alternativas que você pode comparar em voz alta: padrão saga (passos com compensação), outbox (gravar o evento na mesma transação do dado e publicar depois), e consistência eventual onde o negócio aceita. Diga qual escolheria e o custo: mais complexidade de compensação, janelas em que o estado é intermediário.
Orientação a eventos. Eventos imutáveis permitem reconstruir o estado e alimentar outros times (extrato, notificações, antifraude). Cite ordenação por chave de partição e reprocessamento.
Fraude em tempo real. Desenhe um caminho síncrono curto (regras rápidas que aprovam ou barram em poucos milissegundos) e um caminho assíncrono (modelos e análises mais pesadas que podem reverter ou sinalizar depois). O trade-off é falso positivo contra fraude passando.
Isso vale também para fluxos de pagamento instantâneo em geral: o desenho precisa funcionar 24 horas por dia, então fale de degradação controlada e de filas de reprocessamento. Não afirmo regras específicas do Pix aqui porque não consegui confirmar a página oficial hoje.
Erros comuns de quem vem de LeetCode
- Começar pelo banco de dados sem perguntar nada.
- Citar tecnologia por moda (Kafka, Kubernetes) sem dizer o problema que ela resolve.
- Ignorar falha parcial: "a requisição dá certo ou erra" não existe em sistema distribuído.
- Falar números inventados com tom de certeza. Estime, rotule como estimativa e mostre a conta.
- Não fechar: terminar sem resumir o desenho e os trade-offs deixa a impressão de incompleto.
Para a parte de código que costuma vir antes, veja os guias do HackerRank e do CodeSignal.
Como praticar e o que fazer se bater o nervosismo
Pratique em voz alta, com cronômetro, em três cenários: transferência entre contas, notificações em massa e encurtador de links. Grave e ouça: você nomeou o trade-off ou só a ferramenta? Para entrevista em inglês, o guia de entrevista técnica em inglês ajuda.
Se você usa o Interview Copilot, o plano gratuito (sem cartão) serve bem como ensaio: 5 minutos de reconhecimento ao vivo para ver como as sugestões aparecem enquanto você treina. Veja a página do plano gratuito. Sobre o uso em entrevista real: as regras mudam por empresa e por vaga; pergunte ao recrutador o que é permitido antes. No macOS e no Windows a janela pede ao sistema para não aparecer na captura de tela; no Linux ela fica visível, e o resultado depende do programa de compartilhamento. Teste com um compartilhamento privado e nunca use o app onde ele for proibido. Mais em assistente de entrevista invisível.
Fontes
- DesignGurus — Nubank interview process, round by round (relatos de candidatos, não oficial)
- JobRise — iFood entrevista 2026 (guia, sem fonte oficial)
- iFood Carreiras — página oficial (sem descrição de etapas)
- Stripe Docs — Idempotent requests (mecanismo de chave de idempotência)
- Nubank Building — blog de engenharia (apenas títulos consultados)
Perfil da empresa e etapas: verificado em 13/11/2026; relatos de candidatos podem estar desatualizados.
FAQ
O Nubank publica as etapas da entrevista técnica?
Não encontrei uma lista oficial nas páginas que abri hoje. As etapas descritas (recrutador, desafio online, live coding, system design, pair programming, comportamental) vêm de relatos de candidatos reunidos em um guia de preparação e podem variar por vaga e época. Pergunte ao recrutador o formato exato.
O que costuma cair em system design de fintech?
Segundo relatos, cenários do domínio financeiro: ledger, pagamentos e detecção de fraude, com perguntas sobre consistência, idempotência e arquitetura orientada a eventos. Não é regra oficial, mas esses temas são a base de qualquer sistema que movimenta dinheiro, então vale estudá-los.
O que é idempotência e por que importa na entrevista?
É a propriedade de repetir uma operação sem executá-la duas vezes. Evita cobrança duplicada após timeout e reenvio. A documentação da Stripe descreve o modelo: o cliente gera uma chave única, o servidor guarda o resultado da primeira requisição e devolve o mesmo em retentativas.
Como dividir 45 minutos em uma entrevista de system design?
Uma divisão possível: 5 a 7 minutos de requisitos, 5 de interface e dados, 10 de desenho geral, 10 a 15 de aprofundamento em um ponto crítico e o resto em gargalos e falhas. É um roteiro de estudo, não uma regra das empresas.
Preciso decorar números de escala?
Não. Estime em voz alta, mostre a conta e rotule como estimativa. Números inventados ditos com certeza prejudicam. O entrevistador avalia o raciocínio e se você pergunta os requisitos antes de desenhar.
Posso usar um assistente de IA em uma entrevista de system design?
Depende da empresa e da vaga; muitas proíbem. Pergunte ao recrutador antes e respeite a resposta. Para treinar, ferramentas como o plano gratuito do Interview Copilot servem de ensaio sem risco.