Database
Ch-ch-changes!
"No man ever steps in the same river twice,
for it's not the same river and he's not the same man. "
Heraclitus
- Apparently, no woman or man ever reads the same code twice either! This month we did a lot of code refactoring, not only to make it cleaner, but also to reduce the mental load required to understand the system.
- The StateMachine type used to specialize over a set of constants that defined its behavior, such as the message size and compaction interval. The idea was to test specific scenarios without modifying global constants, but in practice these scenarios were very limited, as call sites outside the StateMachine still used global constants! We forfeited this idea and simplified the StateMachine type to rely solely on global constants.
- Still within the state machine domain, we wanted to decouple clients from the StateMachine type, and for that we looked for a common interface shared by both vsr.Replica and vsr.Client. We then realized that this interface did not belong to the StateMachine, but to the state machine’s Operation! We moved all operation-specific functions to the Operation enum and refactored all client code to remove the dependency on the StateMachine type, which now is used only by replicas.
- The connection and message passing logic was previously spread across both the MessageBus and Connection types, making responsibilities less clear. We refactored it, so that all logic is contained within the MessageBus type, with Connection only maintaining connection state between two peers.
- We got rid of the awkward INVALID_SOCKET constant by simply making the IO file descriptor an optional type. In the words of Federico Masimilliano Lorenzi: “Not sure how I never noticed this before, and now it's something I can't unsee!”
- We also did some spring cleaning of the code responsible for parsing command line flags, ensuring it now handles invalid inputs idiomatically through error codes, instead of panicking on malformed inputs. Plus a fuzzer for parse_flag_value, to catch this proactively.
- We removed uses of the platform-specific usize type in favor of the more appropriate u32 or u64 integer type, enforcing the TigerStyle rule of using explicitly-sized types.
- Our asynchronous I/O abstraction now supports canceling individual in-flight operations. Previously, the I/O subsystem only allowed canceling all asynchronous in-flight operations at once.
- We simplified the Rust client's build script, making the Zig build script responsible for driving the build and CI. Previously, the Rust client attempted to build the tb_client library itself.
- We also integrated Vörtex, our non-deterministic simulator, into the CFO (Continuous Fuzzer Orchestration) infrastructure, taking advantage of our fleet of 1000 dedicated CPU cores running the simulator 24/7.
|
|
"Database television" (DTV)
Last month on IronBeetle, our query engine arc continued. We looked at how we actually execute the query, the overall flow of what we do, and then in Zig Zag Merge learned how to extract ‘all transfers’ that relate to a particular characteristic, i.e. specific datasets. Finally, we tackled rewriting the while loop (which as you might have guessed, will have multiple parts!).
Join us live every week on Twitch or catch up on the TigerTube!
|
|
Looking back
What is TigerStyle? Principles behind TigerBeetle ft. Joran (Nov 1)
We’re back! It was an honor to return to The Geek Narrator podcast with Kaivalya Apte, this time to go behind the scenes of TigerStyle, the methodology that led to TigerBeetle—including how and why it was developed, and to spend time on principles, like, “Zero Technical Debt”.
TigerFans: Building a High-Performance Ticketing System with TigerBeetle (Nov 2)
In August 2024, tickets for the Oasis reunion tour sold out rapidly, with approximately 1.4 million tickets sold over six hours… or 65 tickets per second for a high-demand ticket sale scenario. A phenomenal post on 10x ticketing performance, and how this might have been with TigerBeetle, by Rene Schallner.
On Async Mutexes (Nov 5)
A short note from matklad on a contradiction in language design beliefs.
The Write Last, Read First Rule (Nov 6)
Composing systems, each correct in isolation, does not necessarily yield a correct system. A special guest post by Dominik Tornow, Resonate Founder and CEO. How to maintain consistency in the absence of transactions, how to reason about correctness when intermediate states are externalized, and how to recover from partial failures.
|
|
|
Building a financial accounting workflow with TigerBeetle (Nov 18)
Vivek Dehariya explored how TigerBeetle fits into billing/accounting systems by taking a simple example of an accounting workflow for a SaaS in multi-tenant setup across currencies.
Mathematics of Consensus — Accidental Lecture (Nov 22)
Somewhat accidentally, we recorded an impromptu ~2 hour lecture explaining the mathematics behind consensus algorithms, using a Go Pro fisheye. Like Tobi, who accompanied matklad on the journey, undergo your own alchemical transmutation, from understanding the basics of set theory to understanding consensus.
|
|
|
TigerStyle with matklad Vol. 2 (Systems Engineering) (Nov 27)
We returned to The Geek Narrator Podcast for a second installment on TigerStyle, described by KV as “a treasure for anyone doing serious systems/infra engineering” and “one of THE fastest episodes ever released”. Speed? Well, it is matklad.
|
|
Looking ahead
TigerBeetle 1000x World Tour (Dec 1-6)
This week, we’ll see many of you on the 1000x World Tour, taking place across 13 cities, hosted by TigerBeetle’s team and friends. Join us to hear about everything from How We Built TigerBeetle Racer, The Tale of Taming TigerBeetle’s Tail and Property Based Testing You Can Love to TigerSales, How Dependencies Limit Your Options, and 1000x: The Power of an Interface for Performance. If you love the music… take it on tour!
|
|
Thank you!
‘Till next time… all the roads and all the lights.
The TigerBeetle Team
|
|
|
|
|