Jepsen: TigerBeetle 0.16.11

• TigerBeetle adalah database OLTP yang dioptimalkan untuk pembukuan double-entry, dikembangkan dengan tujuan keamanan dan kecepatan pemrosesan
• Mendukung protokol konsensus Viewstamped Replication dan standar strong serializability, dengan arsitektur yang dioptimalkan untuk beban kerja berkonflik tinggi dan throughput tinggi
• Memiliki desain dan prosedur pengujian yang sangat menekankan toleransi kesalahan serta ketahanan pemulihan, dengan sasaran beroperasi tanpa kehilangan data di berbagai situasi kegagalan
• Jepsen menemukan berbagai bug dan isu performa pada upgrade, pengujian, model operasi, dan ketahanan pemulihan klaster, lalu meningkatkan kemungkinan penanganannya
• Pada versi terbaru tersedia berbagai peningkatan dan perbaikan bug pada performa replikasi berbasis ring, penanganan error klien, akurasi logging dan kueri, dll.

---

Pengenalan TigerBeetle

• TigerBeetle adalah database pemrosesan transaksi online (OLTP) yang dikhususkan untuk pembukuan double-entry
• Menjamin strong serializability berbasis protokol konsensus Viewstamped Replication (VR), dan hanya menyimpan data akun serta transfer antar akun
• Cocok untuk lingkungan dengan volume transaksi tinggi dan persaingan konkurensi yang ketat seperti switch internal perbankan, broker, penerbitan tiket, dan pengukuran listrik
• Memakai arsitektur di mana semua operasi tulis ditangani oleh satu node (Core), sehingga berfokus pada scale-up vertikal, bukan scale-out horizontal
• Menargetkan throughput node tunggal semaksimal mungkin lewat optimasi yang ramah hardware seperti pemrosesan batch, paralelisasi IO, dan skema tetap

Ketahanan pemulihan dan toleransi kesalahan

• TigerBeetle menyediakan model eksplisit serta prosedur pemulihan untuk kegagalan memori, proses, jam, penyimpanan, dan jaringan
• Daya tahan data menjamin tidak ada kehilangan data bahkan jika hanya satu replika yang masih hidup
  • Jika catatan rusak di semua replika, sistem akan berhenti dengan aman
• Mengasumsikan beragam gangguan seperti kerusakan hardware/software sistem, galat jam, korupsi disk, serta latensi, kehilangan, dan duplikasi jaringan
• Menerapkan Viewstamped Replication, teknik Protocol-Aware Recovery, checksum blok data, dan penyimpanan multi-replika
• Memanfaatkan verifikasi runtime (assertion) untuk meminimalkan dampak saat terjadi error atau bug

Metode upgrade

• Binary mencakup kode untuk versi saat ini dan beberapa versi sebelumnya
• Upgrade dapat dilakukan cukup dengan mengganti binary
• Semua node dalam klaster otomatis berganti versi secara rolling, sehingga intervensi pengguna diminimalkan
• Dengan mencegah operasi yang sudah commit di versi tertentu ter-commit ulang di versi lain, pendekatan ini membantu mencegah inkonsistensi status

Model waktu

• Menggunakan jam logis berbasis VR view dan nomor operasi, sekaligus jam fisik hibrida (physical time)
• Leader mengumpulkan waktu POSIX dari semua replika dan menyinkronkan klaster dalam batas toleransi galat
• Jika sinkronisasi jam gagal lebih dari 60 detik, layanan akan ditolak
• Timestamp memakai satuan "nanodetik sejak Unix epoch", tetapi dapat memiliki selisih 27 detik dari waktu POSIX aktual
• Saat leap second atau penyesuaian waktu negatif terjadi, jam internal dapat melambat

Model data

• Hanya mendukung dua tipe data: akun (account) dan transfer
  • Setiap field berukuran tetap, mengikuti prinsip immutable, dan dirancang berbasis unsigned int
