Deterministic recovery: designing execution that never loses its place.

The failure mode

A bridge process dies mid-order. It happens. Memory pressure, a bad deploy, a network partition between the bridge and the LP gateway, an OS-level restart nobody scheduled.

The question is what happens next.

Classic bridge architectures answer with guesswork. On restart, the process queries whatever state it can find — open positions from the platform, last known fills from a log file, maybe a stale cache — and tries to reconstruct where things stood. It's an inference, not a fact.

If the guess is wrong, the desk eats the difference. A position that should have been flat isn't. A fill that should have been forwarded to the LP wasn't. Someone reconciles by hand at 2am and calls it operational risk, because that's what it is.

This isn't a rare edge case. It's the default behavior of any system that treats "current state" as something you recompute from scratch after a crash, rather than something you know.

The design answer

The fix isn't a better recovery script. It's not treating recovery as a special case at all.

Every order in the system moves through a defined lifecycle: received, validated, routed, acknowledged, filled, rejected, closed. Each transition is a discrete event. The design principle is simple to state and hard to skip on: the event is written to a durable journal before it is acted on.

Not after. Before.

That ordering is the whole point. If the write happens first, then "the process crashed after writing but before acting" is a recoverable, well-defined state — replay the journal and finish the action. There is no state where an action happened but was never recorded, because nothing acts without first being recorded.

Recovery, then, isn't reconstruction. It's replay. Feed the journal back through the same state machine that produced it, and you get the same output. Same inputs, same outcome, every time. That's determinism, and it's the property that makes "recovery" a boring word instead of a stressful one.

event: ORDER_RECEIVED  -> journaled -> processed
event: ORDER_ROUTED    -> journaled -> processed
event: FILL_CONFIRMED  -> journaled -> processed
[process dies here]
[restart: replay journal from last checkpoint]
-> exact same order state, no guessing

What it means operationally

A restart stops being an incident. It's a resumed replay, indistinguishable in outcome from the process never having stopped. There's no "let's reconcile positions before we open the desk" ritual, because positions were never in question.

Audits get cheaper in the way that matters: they stop being archaeology. "What happened to order X at 14:03:07" is a query against the journal, not a request to reconstruct a timeline from four different log formats and someone's memory. The journal is the timeline. It was written in the order things actually happened, and it doesn't need to be interpreted.

This also changes what failover looks like. In-flight orders aren't a special category requiring a manual sweep — they're just events partway through the lifecycle, and the replay mechanism handles them the same way it handles everything else.

What to ask your current vendor

A few questions expose whether a bridge actually works this way or just claims to:

Can you replay yesterday's order flow from a specific timestamp and get an identical result? If the answer involves caveats about log completeness or "it depends what was cached," the journal isn't authoritative.

What happens to in-flight orders on failover? If the answer describes a reconciliation step, a manual review queue, or a "we compare platform state to LP state and flag mismatches" process, that's guesswork with a UI on it.

Is the state transition written before or after the action executes? This is the question that matters most and gets answered least directly. If nobody can answer it precisely, assume the worse case.

None of this requires exotic technology. It requires deciding, at the architecture level, that guessing is not an acceptable substitute for knowing — and building the journal first, not bolting it on after the first bad night.