Fernanda Lopes
Enviado em 17 de out. de 2026, 11:22
Avaliado em 17 de out. de 2026, 11:26
A nota é uma recomendação da IA; a decisão é sua.
Avaliação
Nota final = 70% diagrama + 30% defesa das perguntas.
Notas por dimensão
Pontos fortes
- Identificou os fluxos básicos de entrada (notificação de pagamento) e consulta por parte do cliente final via aplicativo.
Pontos fracos
- Acoplamento síncrono direto entre o sistema de pagamento e o backend: a restrição do desafio exige o consumo de eventos assíncronos gerados pelo time de pagamentos.
- Ausência de controle de idempotência: viola o requisito não-funcional de nunca creditar uma compra duas vezes sob entregas at-least-once.
- Atualização direta e mutável do saldo ('soma o cashback no saldo') em vez de um modelo de ledger append-only (livro-razão), impossibilitando auditoria, estornos parciais e emissão de extrato.
- Requisitos funcionais essenciais não foram abordados: motor/tabela de regras de campanha, estornos de compras fora de ordem e fluxo de resgate com garantia de saldo não-negativo.
Problemas críticos
- Falta de um intermediador de mensagens durável (fila/tópico): se o backend oscilar durante o pico de 400 compras/s na Black Friday, eventos de compra serão perdidos.
- Inexistência de chave de idempotência por ID de compra no banco de dados, permitindo créditos duplicados ao receber retentativas de eventos de pagamento.
Componentes que faltaram
- Message Broker / Queue (ex: Kafka ou RabbitMQ)
- Ledger / Tabela de Extrato de Cashback
- Mecanismo de Cache / Leitura rápida de saldo
Sugestões
- Introduza uma fila ou stream de eventos (como Apache Kafka ou AWS SQS) entre o sistema de pagamento e os consumidores de cashback para garantir desacoplamento e absorção de picos.
- Adote uma modelagem financeira baseada em ledger append-only com entradas de crédito, débito e estorno, mantendo o saldo como uma visualização materializada.
- Implemente uma tabela ou cache de regras de campanha que permita a alteração dinâmica de porcentagens e limites sem a necessidade de deploy da aplicação.
- Adicione um mecanismo de reserva atômica (ou transação com lock otimista/pessimista) no momento do checkout para garantir que o saldo nunca fique negativo em resgates concorrentes.
Sinais de integridade
Registrados pelo navegador do candidato durante o desenho e a defesa. São sinais para revisar, não prova: um segundo monitor, uma notificação ou colar as próprias anotações também geram registros. E a ausência de registros não garante nada, porque outro dispositivo, como um celular, não aparece. Esses registros não mudam a nota.
- Saiu da aba ou da janela 1× por 45 s no total.
Linha do tempo
Tempo contado desde o início de cada etapa.
- Desenho 10:40Saiu da aba por 45 s
Diagrama e explicação
No celular o diagrama aparece reduzido. Dá para usar dois dedos para zoom, mas a leitura fica melhor no computador.
Explicação do candidato
O pagamento avisa o backend quando tem compra e o backend soma o cashback no saldo do cliente no banco. O app consulta o saldo no backend.
Perguntas de defesa
1. O sistema de pagamento entrega eventos pelo modelo at-least-once e fora de ordem (um reembolso pode chegar antes da confirmação). Como sua arquitetura garante idempotência para evitar créditos duplicados e como você lida com um estorno recebido antes do evento de compra?
Sem resposta
2. Como você modelou a persistência do saldo e do extrato no banco para evitar condições de corrida em resgates concorrentes (garantindo que o saldo nunca fique negativo), sem gerar gargalos de lock na linha do cliente durante o pico de 400 compras por segundo?
Sem resposta
3. As regras de campanha mudam semanalmente sem necessidade de deploy e exigem limites mensais por cliente. De que forma o backend armazenará, avaliará essas regras dinâmicas e calculará o teto mensal acumulado sem sobrecarregar o banco de dados?
Sem resposta