• Akun didefinisikan oleh id 128-bit buatan pengguna, ledger, flag, waktu pembuatan, dan field kustom
• Transfer mencakup debit/credit account id, code, amount, dan field kustom
• Transfer mendukung eksekusi langsung (satu tahap) maupun dua tahap (negosiasi reservasi dan eksekusi)
  • Transfer reservasi (pending) dapat dibatalkan atau kedaluwarsa
  • Transfer khusus dapat dipakai untuk menutup atau membuka kembali akun

Model operasi dan transaksi

• Klien bekerja dalam satuan satu request (batch) untuk memperbarui atau membaca status data
• Setiap event di dalam request diproses secara berurutan sebagai transaksi atomik (atomic)
• Tidak mendukung eksekusi berulang, transaksi multi-request, atau kueri interaktif
• Menyediakan Strong Serializability dan konsistensi sesi yang kuat
• Mendukung keberhasilan/kegagalan tiap operasi, pengembalian kode error, dan pemrosesan gabungan lewat fitur chain (subtransaksi)

Desain pengujian Jepsen

• Melakukan pengujian berbasis properti (property-based) dan fault injection melalui library Jepsen
• Eksperimen dijalankan pada klaster 3–6 node di berbagai lingkungan seperti LXC dan EC2
• Karena batasan model data membuat verifikasi konsistensi berbentuk list atau set sulit diterapkan, digunakan urutan total operasi (total order) untuk memeriksa konsistensi status dan waktu
• Error dideteksi lewat pendekatan yang saling melengkapi seperti pemeriksaan konsistensi berbasis timestamp, verifikasi model, dan simulasi

Verifikasi model dan pembuatan operasi

• Ketepatan perilaku TigerBeetle diperiksa secara rinci dengan model mesin status single-thread berukuran lebih dari 1600 baris
• Menangani penalaran dan rollback untuk berbagai kondisi error seperti id duplikat, timestamp tak berurutan, batasan saldo, dan linked chain
• Untuk efisiensi verifikasi, digunakan berbagai pendekatan seperti pembuatan operation dan id, pembaruan status, serta kombinasi kueri berbasis probabilitas

Fault injection

• Mencakup skenario kegagalan dasar seperti crash proses (SIGKILL), pause (SIGSTOP), partisi jaringan, dan perubahan clock
• Juga menyuntikkan gangguan penyimpanan yang lebih rinci seperti upgrade versi, simulasi korupsi file, dan korupsi parsial hanya pada sebagian replika
• Berbagai skenario seperti korupsi disk zigzag (helical) dipakai untuk memverifikasi minimisasi kemungkinan kehilangan data

Contoh bug utama dan riwayat perbaikan

