Abstract
Deterministic simulation testing finds bugs by exploring random execution paths, injecting failures, and letting you replay any failure with a single starting seed. This testing approach shakes out many difficult to find bugs before they reach production and greatly increases developer confidence in system correctness when making new changes.
This talk will take you on our DST journey at Polar Signals: how we implemented DST in our Go database using a WASM runtime, and why we chose a different approach when rewriting our database in Rust.
You'll walk away with:
- A framework for thinking about software determinism
- An overview of two practical DST approaches and their tradeoffs
- Ideas for implementing DST in your system
Interview
My session is about how we implemented deterministic simulation testing at Polar Signals. DST is a system testing method that verifies correctness by running a workload under simulation, injecting random failures, and enabling deterministic reproducibility of any failure. It has been instrumental in catching edge cases before reaching production and drastically reduces debug & fix cycles so we can build faster while maintaining confidence in system correctness.
As coding agents become more widely adopted and the rate of new code merged increases at a staggering rate, it is more important than ever to invest in end-to-end system-level property testing with deterministic verification of fixes.
Running a system under test deterministically requires careful thought and varies by language/platform. My talk explores various approaches we tried at Polar Signals.
I hope attendees take a stab at implementing DST in their systems, even if it's just for a small component to start with.
It's a conference for doers.
Topics
QCon London 2026 is a three day conference for senior software engineers, architects and team leads. An international program committee of working engineers selects every session. Patterns and practices, not products and pitches.
Part of the track
Native Languages - and Wasm Hosted by Werner Schuster Kernel Developer @Wolfram, InfoQ Editor Functional ProgrammingFrom the same track
Monday 16 March
10:35 Windsor (5th Fl.) Session Deterministic Simulation Testing A Deterministic Simulation Testing (DST) Journey: From WASM in Go to State Machines in Rust Alfonso Subiotto Software Engineer @Polar Signals Deterministic simulation testing finds bugs by exploring random execution paths, injecting failures, and letting you replay any failure with a single starting seed. 11:45 Rutherford (4th Fl.) Unconference Unconference: Native Languages 14:45 Windsor (5th Fl.) Session Use<’lifetimes> For<’what> Ethan Brierley Senior Engineer @TrueLayer and Co-Organiser of Rust London As Rust has become more ergonomic, lifetimes have become more nuanced. By thinking of lifetimes as sets of loans, rather than using the traditional "regions of code" definition, this talk explores advanced lifetime concepts such as variance and higher ranked lifetimes. 15:55 Windsor (5th Fl.) Session Platform Engineering Fixing the AI Infra Scale Problem by Stuffing 1M Sandboxes in a Single Server Felipe Huici CEO and Co-Founder @Unikraft, Founder and Maintainer of the Linux Foundation Unikraft Open Source Project The past year has seen an absolute explosion in the use of AI and agents in particular, a trend that is guaranteed to accelerate going forward. 17:05 Windsor (5th Fl.) Session performance Understanding and Tuning System Performance with CPU Hardware Counters Bryan Boreham Distinguished Engineer @Grafana Labs, Member of the Prometheus Team, Expert in Distributed Systems and Computer Performance Counters are fundamental to monitoring: how many requests were processed, how many CPU-seconds consumed, how many bytes sent over a network. Very likely you are already monitoring your applications and operating systems via the hundreds or thousands of counters they expose.