APRENDER. PRATICAR. EVOLUIR.Extrair uma capacidade com fronteira clara
Um batch fictício de publicação de posições junta validação, transformação e entrega a vários consumidores. Modernizar não exige substituir tudo de uma vez. Um strangler fig pode encaminhar uma capacidade já validada para o serviço novo, mantendo as restantes no legado. Define ownership dos dados, contratos, encaminhamento e critérios de saída antes da separação. Dividir apenas por camada técnica pode manter todos os serviços dependentes da mesma alteração e da mesma transação. A proxy de transição também precisa de capacidade e disponibilidade; acrescentar microserviços não remove esse ponto de falha. Uma anti-corruption layer traduz semântica entre modelos, incluindo unidades, estados e identificadores. Não deve esconder indefinidamente quem é responsável por um contrato incompatível.
Resolver duas escritas sem inventar uma transação global
Se o serviço confirma a base de dados e falha antes de publicar o evento, o consumidor pode nunca conhecer a alteração. No padrão outbox relacional, a alteração de negócio e o registo do evento ficam na mesma transação local. Um publicador separado lê apenas alterações confirmadas e envia o evento. Isto fecha a janela entre commit e intenção de publicação, mas não transforma base de dados e broker numa transação ACID global. A entrega pode repetir-se; preserva identidade do evento, ordem necessária e consumidores idempotentes. Mede atraso e falhas do publicador e define reprocessamento. Confirmar uma linha na outbox não demonstra que o consumidor aplicou o efeito. O estado apresentado ao negócio deve refletir a etapa realmente comprovada.
Compensar efeitos e explicitar irreversibilidade
Uma saga coordena transações locais e ações de compensação quando o fluxo não pode terminar como planeado. Compensar não equivale a executar ROLLBACK numa única transação nem fornece isolamento automático entre sagas concorrentes. Uma reserva pode ser libertada, mas uma notificação já entregue não desaparece. Define quais os passos repetíveis, compensáveis e irreversíveis, com registo durável e responsável pela exceção. Se a compensação falhar, o fluxo continua incompleto; não marques sucesso só porque o erro original foi capturado. Participantes e compensações devem tolerar repetição conforme o contrato. Um circuit breaker pode reduzir pressão sobre uma dependência em falha, mas não prova o resultado de chamadas anteriores nem substitui a reconciliação de efeitos de negócio.
Escolher o workflow e o significado da conclusão
No Step Functions, Standard e Express têm modelos diferentes. Standard suporta fluxos duradouros e padrões de espera por job ou callback; Express tem duração máxima de cinco minutos e não suporta .sync nem .waitForTaskToken. Distingue Express assíncrono, com execução pelo menos uma vez, de síncrono, com execução no máximo uma vez. Estas propriedades não são uma transação global sobre efeitos externos, e retries explícitos podem repetir tarefas. Request Response avança após a resposta da API, que pode apenas confirmar submissão. .sync espera pelo job suportado, mas cancelamento é best effort. Callback exige correlação do token e autorização apropriada; um sistema externo pode comunicar por uma ponte autorizada, respeitando a exigência de principal da mesma conta na devolução do token.
Limitar repetição e gerir o erro certo
Um Retry aplicável é avaliado antes do Catch. Define erros transitórios, número de repetições, backoff, jitter e prazo total, sem repetir automaticamente rejeições funcionais. MaxAttempts conta retries, não inclui a tentativa inicial. No modelo original, três retries após esperas de 2, 4 e 8 segundos produzem no máximo quatro tentativas e catorze segundos de espera, excluindo execução das tarefas. States.ALL não captura States.DataLimitExceeded nem States.Runtime; a documentação atual permite tratar DataLimitExceeded explicitamente. Não extrapoles essa possibilidade para Runtime. Um timeout global do workflow não é um erro capturável por um Catch arbitrário colocado na mesma máquina. Heartbeats demonstram atividade, não sucesso, e não eliminam o limite total de execução.
Provar retomada, observabilidade e passagem a RUN
Para Standard, repetir StartExecution com nome e input idênticos numa execução ainda em curso tem um comportamento idempotente específico; mudar o input ou usar uma execução fechada não é a mesma situação. Express não oferece essa idempotência de arranque. Também não assumes histórico completo de Express apenas porque ativaste CloudWatch Logs: a entrega é best effort. Se o negócio exige evidência durável, desenha um registo adequado e reconciliação dos estados. O handover deve incluir correlação entre pedido, workflow, outbox e consumidor, procedimentos para resultado incerto e limites da compensação. O PM pede evidência de recuperação após falhas e critérios de retirada do legado. Um fluxo verde no orquestrador só é aceite quando o significado desse estado coincide com o compromisso de negócio.
retry_count = 3
interval_seconds = 2
backoff_rate = 2
waits = [interval_seconds * backoff_rate ** i for i in range(retry_count)]
maximum_attempts = 1 + retry_count
total_wait_seconds = sum(waits)
# Original deterministic model: [2, 4, 8], four attempts, 14 seconds waiting.
# Excludes task duration, jitter, caps, redrive and other retriers. Not an AWS execution.Num caso fictício, o novo fluxo marca publicação concluída quando a API aceita o job. O consumidor ainda não recebeu as posições. APS e negócio revêm o estado de conclusão, correlação e evidência antes de desligar o batch legado.
Armadilhas comuns
Confundir outbox com entrega única; saga com isolamento ACID; resposta da API com conclusão; heartbeat com sucesso; logs best effort com histórico completo.
Tópicos relacionados: Desempenho, cache e evidência
Modernização preserva significado e recuperação quando cada estado, repetição e compensação tem um contrato comprovável.
Referência: Strangler fig pattern · SAP-C02