Patterns§
Working shapes for real processes — each pattern is a topology + handlers you can copy, with the reasoning for why the shape looks the way it does. All of them run against an embedded server in one JVM, so every pattern is testable before it's deployed.
⑂ Parallel fork / joinRun independent branches concurrently on isolated state; rejoin through an explicit, hand-written combine. The foundation everything else builds on.
✋ Human-in-the-loop approvalPark the instance on a signal — no worker held — with a deadline that escalates when nobody acts, and a branch on which of the two happened.
⇶ Dynamic fan-outOne isolated branch per element of a runtime collection; results collected in input shape and folded by an explicit combine.
↻ Retries & failure isolationExponential backoff per step, gates for business-level "stop cleanly", and poll-until-ready loops for external dependencies.
⏰ Cron & scheduled workServer-side cron and interval schedules with exactly-once firing across leader failover — no external scheduler.
🧵 One flow, many servicesRoute each step to a queue; separate services (in separate languages) each serve only their steps of the same durable instance.
🧫 Per-tenant isolationGive a tenant its own cell — database and cluster — behind one coordinator, with zero-migration resharding when load grows.
How to read a pattern§
Every page follows the same skeleton:
- The problem — when you reach for this shape.
- The topology — the graph, in the DSL.
- The handlers — plain methods matched by name; the signature picks the step kind.
- Why this shape — the design reasoning, including what Wiggle deliberately makes explicit.
The DSL cookbook is the operator-by-operator companion: eight runnable
workflows exercising everything on these pages (./gradlew :example:runCookbook).