Gustavo Ribeiro
El cronómetro llegó a cero antes del envío; se evaluó el último borrador guardado.
Enviado el 17 oct 2026, 10:45
Evaluado el 17 oct 2026, 10:53
La nota es una recomendación de la IA; la decisión es tuya.
Evaluación
Nota final = 70% diagrama + 30% defensa de las preguntas.
Notas por dimensión
Fortalezas
- 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.
Debilidades
- 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 faltantes
- 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
Sugerencias
- 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.
Señales de integridad
Registradas por el navegador del candidato durante el diseño y la defensa. Son señales para revisar, no prueba: un segundo monitor, una notificación o pegar las propias notas también generan registros. Y la ausencia de registros no garantiza nada, porque otro dispositivo, como un celular, no aparece. Estas señales no cambian la nota.
No se registró ninguna salida de la pestaña, texto pegado ni copia del enunciado.
Diagrama y explicación
En el celular el diagrama se ve reducido. Puedes hacer zoom con dos dedos, pero se lee mejor en la computadora.
Explicación del 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
Preguntas de defensa
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.
Evaluación de la respuesta4.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?
Sin respuesta
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.
Evaluación de la respuesta4.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.