Confirmar o envio das respostas e processá-las com segurança depois

na Dynamox

Desenhei e conduzi com apoio do time um fluxo para que inspetores recebessem confirmação assim que as respostas fossem validadas e armazenadas, enquanto o processamento pesado acontecia em segundo plano. A caixa de saída mantém cada grupo rastreável e reprocessável; o resultado é qualitativo, sem métrica antes e depois.

impactoO aplicativo recebe confirmação depois da validação e do armazenamento durável, sem esperar o processamento completo. Falhas posteriores podem ser rastreadas e reprocessadas. Não há métrica comparativa de desempenho ou taxa de falhas.

Contexto

Ao fim de uma rota, o aplicativo envia de uma vez as respostas coletadas pelo inspetor. A conexão pode cair, e o servidor fazia o processamento dentro da requisição.

Problema

Envios grandes demoravam porque o aplicativo aguardava todo o processamento. Uma queda de conexão podia deixar incerto o que foi salvo, e os horários de pico concentravam a carga.

Restrições

O aplicativo é usado em campo, onde a conexão pode ser instável. O inspetor precisa saber que as respostas estão seguras antes de seguir para a próxima tarefa.

Nem tudo podia ficar para o processamento em segundo plano: erros corrigíveis pelo inspetor precisavam voltar na requisição; falhas internas precisavam ficar rastreáveis e recuperáveis.

Um envio podia conter diferentes tipos de resposta, e uma conexão instável também podia fazer o aplicativo reenviar o mesmo conteúdo.

Decisão

Separei a confirmação do recebimento do momento em que o processamento termina. A API valida o que o inspetor pode corrigir, grava respostas válidas em grupos rastreáveis e confirma o armazenamento. Um consumer processa os grupos depois.

As mensagens passam pelo Kafka. O consumer grava as respostas finais e publica eventos para relatórios e histórico. Falhas ficam registradas com dados suficientes para investigação e reprocessamento.

Trade-offs

A confirmação significa que as respostas foram validadas e armazenadas com segurança, não que já estejam visíveis em todo lugar. A resposta fica rápida, com uma janela curta de consistência eventual.

Resultado

O aplicativo não precisa aguardar todo o processamento para receber confirmação. O processamento pesado saiu do caminho da requisição; falhas posteriores podem ser identificadas e reprocessadas. Não foi medida uma diferença antes e depois.

Lições

Uma confirmação síncrona deve prometer só o que já está garantido. Neste fluxo, isso era “validado e armazenado com segurança”, não “processado”.

Erros que o usuário consegue corrigir devem voltar na requisição; falhas do processamento ficam registradas para recuperação.

Evidências

—A documentação funcional interna explica o fluxo para pessoas não engenheiras.

—Os logs registram cada envio e grupo processado, incluindo o tempo até a integração.