Step Functions: orquestração de workflows
⏱ 12 min·⭐ 55 XP
Pré-requisitos (0/1)0%
- ⬜🪣 S3 features pra dev: presigned URLs, multipart e events(AWS Developer Associate (DVA-C02))
Recomendamos completar os pré-requisitos antes de seguir, mas nada te impede de continuar.
States essenciais
| State | Uso |
|---|---|
| Task | Chama um service (Lambda, DynamoDB, ECS, etc) |
| Choice | Branch condicional baseado em input |
| Parallel | Branches paralelas fixas, join no fim |
| Map | Iterate array processando em paralelo |
| Wait | Pausa N segundos ou até timestamp |
| Succeed / Fail | Termina workflow |
| Pass | Passa input pro próximo (debug, transform) |
StateTask
UsoChama um service (Lambda, DynamoDB, ECS, etc)
StateChoice
UsoBranch condicional baseado em input
StateParallel
UsoBranches paralelas fixas, join no fim
StateMap
UsoIterate array processando em paralelo
StateWait
UsoPausa N segundos ou até timestamp
StateSucceed / Fail
UsoTermina workflow
StatePass
UsoPassa input pro próximo (debug, transform)
Entrada
Iníciopedido recebido
Passos de negócio
Task · reservar estoqueRetry: 3× com backoff
Task · cobrarRetry + Catch
Task · agendar entrega
Decisão e espera
Choicevalor alto → revisão humana
Wait / Task Tokenespera aprovação, sem consumir compute
Compensação
Estornar cobrançaidempotente, com chave
Liberar estoqueidempotente
Fim
Succeed
Fail → DLQ + alertahumano precisa saber
- → reservado
- → cobrado
- → valor alto
- → valor normal
- → aprovado
- → falhou: Catch
- → falhou: Catch
- Integração de apps
- Compute
- Gestão e governança
O ganho não é "orquestrar Lambda": é tirar retry, decisão, espera e compensação do seu código e colocar numa definição visível e auditável. Lambda chamando Lambda para simular isso é o antipadrão que o DVA-C02 cobra.
- Retry por passo, não no código. Cada Task declara sua própria política: quantas tentativas, intervalo, backoff, e para quais erros. Isso sai do seu código e passa a ser configuração visível na definição do fluxo.
- Choice ramifica sem código de orquestração. A decisão vive na máquina de estados, não numa Lambda que chama outra Lambda. Fluxo legível, e mudança de regra não exige deploy de função.
- Esperar humano sem pagar compute. Com Task Token, o fluxo fica suspenso — sem Lambda rodando, sem custo — até alguém chamar a API com o token. Fazer isso com Lambda em polling é caro e frágil.
- Catch aciona a compensação. Falha no passo N dispara o desfazer dos passos 1..N−1, na ordem inversa. Não existe rollback em sistema distribuído: existe compensação explícita, e ela precisa ser desenhada.
- Compensação também falha — e precisa de destino. Estorno que não funciona deixa inconsistência permanente. DLQ mais alerta para humano é obrigatório: alguém precisa saber que três pedidos ficaram no meio do caminho.
Onde isso entra no exame
📘 Domain 1 — Development with AWS Services· 32%
A questão típica dá um requisito e pede o tipo de workflow: Standard vai até 1 ano, é exactly-once e guarda histórico auditável; Express vai até 5 minutos, é at-least-once e serve alta vazão. Saiba também que `Retry` e `Catch` vivem na state machine — colocar retentativa dentro do código da Lambda é justamente a alternativa errada.
Quiz rápido
Um fluxo de aprovação precisa esperar a decisão de um gerente, que pode levar horas ou dias. Qual abordagem?
Retries e Catch
💡
Cada Task state suporta Retry (com backoff exponencial, max attempts) e Catch (redirecionar pra state de error handling). Essencial pra workflows production: DB falhou? Retry 3x com 5/25/125s. Still fail? Vai pra fallback state que notifica Slack.
{
"ChamarServicoExterno": {
"Type": "Task",
"Resource": "arn:aws:states:::lambda:invoke",
"Parameters": { "FunctionName": "consulta-parceiro" },
"Retry": [
{
"ErrorEquals": ["States.TaskFailed", "Lambda.ServiceException"],
"IntervalSeconds": 2,
"BackoffRate": 2.0,
"MaxAttempts": 4,
"JitterStrategy": "FULL"
},
{
"ErrorEquals": ["ParceiroIndisponivel"],
"IntervalSeconds": 30,
"MaxAttempts": 2
}
],
"Catch": [
{
"ErrorEquals": ["States.ALL"],
"ResultPath": "$.erro",
"Next": "RegistrarFalhaEContinuar"
}
],
"TimeoutSeconds": 60,
"Next": "Proximo"
}
}Perguntas frequentes
❓ Fluxo padrão ou expresso?
Padrão quando a execução é longa, precisa de histórico auditável e exatamente uma execução por evento. Expresso quando o volume é alto e a execução é curta, com custo bem menor e histórico limitado. O enunciado dá a duração e o volume — os dois juntos decidem, não um só.
❓ Quando vale orquestrar em vez de chamar direto?
Quando há vários passos com nova tentativa, ramificação e estado que precisa sobreviver a falha — escrever isso à mão é reimplementar máquina de estado com pior visibilidade. Para dois passos simples, a orquestração acrescenta latência e configuração sem ganho.
❓ Como tratar erro dentro de um fluxo?
Com política de nova tentativa por tipo de erro e captura que desvia para um caminho de tratamento — não deixando a execução falhar inteira. É o que separa fluxo de produção de exemplo de tutorial, e a prova cobra reconhecer que nova tentativa e captura são configuração, não código.
Fixando
Quiz rápido
Numa máquina de estados, o passo de cobrança falhou após todos os retries. O que garante que a reserva de estoque feita antes seja desfeita?
Quiz rápido
Qual é a diferença entre Standard e Express workflow no Step Functions?
Terminou de ler?
Marcar como concluído registra o XP, mantém sua sequência e coloca 3 cartas deste módulo na fila de revisão espaçada.
Próximos passos sugeridos
Temas deste módulo
Discussão
Carregando comentários…