Gustavo Ribeiro
O cronômetro zerou antes do envio; foi avaliado o último rascunho salvo.
Enviado em 17 de out. de 2026, 10:45
Avaliado em 17 de out. de 2026, 10:53
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
- 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.
Pontos fracos
- 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.
Problemas críticos
- 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.
Componentes que faltaram
- 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
Sugestões
- 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.
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.
Nenhuma saída da aba, colagem ou cópia do enunciado foi registrada.
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
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
Perguntas de defesa
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.
Avaliação da resposta4.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?
Sem resposta
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.
Avaliação da resposta4.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.