Skip to content

CONCEPT Cited by 1 source

Deterministic state machine for lifecycle

Definition

A deterministic state machine for lifecycle is the pattern of modelling the lifecycle of a stateful resource (a query, a request, a workflow, a connection, a session) as a finite set of states with explicit transitions triggered by enumerated events, where every (state, event) pair has a defined, deterministic next state. The alternative — letting state emerge from the composition of concurrent operations and shared variables — is typically what produces the pathology this pattern fixes: ambiguous state, stuck resources, inconsistency across components.

Canonical wiki instance: Oxla's 2026-01-27 query- manager rewrite. The old query manager had queries getting "stuck in 'finished' or 'executing' while still holding onto resources" with "different parts of the system [disagreeing] about what was actually happening" — the diagnostic symptom of an implicit state machine. The rewrite made the state machine explicit: "The new scheduler is built as a deterministic state machine. At any point, it's in a known state, handling a specific event, and transitioning predictably." (Source: sources/2026-01-27-redpanda-engineering-den-query-manager-implementation-demo).

Four load-bearing properties

From the Oxla rewrite:

  1. Known state at any point. No ambiguity — every instance of the managed resource is in exactly one state at a time, and that state is queryable.
  2. Specific event being handled. Transitions are triggered by enumerated events, not by shared-variable observation or side-effect cascades.
  3. Predictable transition. (state, event) → next_state is a total function; the same inputs always yield the same next state.
  4. Every transition logged. The state machine's trajectory through state space is observable after the fact — see concepts/state-transition-logging.

Why "deterministic" matters

The alternative — a nondeterministic or emergent state machine — produces the exact bugs Oxla named:

  • "Queries could get stuck in 'finished' or 'executing' while still holding onto resources." → terminal states are not side-effect-complete; cleanup is emergent.
  • "Different parts of the system disagreed about what was actually happening." → state is replicated across components without an authoritative source.
  • "A query might show as scheduled in one place and finished in another." → the "lifecycle" is the composition of multiple independent views, not a single state machine.

Making the machine deterministic means one authoritative state per resource + transitions are the only way to change it + transitions are driven by events, not observation.

Scope

This concept applies to any per-resource lifecycle where the resource is long-lived relative to a single RPC:

Composed pattern

See patterns/state-machine-as-query-lifecycle-manager for the query-engine specific instantiation. The generic pattern is: explicit states + enumerated events + transition function + per- transition log record + terminal-state resource teardown (see concepts/explicit-teardown-on-completion).

Contrast: the anti-pattern Oxla fixed

The old query manager's pathological cancellation shape — "To avoid deadlocks, the old code gathered running queries, spawned async work per thread, and sometimes had to retry cancellation from a different thread entirely" — is the failure mode of an implicit state machine: the cancellation operation had no enumerated state to transition from or to, so it had to reconstruct state by querying, and when that failed due to locking concerns, had to spawn concurrency to escape. A deterministic state machine dispatches cancellation as a single event that takes any state to the Cancelled terminal, no reconstruction needed. See concepts/async-cancellation-thread-spawn-antipattern.

Seen in

Last updated · 470 distilled / 1,213 read