Gustavo Ribeiro
The timer ran out before submission; the last saved draft was evaluated.
Submitted on Oct 17, 2026, 10:45 AM
Evaluated on Oct 17, 2026, 10:53 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
- Utilização de cache no Redis para mitigar leituras frequentes de saldo pelo aplicativo mobile.
- Separação básica entre o cliente mobile, o load balancer e a camada de serviço da API.
Weaknesses
- Violação da restrição de integração: o sistema de pagamentos faz chamadas HTTP síncronas (POST/DELETE) em vez de o serviço de cashback consumir eventos de um log/fila durável.
- Violação do requisito de extrato contábil: a modelagem baseia-se em mutação direta (`UPDATE saldo`) sem um ledger append-only (livro-razão), impossibilitando auditoria, rastreio de transações e a exibição de extrato ao cliente.
- Violação do NFR de nunca creditar duas vezes: ausência de chave de idempotência baseada no identificador da compra ou restrição única no banco para suportar entregas at-least-once.
- Não atende à restrição de tolerar desordem de eventos: a abordagem com chamada DELETE síncrona que apenas subtrai o saldo falha se o reembolso chegar antes da confirmação da compra.
- Violação da restrição de regras de campanha: nenhuma estrutura de dados ou mecanismo de regras sem deploy foi desenhado ou concluído na explicação.
Critical issues
- Acoplamento síncrono crítico no fluxo de pagamentos: se a API de cashback falhar ou oscilar sob o pico de 400 req/s, o processamento de pagamentos pode ser bloqueado ou falhar.
- Risco severo de inconsistência financeira e duplicidade por ausência total de idempotência e ausência de ledger contábil.
Missing components
- Fila ou log distribuído de mensageria (ex: Kafka, SQS) para ingestão assíncrona de eventos
- Tabela ou repositório de ledger contábil para histórico e extrato de transações
- Armazenamento de regras de campanha dinâmicas
Suggestions
- Substituir os endpoints HTTP POST/DELETE por um message broker/log distribuído (como Apache Kafka ou RabbitMQ) para consumir eventos de compra e reembolso de forma assíncrona.
- Implementar um ledger contábil append-only com entradas de crédito, débito e estorno com chave de idempotência (`purchase_id`), derivando ou materializando o saldo.
- Criar uma tabela no banco relacional para persistir regras de campanha (categorias, percentuais, limites mensais), permitindo alterações dinâmicas sem deploy.
- Desenhar o fluxo de resgate com bloqueio pessimista ou reserva atômica no banco relacional para assegurar que o saldo nunca fique negativo.
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.
No tab exits, pastes or statement copies were recorded.
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
Quando a compra é aprovada o sistema de pagamentos chama POST /cashback na nossa API com o valor e o cliente. A API calcula a porcentagem da categoria e soma no campo saldo da tabela de clientes. O saldo fica em cache no Redis para o app não bater no banco toda hora. Para o reembolso o pagamentos chama DELETE /cashback e a API subtrai. As regras das campanhas
Defense questions
1. Sua modelagem atual faz um UPDATE direto no campo de saldo da tabela de clientes. Como você planeja garantir a idempotência de chamadas duplicadas, rastrear estornos parciais e gerar o extrato histórico de lançamentos sem uma estrutura de ledger (livro-razão)?
Dá para criar uma tabela de histórico com as compras e consultar antes de fazer o UPDATE para ver se já existe.
Answer review4.0
A resposta identifica a necessidade de rastrear compras anteriores por meio de uma tabela de histórico para evitar duplicidades. No entanto, não aborda o tratamento de estornos parciais nem a modelagem de um livro-razão imutável, além de propor uma verificação antes da escrita que é suscetível a condições de corrida sem travas ou restrições de unicidade.
2. Considerando a restrição de que eventos podem chegar fora de ordem (como uma solicitação de estorno chegar antes da confirmação da compra), como sua API lidará com a requisição de DELETE /cashback se o registro da compra original ainda não existir no banco de dados?
No answer
3. Como você pretende armazenar e avaliar as regras de campanha dinâmicas (como tetos mensais por cliente e percentuais por categoria) para que mudem sem deploy e suportem o pico de 400 requisições por segundo sem sobrecarregar o MySQL?
As regras ficariam numa tabela no MySQL e a API consulta a cada compra. Com o Redis de cache não deve sobrecarregar.
Answer review4.5
A resposta acerta ao sugerir o armazenamento das regras em banco de dados com camada de cache em Redis para absorver a carga de leitura. Contudo, não detalha a invalidação desse cache após alterações dinâmicas e ignora como avaliar tetos acumulados por cliente no mês de forma atômica e performática.