Case study · 03/2022 — 05/2022
WakeFlow
WakeFlow was a focused experiment in workflow automation: define a sequence of steps, hang triggers off them, and let the system run the rest. The interesting part was not the visual editor but the scheduler underneath, the thing that actually has to fire jobs at the right time, in the right order, and survive a process restart without dropping work on the floor.
Problem
Workflow engines look simple from the outside: "do A, then B, then C", and become unpleasant the moment you ask the obvious questions. What happens if step B is in flight when the worker dies? What happens if the schedule for step C drifts? What happens if two replicas pick up the same trigger? The project was an excuse to confront those questions head-on instead of papering over them with a queueing service and crossed fingers.
Approach
Workflow runs were modelled as durable state machines with each step writing its outcome before signalling the next. Triggers were treated as first-class records rather than ephemeral messages so a restart could replay them deterministically. The scheduler used a leasing model to make sure two replicas could not advance the same run, and idempotency was required at every step boundary. Event-driven triggers and time-based triggers shared the same code path, which kept the surface area small.
Outcome
WakeFlow ended up being more useful as a study than as a product. The mental model durable state machine, leased advancement, idempotent steps has carried into the way I approach any long-running orchestration since, including ETL pipelines and the scheduler primitives behind the bigger systems I have shipped after it.