APRENDER. PRATICAR. EVOLUIR.Desenhar estados que o negócio compreende
Imagina um fecho de fundos submetido por uma interface interna. O botão pode aceitar o pedido antes de a reconciliação acabar. Define estados distintos para aceite, em processamento, concluído e resultado incerto; cada um precisa de evidência e de um responsável. A resposta HTTP 202 de uma invocação assíncrona apenas permite avançar para aceite. Guarda a identidade da operação e disponibiliza uma consulta de estado. No handover, explica como distinguir um pedido ainda pendente de um pedido que exige intervenção para cumprir o horário de fecho.
Verificar também a recuperação
Um destino de falha é outra dependência operacional. Um registo de invocação pode ajudar a reconstruir o que aconteceu, mas a sua entrega também pode falhar. Numa simulação autorizada, provoca uma falha conhecida e confirma o registo esperado e o alerta. Se a fila estiver vazia, compara essa observação com DestinationDeliveryFailures antes de concluir que não há incidentes. Define quem pode consultar os dados e como evitar que informação sensível circule em canais de suporte. O runbook deve incluir o procedimento quando a própria recolha de evidência falha.
Separar fila assíncrona de stream
Não transfiras automaticamente a configuração de uma invocação assíncrona para um event source mapping. Num stream, o mapping lê um shard e entrega um lote à função; o checkpoint influencia o trabalho que será retomado. Regista no desenho quem lê, quem confirma e que estado persiste entre tentativas. Para um movimento de fundos, a identidade de negócio deve sobreviver à repetição de um lote e à alteração do ID técnico da invocação. Uma reunião de desenho deve percorrer explicitamente uma falha antes e depois de uma chamada externa.
Resolver um lote com sucesso parcial
No exercício, 201 conclui, 202 falha, 203 falha e 204 conclui. Com a resposta parcial ativa, a menor sequência falhada estabelece o início da repetição: 202. O efeito de 204 pode voltar a ser pedido apesar de ter concluído. Desenha um registo durável que permita reconhecer o resultado anterior. Devolver apenas IDs falhados não é uma promessa de execução única dos restantes. Ensaiar uma paragem na primeira falha pode simplificar a sequência, mas não elimina outras origens de duplicação. Documenta essa diferença para a equipa de suporte.
Evitar regressões no índice de relatórios
Um índice mantido por notificações S3 não deve tratar a ordem de chegada como ordem das alterações. Conserva o sequencer por chave, normaliza o comprimento para a comparação hexadecimal e usa uma atualização condicional para impedir corridas entre consumidores. No caso 0A seguido de 9, compara 0A com 09 e rejeita a regressão. Não compares esses valores entre chaves distintas. Descodifica a chave segundo o formato do evento antes de pedir o objeto. Regista a razão de um evento ignorado para distinguir duplicação prevista de perda de trabalho.
Calcular o prazo antes de escolher retries
O modelo usa três execuções de um segundo, separadas por esperas de dois e quatro segundos: nove segundos no total. MaxAttempts=2 permite duas repetições além da primeira execução. Com um prazo de oito segundos, o plano não cabe mesmo antes de contar rede ou overhead. O modelo exclui jitter, SDK retries e agendamento; no sistema real mede esses efeitos. O nome do erro também importa: States.TaskFailed não cobre States.Timeout. Define o tratamento da expiração e o estado incerto do negócio sem assumir que terminar a espera cancela um efeito externo.
Preparar replay e acompanhar a recuperação
Antes de replay, confirma compatibilidade dos eventos guardados com a versão corrigida e mantém a identidade da operação. Começa com uma amostra cujo resultado possa ser reconciliado. Se chegam 120 registos por segundo e concluem 100, o backlog cresce 20 por segundo; aumentar retenção apenas dá mais tempo. Para recuperar 6000 registos com entrada constante de 120 e capacidade de 150, o saldo de recuperação é 30 por segundo e o modelo demora 200 segundos. Interrompe a extrapolação se houver falhas, variação de carga ou um shard que concentre o atraso.
Num fecho fictício, o checkpoint repete 204 já concluído. A equipa reconhece a identidade de negócio e verifica o resultado existente antes de contactar novamente o fornecedor.
Armadilhas comuns
Confundir 202 com conclusão; aplicar o contrato SQS a um stream; ordenar objetos diferentes por sequencer; ignorar retries internos ao calcular o prazo.
Tópicos relacionados: Idempotência e contratos de dados · Monitorização de backlog
Recuperação credível exige reconhecer efeitos anteriores, conservar trabalho falhado e provar que o caminho de diagnóstico funciona.
Referência: Lambda with Kinesis · DVA-C02; exam guide 2.1