mhtirogla
Home
Systems
API
Pricing
About
Log in
← Back
Home
›
Systems
›
Databases and storage engines
ledger-db
append-only financial ledger database
TigerBeetle
System
Techniques · 8
Primitives · 32
ledger-db
Deterministic simulation testing
distributed · medium: Run the whole system in one thread under a seeded scheduler with simulated network, disk and clock, so every failure replays from its seed.
›
Viewstamped replication
distributed · medium: VSR: primary-backup consensus with view changes and recovery
Authorization holds
finance · medium: Pending vs posted balances: auth holds, incremental auths, partial captures and hold expiry
Tamper-evident audit log
security · medium: An append-only log whose Merkle root, signed per batch, lets anyone verify an entry is present and history was never rewritten, with log-size proofs.
›
LSM-tree
storage · medium: Buffer writes in memory, flush them as immutable sorted files and merge in the background; turns random writes into sequential I/O.
›
Fault injection
distributed · medium: Inject latency, errors, kills and partitions via proxies, netem or hooks
State-machine snapshots
distributed · medium: Periodically save the state a log has produced at index i so the log prefix can be deleted; recovery and catch-up become load snapshot plus replay suffix.
›
Write-ahead log
storage · low: Append each change to a checksummed sequential log and fsync it before touching data pages; the basis of crash durability in nearly every database.
›
Double-entry ledger
finance · low: Append-only journal of transactions whose postings sum to zero per currency; balances are derived, so money can only move, never appear or vanish.
›
Idempotency keys
finance · low: Client-chosen unique key per logical operation, stored with a request fingerprint and the final response, so retries replay the first result instead of acting twice.
›
Money representation
finance · low: Store money as integer minor units with an explicit currency exponent, compute in wider integers, and round once with a named rounding mode.
›
CRC32C checksums
hardware-os · low: The Castagnoli CRC-32 with dedicated instructions on x86 (SSE4.2) and ARMv8. It is the standard fast integrity check for storage blocks, logs and network frames.
›
fsync, O_DSYNC and O_DIRECT
hardware-os · low: What fsync, fdatasync, O_DSYNC, O_DIRECT and F_FULLFSYNC really guarantee on Linux and macOS, and the exact call sequences for crash-safe files.
›
io_uring
networking · low: Linux async I/O through two shared-memory rings (submissions in, completions out), batching or eliminating syscalls for sockets and files alike.
›
Zero-copy serialization
networking · low: Wire formats laid out like in-memory structs (FlatBuffers, Cap'n Proto, SBE, rkyv) so readers access fields in place with no decode pass or allocation.
›
Group commit
storage · low: Let concurrent committers share one log write and fsync; throughput grows with concurrency while each commit still waits at most about two fsyncs.
›
Arena allocator
systems · low: Allocate by bumping a pointer through big chunks and free everything at once: a few instructions per allocation for objects sharing a lifetime.
›
Cooperative scheduling
concurrency · low: Green threads/coroutines yielding at await points on a user-space scheduler
Record replay
distributed · low: Record every nondeterministic input (time, randomness, I/O, model and tool outputs, per-tick player input) and re-execute deterministically for debugging, replays and state rebuild
PRNGs (PCG, xoshiro)
numerics · low: Small, fast, statistically strong non-cryptographic generators: PCG32 and xoshiro256**, with seeding, parallel streams and unbiased ranges.
›
Leases
distributed · low: A lock that expires on its own: bounded-time ownership that survives crashes and partitions, given bounded clock drift and fencing tokens on writes.
›
Iso 8583 messages
finance · low: ISO 8583 card messages: MTIs, bitmaps, data elements and their encodings
Cron scheduling
systems · low: Cron expression parsing and next-fire-time computation, with catch-up and time-zone rules
+ 1 more techniques
+ 16 more primitives
System
Techniques · 8
Primitives · 32
ledger-db
Deterministic simulation testing
distributed · medium: Run the whole system in one thread under a seeded scheduler with simulated network, disk and clock, so every failure replays from its seed.
›
Viewstamped replication
distributed · medium: VSR: primary-backup consensus with view changes and recovery
Authorization holds
finance · medium: Pending vs posted balances: auth holds, incremental auths, partial captures and hold expiry
Tamper-evident audit log
security · medium: An append-only log whose Merkle root, signed per batch, lets anyone verify an entry is present and history was never rewritten, with log-size proofs.
›
LSM-tree
storage · medium: Buffer writes in memory, flush them as immutable sorted files and merge in the background; turns random writes into sequential I/O.
›
Fault injection
distributed · medium: Inject latency, errors, kills and partitions via proxies, netem or hooks
State-machine snapshots
distributed · medium: Periodically save the state a log has produced at index i so the log prefix can be deleted; recovery and catch-up become load snapshot plus replay suffix.
›
Syscall interception
security · medium: Intercept syscalls via ptrace, seccomp user notify or a user-space kernel
Write-ahead log
storage · low: Append each change to a checksummed sequential log and fsync it before touching data pages; the basis of crash durability in nearly every database.
›
Double-entry ledger
finance · low: Append-only journal of transactions whose postings sum to zero per currency; balances are derived, so money can only move, never appear or vanish.
›
Idempotency keys
finance · low: Client-chosen unique key per logical operation, stored with a request fingerprint and the final response, so retries replay the first result instead of acting twice.
›
Money representation
finance · low: Store money as integer minor units with an explicit currency exponent, compute in wider integers, and round once with a named rounding mode.
›
CRC32C checksums
hardware-os · low: The Castagnoli CRC-32 with dedicated instructions on x86 (SSE4.2) and ARMv8. It is the standard fast integrity check for storage blocks, logs and network frames.
›
fsync, O_DSYNC and O_DIRECT
hardware-os · low: What fsync, fdatasync, O_DSYNC, O_DIRECT and F_FULLFSYNC really guarantee on Linux and macOS, and the exact call sequences for crash-safe files.
›
io_uring
networking · low: Linux async I/O through two shared-memory rings (submissions in, completions out), batching or eliminating syscalls for sockets and files alike.
›
Zero-copy serialization
networking · low: Wire formats laid out like in-memory structs (FlatBuffers, Cap'n Proto, SBE, rkyv) so readers access fields in place with no decode pass or allocation.
›
Group commit
storage · low: Let concurrent committers share one log write and fsync; throughput grows with concurrency while each commit still waits at most about two fsyncs.
›
Arena allocator
systems · low: Allocate by bumping a pointer through big chunks and free everything at once: a few instructions per allocation for objects sharing a lifetime.
›
Cooperative scheduling
concurrency · low: Green threads/coroutines yielding at await points on a user-space scheduler
Record replay
distributed · low: Record every nondeterministic input (time, randomness, I/O, model and tool outputs, per-tick player input) and re-execute deterministically for debugging, replays and state rebuild
PRNGs (PCG, xoshiro)
numerics · low: Small, fast, statistically strong non-cryptographic generators: PCG32 and xoshiro256**, with seeding, parallel streams and unbiased ranges.
›
Leases
distributed · low: A lock that expires on its own: bounded-time ownership that survives crashes and partitions, given bounded clock drift and fencing tokens on writes.
›
Iso 8583 messages
finance · low: ISO 8583 card messages: MTIs, bitmaps, data elements and their encodings
Cron scheduling
systems · low: Cron expression parsing and next-fire-time computation, with catch-up and time-zone rules
Merkle tree
data-structures · low: Hash tree for verifying and diffing large datasets with logarithmic proofs
Segmented log
distributed · low: Split an append-only log into files named by their first offset, write only the newest, and find any record by binary search plus a sparse index.
›
Digital signatures (Ed25519)
security · low: Small, fast, deterministic public-key signatures that prove who produced a message; the default for tokens, releases and protocols.
›
Trusted timestamping
security · low: RFC 3161 time-stamp tokens: a TSA signs a hash with time, proving data existed then
Transparent interception
networking · low: Redirect traffic to a local proxy (iptables TPROXY/REDIRECT, eBPF) without app changes
Copy-on-write fork
hardware-os · low: fork() gives the child the parent's whole address space by sharing pages read-only and copying one only when someone writes it; vfork and posix_spawn skip even that.
›
Copy on write snapshots
storage · low: Point-in-time snapshots by sharing pages/extents and copying only on write
Ebpf
hardware-os · low: Verified in-kernel programs on hooks (kprobes, XDP, tc) with maps
Ptrace process control
hardware-os · low: Ptrace: attach, read and write registers and memory, single-step, intercept signals
Seccomp bpf
security · low: Syscall filtering with seccomp BPF programs
Futex-based mutex
concurrency · low: A mutex that is one atomic word in user space and enters the kernel (futex wait/wake) only under contention; how std and glibc locks work.
›
Fencing tokens
distributed · low: A number that grows with every lock grant and is checked by the protected resource, so a paused ex-holder's late write is rejected.
›
Largest remainder rounding
finance · low: Splitting an amount into parts that sum exactly (largest remainder / Hamilton) for allocations, splits and prorations
SIMD programming
hardware-os · low: Process 4-16 lanes per instruction with AVX2, AVX-512 or NEON via Rust std::arch, with runtime dispatch and a portable fallback.
›
Cryptographic hashes (SHA-2, BLAKE3)
security · low: Collision-resistant fingerprints of data; SHA-256 for interoperability, BLAKE3 for speed, HMAC/HKDF for keyed uses.
›
Exponential backoff with jitter
systems · low: Retry after delays that grow geometrically and are randomized, so failed clients spread out instead of hammering a recovering service in synchronized waves.
›
Copy for AI
Similar systems
Share the most building blocks with this one.
event-store
29 %
audit-log
23 %
core-banking
21 %
securities-settlement
21 %
clearing
19 %