Fernanda Lopes
Submitted on Oct 17, 2026, 11:22 AM
Evaluated on Oct 17, 2026, 11:26 AM
The score is an AI recommendation; the decision is yours.
Evaluation
Final score = 70% diagram + 30% defense of the follow-up questions.
Scores by dimension
Strengths
- Identificou os fluxos básicos de entrada (notificação de pagamento) e consulta por parte do cliente final via aplicativo.
Weaknesses
- 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.
Critical issues
- 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.
Missing components
- Message Broker / Queue (ex: Kafka ou RabbitMQ)
- Ledger / Tabela de Extrato de Cashback
- Mecanismo de Cache / Leitura rápida de saldo
Suggestions
- 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.
Integrity signals
Recorded by the candidate's browser during the design and the defense. They are signals to review, not proof: a second monitor, a notification or pasting one's own notes also create records. And no records doesn't rule anything out, because another device, such as a phone, doesn't show up. These records don't change the score.
- Left the tab or window 1× for 45 s in total.
Timeline
Time counted from the start of each step.
- Design 10:40Left the tab for 45 s
Diagram and explanation
On a phone the diagram is shown smaller. You can pinch to zoom, but it reads better on a computer.
Candidate's explanation
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.
Defense questions
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?
No answer
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?
No answer
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?
No answer