Deterministic systems: Why and how-to?
summary
Advocates a concrete one-writer state machine pattern: record every input to a durable journal, apply events to a single-threaded core, take periodic snapshots, and keep a replica for non‑blocking snapshotting and failover. Uses a ring buffer (Disruptor) for ordered delivery, verifies determinism via replay tests and JCStress, and measures with JMH; production numbers include ~100,000 orders/sec and ~80 µs edge roundtrips. Warns about non‑reproducible calls (DB, time, random), journaling I/O bottlenecks, and suggests CPU pinning and sharding.
AI-written summary · about
chapters (17)
- 0:00Introduction to talk
- 1:15Context of our work
- 3:02Why deterministic systems
- 5:55Benefits of determinism
- 8:00Non-determinism in systems
- 9:45Single-threaded state updates
- 12:12Journaling and snapshots
- 16:27Handling software updates
- 17:30Testing determinism
- 18:13Common pitfalls
- 20:43Concurrency is hard
- 23:15Single thread vs multiple threads
- 25:25Blocking calls and I/O
- 27:55Thread isolation and CPU pinning
- 30:01Why single-thread updates are better
- 31:26Summary of benefits
- 32:52Q&A session
related talks
46mDeterminedly deterministic and how it can help you
13mInsights on determinism
59mThe Mess We're (Still) In
27mLet's Bring System Dynamics Back to CS!
21mDDD and FSM: tackling complexity with state machines
19mHow to Fail Your Event-Driven System
46mState Machines (The Good, The Bad and The Ugly)
15mHow Deterministic Game Engines will Disrupt Multiplayer Game Development