fivenines
10/39
Lesson 1.7

Determinism: the event log is the exchange

What you'll learn

The sequenced event log — the single idea that gives you recovery, audit, replication, and regulation-grade history all at once.

Building on

1.3 established that the engine is a single-threaded function of its input order. This lesson cashes that in. This is the most important lesson in the course — Parts 2 and 3 are elaborations of this diagram.

Because matching is deterministic, the engine's entire state is a pure function of one thing: the sequence of inputs it has consumed. Same inputs, same order → same books, same fills, byte for byte. So we make that sequence a first-class object:

flowchart LR
    IN["All inputs: orders, cancels, phase timers, admin actions"] --> SEQ["SEQUENCER stamps a global sequence number: 1, 2, 3, ..."]
    SEQ --> J[("Append-only journal — durable before processing")]
    SEQ --> ME["Matching engine consumes events strictly in order"]
    ME --> OUT["Outputs: acks, fills, market data, trade feed"]
    ME -- "every N minutes" --> SNAP[("Snapshot: full state + last seq applied")]
    J -. "crash recovery: replay from snapshot's seq" .-> ME
    
The sequenced-log architecture. The journal, not the engine's RAM, is the authoritative exchange. The engine is a deterministic view of the log — a cache of its consequences.

Everything that touches the core goes through the sequencer — even the clock. "It is now 16:00, run the closing auction" enters as event N like any order, because if the engine read wall-clock time directly, replaying the log later would produce different results. Determinism means no hidden inputs: no local time, no random numbers, no iteration over unordered structures.

Worked example — recovery by replay

The engine crashes having processed event 4,000,000. Recovery is mechanical:

  1. Restart. Load the latest snapshot — say it captured state as of event 3,950,000.
  2. Replay journal events 3,950,001 → 4,000,000 through the same matching logic. Replay is compute-only (no network waits), so it runs orders of magnitude faster than real time.
  3. State is now bit-identical to the moment before the crash — every resting order, every partial fill, every phase. Resume consuming new events at 4,000,001.

Not "approximately restored from backups." Identical, provably, because state ≡ f(log).

One log, four products: recovery (above), audit (regulators can replay to any nanosecond — the journal is the legally authoritative record), testing (replay yesterday's real traffic against tomorrow's code and diff the outputs), and — the seed of Part 2 — replication: feed the same log to a second engine and you get a second, perfectly synchronized copy for free.

Key ideas
  • State = f(sequenced log). The log is authoritative; the engine is a view.
  • All inputs — including time — enter through the sequencer.
  • One mechanism yields recovery, audit, testing, and (later) replication.
Next step

See what actually stuck.

Take the practice scenarios now.