Airbnb abre o código do Skipper, seu workflow engine embarcado

O Skipper tem duas abstrações centrais. O workflow descreve a orquestração: decisões, ordem e esperas. As actions executam o trabalho com efeitos colaterais, como chamar uma API ou gravar no banco. O resultado de cada action é registrado para ser reaproveitado na recuperação.

Quando um workflow interrompido é retomado, o método é reexecutado desde o início, e as actions com checkpoint persistido devolvem o resultado salvo. Por isso o código do workflow precisa ser determinístico: leitura de relógio, aleatoriedade e I/O ficam nas actions. Por padrão, os checkpoints são agrupados até a execução terminar ou pausar. Isso reduz escritas, mas uma queda antes da persistência pode repetir várias actions já concluídas. Mesmo com checkpoint imediato, o efeito externo e o checkpoint não são atômicos, então os efeitos colaterais seguem como pelo menos uma vez e cada action precisa ser idempotente. A release inclui o engine, adaptadores MySQL e SQLite, utilitários de teste, a UI de administração e o Skipper State Machine, um DSL Kotlin. Postgres e DynamoDB aparecem como possíveis plugins futuros.

Em 30 de abril de 2026, o CEVIU noticiou "Construindo o engine de workflow embarcado do Airbnb", sobre o Skipper como engine leve para processos de longa duração, sem depender de ferramentas externas de orquestração. Naquele momento era a história de como foi construído. Agora, em 12 de novembro de 2026, o projeto virou open source sob Apache 2.0, com código, documentação e exemplos públicos.

Para quem opera serviços Java ou Kotlin com processos de várias etapas, o Skipper oferece durabilidade sem subir um cluster de orquestração. Em troca, a equipe assume a capacidade do banco, a execução e a recuperação. É uma escolha de arquitetura, e a leitura aqui é que ela serve melhor a times com operação madura.