Fernanda Lopes
Enviado el 17 oct 2026, 11:22
Evaluado el 17 oct 2026, 11:26
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
- Identificou os fluxos básicos de entrada (notificação de pagamento) e consulta por parte do cliente final via aplicativo.
Debilidades
- 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 faltantes
- Message Broker / Queue (ex: Kafka ou RabbitMQ)
- Ledger / Tabela de Extrato de Cashback
- Mecanismo de Cache / Leitura rápida de saldo
Sugerencias
- 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.
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.
- Salió de la pestaña o de la ventana 1× durante 45 s en total.
Línea de tiempo
Tiempo contado desde el inicio de cada etapa.
- Diseño 10:40Salió de la pestaña durante 45 s
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
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.
Preguntas de defensa
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?
Sin respuesta
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?
Sin respuesta
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?
Sin respuesta