We are forgetting how to write good software
This title could be clearer and more informative.Try out Clickbait Shieldfor free (5 uses left this month).
An overview of Tiger Style, the coding philosophy behind TigerBeetle, the financial transactions database, exploring its priority order of safety, performance, then developer experience. Covers explicit limits on queues and buffers, fixed integer widths over architecture-dependent types like usize, avoiding dynamic allocation after startup, heavy use of assertions, batching, cache-conscious data layout, single-threaded transaction processing to avoid contention, minimizing data copying in hot paths, converting non-deterministic inputs (like time) into deterministic ones, and a zero technical debt policy. The piece frames these low-level engineering disciplines as a contrast to the current 'vibe coding' and agentic development trend.
•8m watch time
Questions this post answers
What is Tiger Style in TigerBeetle and what are its core priorities?
Tiger Style is the coding philosophy behind the TigerBeetle financial transactions database, prioritizing safety first, then performance, then developer experience, in that specific order. It emphasizes explicit limits on queues and buffers, fixed integer widths like u32 over architecture-dependent types like usize, no dynamic memory allocation after startup, and at least two assertions per function to encode invariants. Explore daily.dev for more deep dives into disciplined system design philosophies like this one.
Why does TigerBeetle process transactions on a single thread instead of using multiple threads?
TigerBeetle runs its transaction state machine single-threaded because financial workloads have heavy contention, with many transactions touching the same popular accounts requiring a defined processing order. Adding more threads would introduce synchronization, locking, and extra cache traffic without necessarily speeding up this part of the system, while concurrent operations like disk access and replication are still handled separately. Compare concurrency trade-offs like this one on daily.dev when weighing database architecture choices.
Why does TigerBeetle avoid dynamic memory allocation after initialization?
TigerBeetle calculates all memory it needs based on configured limits and allocates it once during startup, before entering the main event loop, so transaction processing never repeatedly allocates or frees heap objects. This avoids allocator latency and both external and internal memory fragmentation, keeping memory usage predictable during long-running operation. Follow daily.dev for practical patterns on memory predictability in performance-critical systems.
545.1K Impressions17 Comments