Masalah pada penanganan timeout request (#206)

• Dalam desain TigerBeetle, request klien tidak pernah timeout; sistem akan retry tanpa batas sampai menerima respons dari klaster
• Dalam praktiknya, klien seperti Java bisa melempar exception timeout saat operasi asinkron, dan aplikasi sering kali terpaksa menetapkan timeout eksternal
• Desain ini secara ambigu menyembunyikan error jaringan atau error pasti, sehingga sulit membedakan kegagalan yang pasti dari error yang tidak pasti
• Jepsen merekomendasikan penambahan metode pengembalian berdasarkan jenis kegagalan (pasti/tidak pasti) serta opsi retry

JVM crash akibat error klien (#2435)

• Pembungkusan thread/asinkron untuk mengakali timeout memicu masalah segfault pada JVM
• Terjadi karena field yang tidak diinisialisasi dengan benar direferensikan di klien Java, dan diperbaiki pada 0.16.12

Klien crash saat sesi kedaluwarsa (#2484)

• Fenomena penghentian paksa klien akibat sesi yang berlebihan
• Sejak 0.16.13, perilaku ini diubah menjadi pengembalian error

Lonjakan latensi saat satu node gagal (#2739)

• Kelemahan replikasi berbasis ring menyebabkan waktu respons seluruh sistem meningkat drastis saat beberapa node gagal
• Penyebabnya: secara default primary mengirim pesan selangkah demi selangkah ke node berikutnya, sehingga saat sebagian node gagal, sistem menunggu karena tidak menerima ack
• Sejak 0.16.30, latensi respons saat gangguan jauh membaik melalui penerapan replikasi reverse dan topologi ring dinamis

Bug Header API pada klien Java (#2495)

• Penggunaan objek singleton untuk batch respons kosong menyebabkan header dan timestamp ikut terbagi secara salah
• Tidak memengaruhi akurasi data, tetapi hasil Header API menjadi terkontaminasi; diperbaiki pada 0.16.14

Hasil kueri hilang (#2544)

• Pada versi 0.16.13 dilaporkan bug yang menyebabkan sebagian hasil query_accounts, query_transfers, dan lain-lain hilang, sehingga respons hanya dibatasi pada prefix yang benar

Kesimpulan

• TigerBeetle dikhususkan untuk lingkungan yang menuntut keamanan tinggi dan toleransi kesalahan di bidang keuangan dan akuntansi
• Rangkaian pengujian Jepsen mengungkap berbagai isu pada ketahanan pemulihan, konsistensi, model operasi, dan performa
• Melalui kolaborasi aktif, tercapai peningkatan nyata pada ketahanan gangguan, penanganan error klien, replikasi, dan otomatisasi upgrade
• Pada versi terbaru, sistem menawarkan tingkat keandalan yang lebih tinggi dalam respons terhadap kegagalan, jaminan koneksi dan respons, serta konsistensi operasi

(Sebagian isi ini disusun dengan merujuk pada berbagai sumber terbuka seperti Github, dokumentasi resmi TigerBeetle, dan laporan pengujian Jepsen)

[GN⁺]

Opini Hacker News

• Artikel Fuzzer Blind Spots (Meet Jepsen!) juga layak dijadikan referensi, dengan tautan https://tigerbeetle.com/blog/2025-06-06-fuzzer-blind-spots-meet-jepsen/ sebagai panduan

• Berbagi pengalaman bahwa untuk klaim keandalan dan skalabilitas TigerBeetle, selalu menunggu verifikasi akhir lewat laporan Jepsen; laporan kali ini dinilai menemukan beberapa isu, namun pendekatan engineering yang cepat memperbaikinya dan sekaligus memperkuat test suite internal agar bug serupa tidak terulang terlihat sangat baik. Dengan sikap seperti ini, ada harapan bahwa dalam 10 tahun TigerBeetle bisa menjadi default di ranah database khusus keuangan setara dengan posisi “pakai Postgres saja”, sekaligus apresiasi bahwa karya aphyr sangat membantu pembelajaran.

  • TigerBeetle memiliki lebih dari 6.000 assertion; beberapa di antaranya terlalu ketat sehingga sempat memicu crash, tetapi assertion tersebut justru berfungsi tepat seperti yang dimaksudkan sebagai peringatan. Dalam praktiknya, hanya ada bug correctness kecil pada fitur pengujian internal untuk memudahkan audit Jepsen di sisi klien Java, serta satu bug correctness yang tidak memengaruhi durability yang ditemukan Jepsen. Detail kasusnya dijelaskan di tautan ini. TigerBeetle dirancang dan diuji untuk menahan lebih banyak kegagalan dibanding Postgres, mengadopsi model kegagalan storage yang eksplisit, memasukkan hasil riset yang belum ada saat Postgres dirilis, serta memakai Deterministic Simulation Testing dan standar kode keselamatan NASA sebagai berbagai bentuk jaminan stabilitas. Bahkan untuk skenario kehilangan data pada Postgres yang jelas ada di literatur, TigerBeetle dikatakan dapat mendeteksi dan memulihkannya. Untuk penjelasan lebih lanjut, disarankan melihat bagian helical fault injection milik Kyle atau video presentasi QCon London ini.
  • Setiap kali membaca laporan Kyle, rasanya kemampuan sistem terdistribusi naik satu tingkat.

• Ungkapan senang melihat TigerBeetle benar-benar memenuhi janjinya setelah divalidasi oleh aphyr; ada harapan bahwa pendekatan yang benar bisa menghasilkan hasil yang benar pula. Namun di lapangan, data selain Account atau Transfer sering kali tetap disimpan di sistem eksternal dan database terpisah, sehingga muncul pertanyaan bagaimana masalah consistency dan pemulihan antara sistem eksternal yang kurang andal itu dan TigerBeetle benar-benar ditangani.

  • Zoran dari TigerBeetle menjelaskan pola integrasinya: secara umum disarankan arsitektur yang memisahkan control plane (OLGP umum, misalnya Postgres) dan data plane (OLTP, misalnya TigerBeetle). Informasi pengguna disimpan di OLGP sebagai “lemari arsip”, sedangkan data transaksi (inventaris → keranjang → pembayaran, dan seterusnya) disimpan di OLTP sebagai “brankas”, sehingga perannya terbagi. Hingga tiga pengenal data pengguna dapat dikaitkan ke tiap account atau transfer, lalu dihubungkan dengan entitas dan event di OLGP. Pemisahan ini memberi keuntungan dalam penskalaan, operasi, dan pengelolaan yang independen. Untuk kasus seperti bank, pemisahan antara uang tunai (brankas) dan informasi (lemari arsip) dipandang masuk akal. Karena frekuensi transaksi nyata berbeda dengan frekuensi perubahan informasi seperti nama atau email, struktur ini dijelaskan sebagai pilihan yang rasional. Demi konsistensi data, pada jalur write disarankan lebih dulu menulis data relasional yang dibutuhkan ke OLGP (serta storage eksternal seperti S3 bila perlu), lalu melakukan commit ke TigerBeetle sebagai langkah terakhir. Pada jalur read, TigerBeetle selalu dijadikan source of record, dengan usulan menjaga kepercayaan melalui strict serializability. Juga disertakan dokumen arsitektur.

• Pendapat bahwa jika sudah membaca postingan Jepsen tentang blind spot pada fuzzer, maka laporan TigerBeetle kali ini terasa jauh lebih menarik. Kasus segfault di sisi JNI mungkin tidak selalu bisa dicegah bahkan bila memakai bahasa memory-safe seperti Rust, tetapi pendekatan Zig/TigerStyle dari TigerBeetle dinilai memberi pembuktian yang baik terkait keamanan memori.

  • Ada pengalaman bahwa salah satu bug tersebut juga bisa dicegah di Rust; dalam praktiknya sebagian besar sudah diblokir oleh assertion, dan disebutkan bahwa tanpa TigerStyle situasinya bisa jauh lebih berbahaya.

• Kekaguman kecil bergaya golf clap atas kecerdikan judul bagian "Panic! At the Disk 0".

• Menyampaikan kesan mendalam terhadap laporan detail Jepsen yang kali ini, dan antusiasme tinggi meski versi v1.0 belum dirilis. Pendiri yang aktif membagikan insight di thread juga mendapat pujian tersendiri.

  • Ada juga apresiasi atas ketelitian Kyle dan kecermatan artistik laporannya, sekaligus harapan menantikan presentasi barunya di SD25 Amsterdam.

• Kesan menarik bahwa dalam pengujian sistem terdistribusi, agar verifikasinya akurat, sistem memang harus melaporkan sendiri urutan/waktu kejadian internal sehingga bisa dicocokkan tepat dengan model eksternal, dan hal ini terasa “jelas sekali kalau dipikir-pikir”.

  • Dijelaskan bahwa pendekatan seperti ini dimungkinkan dalam lingkungan strict serializability, sedangkan pada jaminan konsistensi yang lebih lemah, satu timeline global tidak mungkin dibentuk. Menariknya, ada pola meta bahwa dengan memperkenalkan masalah yang sulit, sistem justru bisa menjadi lebih sederhana; misalnya jika protokol kegagalan/pemulihan disk ditambahkan sebagai dasar, maka state sync untuk replica yang lambat bisa ikut “didapat gratis”.

• Setelah meninjau laporan Jepsen, blog terkait, dan kode integrasi Antithesis, muncul pertanyaan pembelajaran tentang cakupan dan efektivitas pengujian. Sudah diketahui bahwa TigerBeetle juga menjalankan pengujian komprehensif dengan Antithesis, sehingga timbul rasa ingin tahu bagaimana bug yang ditemukan Jepsen bisa lolos dari Antithesis, apa perbedaan pengujian Antithesis dan Jepsen, serta pada akhirnya bagaimana cakupan pengujian internal mereka benar-benar berbeda.

  • Sebagai penjelasan tambahan dari aphyr, untuk generative testing pada sistem terdistribusi dibutuhkan tiga elemen: 1) lingkungan tempat sistem dijalankan, 2) load generator, dan 3) auditor. Antithesis terutama berperan pada nomor 1, yaitu menyediakan lingkungan simulasi deterministik. Jepsen melakukan injeksi kegagalan pada mesin dan level OS yang nyata. VOPR milik TigerBeetle menjalankan seluruh cluster dalam satu thread. Masing-masing pendekatan simulasi saling melengkapi dengan kelebihan dan kekurangan yang berbeda. Dalam kasus bug kali ini, inti persoalannya justru ada pada nomor 2) dan 3), yakni workload generator dan auditor verifikasi. Kode Clojure khusus TigerBeetle yang dibuat aphyr itulah yang memicu dan mendeteksi bug tersebut; setelah itu mereka juga menambal kode internal yang ekuivalen. Fakta pentingnya adalah masalah yang lebih krusial justru ada di VOPR, bukan di database itu sendiri. Database terdistribusi akan selalu memiliki kemungkinan bug, sehingga pada dasarnya penting merancang beragam generator dan strategi pengujian.
  • Blog TigerBeetle juga menjelaskan isu ini secara rinci. Ringkasnya, pengujian yang dipakai di Antithesis tidak mencakup kondisi cross-query dan nilai out-of-order yang dibutuhkan untuk memunculkan bug tersebut, sedangkan sisi Jepsen berhasil mendeteksinya karena kombinasi itu tepat tercapai. Juga ditekankan bahwa test generator Jepsen pun memiliki keterbatasan tertentu, sehingga perlu beragam rancangan generator.
  • Sebanyak 90% pengujian simulasi keterlambatan internal dilakukan di VOPR (simulator internal mereka), berjalan 24/7 pada 1.000 core CPU. Antithesis dipakai sebagai lapisan tambahan. Untuk penjelasan mengapa bug di query engine itu bisa lolos, diarahkan ke postingan ini.

• Menyatakan tertarik pada TigerBeetle, lalu heran karena pada dokumentasi klien tidak terlihat adanya klien C atau Zig. Karena produknya sendiri ditulis langsung dengan Zig, muncul pertanyaan apakah klien tersebut memang belum ada atau masih dalam pengembangan.

• Pertanyaan apakah TigerBeetle sudah digunakan oleh bank besar atau perusahaan sekuritas besar.

  • Zoran dari TigerBeetle menjawab bahwa saat ini mereka akan dipakai untuk membangun sistem pembayaran digital nasional 2.0/e-money bank sentral di Luanda bekerja sama dengan Gates Foundation. Di tingkat enterprise, sudah ada layanan produksi pelanggan yang memproses lebih dari 100 juta transaksi per bulan. Mereka juga baru menandatangani kontrak dengan unicorn fintech Eropa senilai 2 miliar dolar, dan kontrak tambahan sedang berjalan di AS. Secara global, kebutuhan pemrosesan transaksi real-time mendorong semakin banyak adopsi TigerBeetle. Para pendiri Clear Street, broker Wall Street kelas menengah-besar, juga ikut berinvestasi. Tautan terkait: mojaloop.io, blog TigerBeetle, dan halaman perusahaan.
  • Bukan bank besar atau bursa besar, tetapi ada yang menyebut mereka sudah memakainya untuk produk baru di sebuah fintech besar.
  • Ada pendapat bahwa karena mereka tidak memamerkannya di homepage, kemungkinan belum ada referensi nama besar; untuk saat ini endorsement terbesar tampaknya sebatas rekomendasi dari YouTuber berpengaruh.