Summary
Disclaimer: This summary has been generated by AI. It is experimental, and feedback is welcomed. Please reach out to info@qconlondon.com with any comments or concerns.
Deterministic Simulation Testing (DST) is a method used to find bugs by exploring random execution paths and injecting failures. This helps in replaying failures and detecting hard-to-find bugs before they reach production, thereby enhancing developer confidence.
Key Points:
- History of Bugs: The speaker discusses past challenges with unreproducible bugs in distributed systems, highlighting the difficulty in reproducing such issues.
- Go and Rust Approaches: Two different implementations of DST were explored: one using WASM in Go and another using state machines in Rust. While Go used the concurrency model directly in testing, the Rust approach involved rearchitecting code using state machines.
- Challenges with Go: Modifying Go's runtime for deterministic testing posed maintenance challenges, eventually leading to discontinuation of DST due to high efforts and maintenance burden.
- State Machines in Rust: Utilized state machines to achieve deterministic execution and failure injection. This approach facilitated detailed control over system execution, making it easier to simulate and test failures.
- Comparison of Approaches: Deterministic runtime offers low effort in adopting DST but limits comprehensive coverage. State machines, although requiring significant initial effort, provide deeper control and extensive failure simulation.
Conclusion: DST is a powerful tool for preemptively eliminating production bugs, enabling better codebase exploration and consistent testing.
Resources for Further Learning: The presentation includes references to additional blog posts, talks, and resources related to DST.
This is the end of the AI-generated content.
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:
What is your session about, and why is it important for senior software developers?
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.
Why is it critical for software leaders to focus on this topic right now, as we head into 2026?
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.
What are the common challenges developers and architects face in this area?
Running a system under test deterministically requires careful thought and varies by language/platform. My talk explores various approaches we tried at Polar Signals.
What's one thing you hope attendees will implement immediately after your talk?
I hope attendees take a stab at implementing DST in their systems, even if it's just for a small component to start with.
What makes QCon stand out as a conference for senior software professionals?
It's a conference for doers.
Speaker
Alfonso Subiotto
Software Engineer @Polar Signals
Alfonso is a software engineer with a deep focus on distributed systems and databases. After honing his skills on the SQL execution team at Cockroach Labs, he now contributes to the storage layer at Polar Signals, a continuous profiling solution. Alfonso’s current area of focus is ensuring correctness through deterministic simulation testing.