Tackle the hardest software problem. Ship it 5 ears quicker, and do it to tighter tolerances. Go slow to go fast later
assertions
- Your functions are contributing to correctness
- preconditions and postconditions
- ”separate control data plane”
- Every function should be checking as stuff comes in
- Encoding your expectations into your code
- program becomes self verifying
- combine assertions with running simulation
Systems programming
- If it compiles, it is just the beginning
- Hackers think differently, come up with what you don’t expect
- distributed systems are similar to hackers
limits
- Everything has a limit
- Resources have limits
- You might as well makes those limits explicit
- handling overload, handle back pressure
don’t let assertions be misunderstood
- assertions are not about convenience, but about correctness
- assertions should not be disabled on production
- assertions are there to catch bad code
- the cost to not shutting down is greater
time machine
- tiger beetle simulates harsh environments, crashing disks, crashing multiple node disks at the same time
- Replay bugs from seed
financial systems
- 1 financial transactions is 10 transactions
- everyone is running single core, vertical scaling
architecture
- replicated state machine
- machine with state that you replicate
tiger beetle
- 630kb fully distributed database
- written in zig
- runs on rpi’s with sd
how
- decouple performance
- zero copy, direct op to dma to disk
- zero deserialization
- io_uring
- no GC spikes
storage fault model
- make database self healing
- vsr consensus engine
- WAL shared by both
- Multi region
resources
- conference talk tiger beetle tiger style https://youtu.be/w3WYdYyjek4?si=YeUg8d3bX_RUfwiw
- fastest and safest database https://youtu.be/sC1B3d9C_sI?si=0fVyhEOrcp7BAFU8
- NASA’s rules safety for critical code https://en.m.wikipedia.org/wiki/The_Power_of_10:_Rules_for_Developing_Safety-Critical_Code