Larissa Campos
Enviado em 17 de out. de 2026, 09:48
Avaliado em 17 de out. de 2026, 09:55
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
- Uso de fila SQS para desacoplar a ingestão de eventos do sistema de pagamentos externo, garantindo que o fluxo de checkout não seja bloqueado.
- Armazenamento de regras de campanha no S3 com recarga periódica em memória, atendendo ao requisito de alterar regras sem a necessidade de deploy.
Pontos fracos
- Violação da restrição de eventos fora de ordem: a solução não descreve como tratar um reembolso que chega antes da confirmação da compra, o que pode falhar ou gerar inconsistências.
- Implementação de idempotência baseada em verificação prévia (check-then-act: consulta antes de inserir) sem constraint de unicidade no banco, suscetível a race conditions em entregas concorrentes no SQS.
- Controle de concorrência frágil no resgate (checkout): checar saldo na API antes de subtrair via UPDATE expõe o sistema a resgates concorrentes que podem deixar o saldo negativo, violando a regra de nunca ficar abaixo de zero.
- Modelagem de dados baseada em mutação direta de saldo (`UPDATE clientes SET saldo = ...`) em vez de um modelo formal de livro-razão (ledger) append-only como fonte primária da verdade.
Componentes que faltaram
- Dead Letter Queue (DLQ) ou fila de reprocessamento para eventos fora de ordem e falhas
Sugestões
- Adicionar uma constraint de chave única (UNIQUE) em `purchase_id` no MySQL para garantir idempotência a nível de banco de dados e evitar créditos duplicados mesmo com múltiplos workers paralelos.
- Utilizar atualização atômica condicional no checkout (`UPDATE clientes SET saldo = saldo - :valor WHERE id = :id AND saldo >= :valor`) ou padrão de reserva temporária para assegurar que o saldo nunca fique negativo.
- Modelar uma tabela de ledger (extrato append-only) contendo eventos imutáveis (crédito, débito, estorno) e derivar o saldo acumulado a partir dela.
- Implementar uma tabela de 'operações pendentes' ou Dead Letter Queue (DLQ) com retentativa para acomodar eventos de reembolso que cheguem antes da compra confirmada.
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.
- Saiu da aba ou da janela 4× por 7 min 5 s no total.
- Colou texto 2×: 1.340 caracteres no total; o maior trecho tinha 910.
- Copiou trechos do enunciado 1× (640 caracteres no total).
Linha do tempo
Tempo contado desde o início de cada etapa.
- Desenho 02:50Copiou 640 caracteres do enunciado
- Desenho 07:50Saiu da aba por 1 min 35 s
- Desenho 18:50Saiu da aba por 2 min 20 s
- Desenho 32:50Saiu da aba por 1 min 20 s
- Desenho 36:00Colou 910 caracteres na explicação
- Desenho 36:30Saiu da aba por 1 min 50 s
- Defesa 03:20Colou 430 caracteres na resposta 2
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
O sistema de pagamento manda a compra para uma fila SQS. Um worker lê a fila, carrega as regras de um JSON no S3 (recarrega a cada 5 minutos) e calcula o valor do cashback. Para não creditar duas vezes, o worker consulta se a compra já está na tabela de cashback antes de inserir. Se não estiver, insere a compra e faz UPDATE clientes SET saldo = saldo + valor. Quando chega reembolso, o worker faz o mesmo cálculo e subtrai do saldo. A API de cashback responde saldo e extrato direto do MySQL. No checkout, a API confere se o saldo é suficiente e faz o UPDATE subtraindo o valor usado. Para escalar, aumento o número de workers e uso réplicas de leitura no MySQL se precisar.
Perguntas de defesa
1. Sua estratégia contra duplicidade e resgates baseia-se em consultar o banco antes de atualizar ('check-then-act'). Como você evita condições de corrida tanto entre workers concorrentes processando a mesma mensagem SQS em paralelo quanto em múltiplos resgates simultâneos no checkout para garantir que o saldo nunca fique negativo?
Dá para usar uma transação com SELECT FOR UPDATE na linha do cliente antes de atualizar o saldo, assim dois workers não atualizam ao mesmo tempo. No checkout faço a mesma coisa.
Avaliação da resposta5.0
O uso de SELECT FOR UPDATE resolve a concorrência imediata no checkout para evitar saldo negativo, mas não soluciona a idempotência na ingestão de mensagens duplicadas da SQS sem uma restrição única explícita no banco de dados. A resposta não aborda constraints de unicidade nem mecanismos de idempotency key para evitar inserções duplicadas caso duas transações concorrentes chequem a existência da compra.
2. Uma das restrições críticas é que eventos podem chegar fora de ordem (um reembolso antes da compra) e podem existir reembolsos parciais. Como o seu worker lida com o cálculo e persistência se a mensagem de estorno chegar antes da confirmação original da compra?
Em sistemas distribuídos, a ordenação de mensagens não é garantida. Uma abordagem comum é utilizar filas FIFO, que garantem a entrega na ordem de envio, combinadas com deduplicação baseada em um identificador único da mensagem. Assim, os eventos de uma mesma compra são processados na sequência correta e o estorno só é aplicado depois do crédito, evitando inconsistências no saldo do cliente e garantindo a integridade dos dados.
Avaliação da resposta3.0
A resposta sugere filas FIFO como solução genérica, mas ignora a premissa explícita do desafio de que o sistema de pagamento é externo e os eventos chegam fora de ordem da origem. Faltou propor um padrão de compensação, retenção em estado pendente ou tabela de eventos desordenados para reconciliar o estorno quando a compra de fato for processada.
3. Para aplicar a regra de teto (cap) mensal de cashback por cliente sob um pico de 400 compras por segundo, como você estrutura a modelagem e bloqueios no MySQL para evitar gargalos de lock contention ou consultas agregadas pesadas a cada transação?
Eu guardaria um campo total_mes na tabela de clientes e somaria ali a cada crédito. Como cada cliente compra poucas vezes, não acho que vai ter muita disputa de lock.
Avaliação da resposta4.5
A criação de um acumulador desnormalizado por cliente simplifica a verificação do teto e evita agregações pesadas na leitura. Contudo, a resposta não detalha o ciclo de virada de mês (reset do campo) nem o controle transacional caso ocorram reembolsos ou concorrência no fechamento do teto mensal.