Jepsen: TigerBeetle 0.16.11

• TigerBeetle, çift taraflı muhasebe kayıtlarına odaklanan bir OLTP veritabanıdır ve güvenlik ile yüksek işlem hızını hedefleyerek geliştirilmiştir
• Viewstamped Replication uzlaşma protokolünü ve strong serializability ilkesini destekler; yüksek çekişmeli, yüksek hacimli iş yükleri için optimize edilmiş bir yapıya sahiptir
• Hata toleransı ve arıza dayanıklılığına güçlü biçimde odaklanan tasarım ve test süreçleriyle, çeşitli arıza durumlarında veri kaybı olmadan çalışmayı amaçlar
• Yükseltme, test, işlem modeli ve küme arıza dayanıklılığı gibi alanlarda çeşitli hata ve performans sorunları Jepsen testleriyle ortaya çıkarıldı ve bunlara verilen yanıtlar geliştirildi
• En son sürümde Ring tabanlı çoğaltma performansı, istemci hata işleme, loglama ve sorgu doğruluğu gibi alanlarda çeşitli iyileştirmeler ve hata düzeltmeleri sunuluyor

---

TigerBeetle'a giriş

• TigerBeetle, çift taraflı muhasebe (Double-entry bookkeeping) için özelleştirilmiş bir çevrimiçi işlem işleme (OLTP) veritabanıdır
• Viewstamped Replication (VR) uzlaşma protokolü temelinde strong serializability sağlar ve yalnızca hesaplar ile hesaplar arası transfer verilerini saklar
• Banka içi switch sistemleri, aracılık, biletleme, elektrik sayaçlama gibi işlem hacminin yüksek ve eşzamanlılık çekişmesinin yoğun olduğu ortamlar için uygundur
• Tüm yazma işlemlerini tek bir düğümün (Core) yönettiği bir yapıyla, yatay ölçekleme (scale-out) yerine dikey ölçeklemeye (scale-up) odaklanır
• Toplu işleme, IO paralelleştirme, sabit şema gibi donanım dostu optimizasyonlarla tek düğüm üzerindeki işlem hacmini en üst düzeye çıkarmayı hedefler

Arıza dayanıklılığı ve hata toleransı

• TigerBeetle; bellek, süreç, saat, depolama ve ağ hataları için açık modeller ve kurtarma prosedürleri sunar
• Veri kalıcılığı, yalnızca tek bir kopya hayatta kalsa bile veri kaybı olmayacağını garanti eder
  • Tüm kopyalardaki kayıtlar bozulursa sistem güvenli biçimde durur
• Sistem donanım/yazılım arızaları, saat sapmaları, disk bozulmaları, ağ gecikmesi/kaybı/tekrarı gibi çeşitli arıza türleri varsayılır
• Viewstamped Replication, Protocol-Aware Recovery, veri blokları için checksum ve çoklu kopya saklama mekanizmaları uygulanır
• Çalışma zamanı doğrulamaları (assertion) kullanılarak hata ve bug oluştuğunda etkiler en aza indirilmeye çalışılır

Yükseltme yöntemi

• İkili dosya, mevcut sürüm ile birlikte birden fazla önceki sürümün kodunu içerir
• Yükseltme, yalnızca ikili dosyanın değiştirilmesiyle yapılabilir
• Kümedeki tüm düğümler sürümü otomatik rolling yöntemle değiştirir; kullanıcı müdahalesi en aza indirilir
• Belirli bir sürümde commit edilen işlemlerin başka bir sürümde tekrar commit edilmesini önleyerek durum tutarsızlığını engellemede avantaj sağlar

Zaman modeli

• VR view ve işlem numaralarını kullanan mantıksal saat ile hibrit fiziksel saat (physical time) birlikte kullanılır
• Lider, tüm kopyaların POSIX zamanını toplar ve hata payı içinde küme genelinde karşılıklı senkronizasyon sağlar
• Saat senkronizasyonu 60 saniyeden uzun süre başarısız olursa hizmet reddedilir
• Zaman damgaları "Unix epoch'tan sonraki nanosaniyeler" cinsindendir ancak gerçek POSIX zamanından 27 saniye sapma oluşur
• Artık saniye ya da negatif zaman düzeltmesi olduğunda iç saatin yavaşlaması görülebilir

Veri modeli

• Yalnızca iki veri tipi desteklenir: hesap (account) ve transfer (transfer)
  • Her alan sabit boyutludur, değişmezlik (immutable) ilkesine uyar ve unsigned int tabanlıdır
• Hesap; kullanıcı tanımlı 128 bit id, ledger, bayraklar, oluşturulma zamanı ve özel alanlarla tanımlanır
• Transfer; debit/credit account id, code, amount ve özel alanlar gibi bilgileri içerir
• Transferler hem anında yürütme (tek aşama) hem de iki aşamalı (rezervasyon/yürütme uzlaşması) işlemeyi destekler
  • Bekleyen transferler (pending) iptal edilebilir veya süresi dolabilir
  • Özel transferlerle hesap kapatma/yeniden açma işlemleri yapılabilir

İşlem modeli ve transaction'lar

• İstemci, veri durumunu güncellemek veya sorgulamak için tek bir istek (batch) birimiyle çalışır
• İstek içindeki her olay sıralı ve atomik (atomic) transaction olarak işlenir
• Yeniden yürütme, çoklu istek transaction'ları ve etkileşimli sorgular desteklenmez
• Güçlü tutarlılık (Strong Serializability) ve güçlü oturum tutarlılığı sağlar
• Her işlemin başarı/başarısızlık durumu ve hata kodu döndürülür; chain (alt transaction) özelliğiyle bileşik işlemler desteklenir

Jepsen test tasarımı

• Jepsen kütüphanesiyle özellik tabanlı (property-based) testler ve hata enjeksiyonu (fault injection) gerçekleştirildi
• LXC, EC2 gibi farklı ortamlarda 3 ila 6 düğümlü kümeler üzerinde deneyler yapıldı
• Veri modeli kısıtları nedeniyle klasik liste/set tipi tutarlılık doğrulaması zordu; bunun yerine toplam işlem sırası (total order) kullanılarak durum ve zaman tutarlılığı doğrulandı
• Zaman damgası tabanlı tutarlılık kontrolleri, model doğrulama ve simülasyon gibi birbirini tamamlayan yöntemlerle hatalar tespit edildi

Model doğrulama ve işlem üretimi

• 1600+ satırlık tek iş parçacıklı bir durum makinesi modeliyle TigerBeetle davranışının doğruluğu ayrıntılı biçimde doğrulandı
• Çeşitli hata koşulları (yinelenen id, kesintili zaman damgaları, bakiye kısıtları vb.) ve bağlantılı chain yapıları için çıkarım ve rollback işleme uygulandı
• Doğrulama verimliliği için operation/id üretimi, durum güncelleme ve olasılık tabanlı sorgu kombinasyonları gibi çeşitli yöntemler kullanıldı

Hata enjeksiyonu

• Süreç çökmesi (SIGKILL), duraklatma (SIGSTOP), ağ bölünmesi, saat değişikliği gibi temel arıza senaryoları dahil edildi
• Sürüm yükseltme, dosya bozulması simülasyonu ve yalnızca bazı kopyalarda kısmi bozulma gibi ayrıntılı depolama arızası enjeksiyonları uygulandı
• Zigzag (helical) disk bozulması gibi çeşitli senaryolarla veri kaybı olasılığının en aza indirildiği doğrulandı

Başlıca hata örnekleri ve iyileştirmeler

İstek zaman aşımı işlemedeki sorunlar (#206)

• TigerBeetle tasarımına göre istemci istekleri asla zaman aşımına uğramaz; kümeden yanıt alınana kadar sonsuz yeniden deneme yapılır
• Pratikte ise Java gibi istemciler asenkron işlemlerde zaman aşımı istisnası üretebilir ve uygulamalar dış zaman aşımı koymak zorunda kalabilir
• Ağ hatalarını ya da kesin hataları belirsiz biçimde gizleyen bu tasarım nedeniyle kesin başarısızlık ile belirsiz hata ayrımı zorlaşır
• Jepsen, hata türüne göre (kesin/belirsiz) dönüş biçimi ve yeniden deneme seçenekleri eklenmesini önerdi

İstemci hatası nedeniyle JVM çökmesi (#2435)

• Zaman aşımını aşmak için yapılan iş parçacığı/asenkron sarmalama, JVM segfault sorununa yol açtı
• Java istemcisinde uygun biçimde başlatılmamış bir alanın referans edilmesinden kaynaklandı; 0.16.12'de düzeltildi

Oturum süresi dolduğunda istemci çökmesi (#2484)

• Aşırı sayıda oturum nedeniyle istemcinin zorla kapanması sorunu yaşandı
• 0.16.13'ten itibaren bunun yerine hata döndürme yaklaşımı benimsendi

Tek düğüm arızasında gecikmenin aniden artması (#2739)

• Ring tabanlı çoğaltmanın zayıflığı nedeniyle bazı düğümler başarısız olduğunda genel yanıt süresi ciddi biçimde uzuyordu
• Nedeni: varsayılan olarak primary düğüm mesajları bir sonraki düğüme tek tek iletir; bazı düğümler başarısız olduğunda ack alınamadığı için bekleme oluşur
• 0.16.30 sonrasında ters yönlü çoğaltma ve dinamik ring topolojisi eklenerek arıza anındaki yanıt gecikmesi büyük ölçüde iyileştirildi

Java istemcisi Header API hatası (#2495)

• Boş yanıt batch'lerinde singleton nesne kullanılması nedeniyle header ve zaman damgalarının yanlış paylaşılması sorunu oluştu
• Veri doğruluğunu etkilemese de Header API sonuçlarını bozuyordu; 0.16.14'te düzeltildi

Sorgu sonucunun eksik dönmesi (#2544)

• 0.16.13 sürümünde query_accounts, query_transfers gibi sorgularda bazı sonuçların eksik dönmesine yol açan bir hata raporlandı; yanıt yalnızca doğru prefix ile sınırlandırılıyordu

Sonuç

• TigerBeetle, finans ve muhasebe alanında yüksek güvenlik ve hata toleransı gerektiren ortamlar için özelleştirilmiştir
• Jepsen test serileriyle dayanıklılık, tutarlılık, işlem modeli ve performans açısından çeşitli sorunlar ortaya çıkarıldı
• Aktif iş birliği sayesinde arıza dayanıklılığı, istemci hata işleme, çoğaltma ve yükseltme otomasyonu gibi alanlarda somut iyileştirmeler yapıldı
• En güncel sürüm, arızalara daha dayanıklı tepki, bağlantı ve yanıt güvencesi ile işlem tutarlılığı açısından daha yüksek güvenilirlik sunuyor

(Bu içeriğin bir bölümü Github, resmi TigerBeetle belgeleri ve Jepsen test raporları gibi çeşitli açık kaynaklardan yararlanılarak hazırlanmıştır)

[GN⁺]

Hacker News görüşleri

• Ek bilgi olarak Fuzzer Blind Spots (Meet Jepsen!) yazısına da bakılabilir: https://tigerbeetle.com/blog/2025-06-06-fuzzer-blind-spots-meet-jepsen/

• TigerBeetle’ın güvenilirliği ve ölçeklenebilirliğiyle ilgili anlatılanları her zaman en son Jepsen raporuyla doğrulama alışkanlığını paylaşıyor; bu raporda çeşitli sorunların bulunmuş olması, bunların hızlıca düzeltilmesi ve benzer hataların tekrarlanmaması için iç test paketinin de güçlendirilmesi şeklindeki mühendislik yaklaşımını beğendiğini söylüyor. Bu tavırla giderse 10 yıl sonra finans odaklı veritabanı alanında “git Postgres kullan” seviyesinde varsayılan tercih haline gelmesini beklediğini ekliyor. aphyr’ın harika çalışması sayesinde çok şey öğrendiğini de belirtiyor.

  • TigerBeetle’da 6.000’den fazla assertion bulunduğunu, bazılarının fazla katı olduğu için kimi crash’leri tetiklediğini ama bu assertion’ların tam da amaçlandığı gibi uyarı işlevi gördüğünü anlatıyor. Pratikte küçük bir correctness bug’ın yalnızca Java istemcisi tarafında Jepsen denetimini kolaylaştıran dahili test özelliğinde ortaya çıktığını, durability’yi etkilemeyen bir correctness bug’ın da Jepsen tarafından bulunduğunu söylüyor. İlgili örnekler bu bağlantıda ayrıntılı anlatılıyor. TigerBeetle’ın Postgres’ten daha fazla arızaya dayanacak şekilde tasarlanıp test edildiğini, açık bir depolama arızası modelini benimsediğini, Postgres’in çıktığı dönemde var olmayan araştırma sonuçlarını yansıttığını, Deterministic Simulation Testing ve NASA güvenli kod standartları gibi çeşitli güvenilirlik önlemleri kullandığını belirtiyor. Hatta literatürde veri kaybı yaşadığı açık olan bazı Postgres senaryolarında TigerBeetle’ın tespit ve kurtarma yapabildiğini söylüyor. Daha fazla ayrıntı için Kyle’ın helical fault injection bölümüne ya da QCon London konuşmasının videosuna bakılmasını öneriyor.
  • Kyle’ın raporlarını her okuyuşunda dağıtık sistemler konusundaki becerisinin bir seviye arttığını hissettiğini paylaşıyor.

• TigerBeetle’ın aphyr tarafından doğrulanıp verdiği sözleri tuttuğunu görmenin sevindirici olduğunu söylüyor; doğru yaklaşımın gerçekten doğru sonuçlara götürebileceğine dair umut verici buluyor. Gerçek sahada Account veya Transfer dışındaki verilerin çoğu zaman harici sistemlerde ve ayrı veritabanlarında tutulduğunu, bu durumda bu daha az güvenilir dış sistemlerle TigerBeetle arasındaki tutarlılık ve kurtarma süreçlerinin pratikte nasıl yürüdüğünü soruyor.

  • TigerBeetle’dan Joran entegrasyon desenini açıklıyor: Genelde control plane (genel OLGP, ör. Postgres) ile data plane’i (OLTP, ör. TigerBeetle) ayıran bir mimari önerdiklerini söylüyor. Kullanıcı bilgileri gibi veriler OLGP denilen “evrak dolabında”, işlem verileri (envanter → sepet → ödeme gibi) ise OLTP denilen “kasada” tutuluyor. Hesap veya transfer başına en fazla 3 kullanıcı veri tanımlayıcısı bağlanabildiğini, böylece OLGP varlıklarıyla event’lerin ilişkilendirilebildiğini belirtiyor. Bu ayrımın bağımsız ölçekleme, işletim ve yönetim avantajları sunduğunu; örneğin bir bankada nakit ile bilginin ayrılması gerektiği için uygun bir model olduğunu söylüyor. Gerçek işlem sıklığı ile bilgi değişim sıklığının (isim/e-posta vb.) farklı olduğu için bu yapının mantıklı olduğunu ekliyor. Veri tutarlılığı için write yolunda önce OLGP’ye (ve gerekliyse S3 gibi harici depolara) bağımlı verilerin yazılmasını, en son TigerBeetle’a commit edilmesini öneriyorlar. Read yolunda ise her zaman source of record olarak TigerBeetle’ın sorgulanması ve strict serializability sayesinde güven sağlanması tavsiye ediliyor. İlgili mimari dokümanı da paylaşıyor.

• Jepsen’in fuzzer blind spot yazısını okuyan biri olarak bu TigerBeetle raporunu çok daha ilginç bulduğunu söylüyor. JNI tarafındaki segfault örneğinin Rust gibi bellek güvenli diller kullanıldığında engellenmeyebileceğini ama TigerBeetle’ın Zig/TigerStyle yaklaşımının bellek güvenliği açısından iyi bir kanıt sunduğunu düşünüyor.

  • Rust ile de savunulabilecek bir hata örneği yaşadıklarını, gerçekte assertion’ların çoğunu engellediğini ve TigerStyle olmasaydı durumun daha tehlikeli olabileceğini söylüyor.

• Panic! At the Disk 0 bölüm başlığının zekice oluşunu küçük bir golf alkışıyla takdir ediyor.

• Jepsen’den geçmiş bu ayrıntılı rapordan çok etkilendiğini, henüz v1.0 çıkmamış olsa da beklentisinin oldukça yükseldiğini söylüyor. Kurucuların başlık altında aktif biçimde içgörü paylaşmasını da ayrıca övüyor.

  • Kyle’ın titizliği ve raporun adeta sanatsal bir incelik taşıması hakkında konuşup, SD25 Amsterdam’daki yeni sunum haberini de merakla beklediğini ekliyor.

• Dağıtık sistem testlerinde, sistem içinde olayların gerçekleşme sırası/zamanı bilgisinin sistem tarafından doğrudan raporlanıp dış modelle birebir karşılaştırılmasının doğru doğrulama için fiilen temel bir gereklilik olmasının ilginç ve “apaçık doğru” hissettirdiğini söylüyor.

  • strict serializability ortamında bunun mümkün olduğunu, daha zayıf tutarlılık garantilerinde ise tek bir küresel zaman çizelgesinin kurulamayacağını açıklıyor. Zor bir problemi sisteme dahil etmenin paradoksal biçimde sistemi sadeleştirmesi şeklindeki meta deseni ilginç bulduğunu; örneğin disk arızası/kurtarma protokolünü temelden ekleyince yavaş replica’ların state sync ihtiyacının da “bedavaya” çözülebildiğini anlatıyor.

• Jepsen raporunu, ilgili blog yazısını ve Antithesis entegrasyon kodunu inceledikten sonra test kapsamı ve etkisi üzerine öğrenme amaçlı bir soru soruyor: TigerBeetle’ın zaten Antithesis ile de kapsamlı testler yaptığını bildiğini, buna rağmen Jepsen’in bulduğu hatanın Antithesis tarafından neden yakalanamadığını merak ediyor. Antithesis ile Jepsen testleri arasındaki farkları ve iç test kapsamının nihayetinde nasıl ayrıştığını daha somut biçimde soruyor.

  • aphyr ek açıklama yapıyor: Dağıtık sistemlerde generative testing için üç unsur gerektiğini söylüyor: 1) sistemin çalışma ortamı, 2) yük üreteci, 3) denetçi/auditor. Antithesis’in daha çok 1 numara, yani deterministik simülasyon ortamı sağlama tarafında güçlü olduğunu belirtiyor. Jepsen’in ise gerçek makine/OS seviyesinde hata enjeksiyonu yaptığını; TigerBeetle’ın VOPR sisteminin tüm küme simülasyonunu tek bir thread içinde çalıştırdığını anlatıyor. Bu simülasyon yaklaşımlarının her birinin farklı artı ve eksileri olduğunu söylüyor. Bu bug vakasında asıl belirleyici olanın 2) ve 3), yani workload üretimi ile doğrulayıcı auditor olduğunu; aphyr’ın TigerBeetle’a özel Clojure kodunun hatayı hem tetiklediğini hem de tespit ettiğini, sonrasında eşdeğer şirket içi kodun da yamalandığını belirtiyor. Sorunun veritabanının kendisinden çok VOPR tarafında daha kritik olduğuna dikkat çekiyor. Dağıtık veritabanlarında her zaman bug ihtimali olduğunu ve esas meselenin farklı üretici/test stratejileri tasarlamak olduğunu vurguluyor.
  • TigerBeetle’ın blogunda da konu ayrıntılı anlatılıyor: Özetle Antithesis’te kullanılan testler, bu hatanın ortaya çıkması için gereken çapraz sorguları ve out-of-order değer koşullarını içermediği için bug gözden kaçmış; Jepsen tarafı ise bu kombinasyonu kurabildiği için tespit etmiş. Jepsen’in test generator’larının da belli sınırları olduğunu ve bu yüzden farklı generator tasarımlarının gerekli olduğunu özellikle belirtiyor.
  • Dahili gecikme simülasyonu testlerinin %90’ının VOPR (kendi simülatörleri) üzerinde yapıldığını, bunun 1.000 CPU çekirdeğiyle 7/24 çalıştığını; Antithesis’in ise ek bir katman olarak kullanıldığını söylüyor. Sorgu motoru bug’ının neden kaçtığına dair ayrıntılar için bu yazıya bakılmasını öneriyor.

• TigerBeetle’la ilgilendiğini söyleyip, istemci dokümantasyonunda C veya Zig istemcisi görünmemesini garipsiyor; ürün doğrudan Zig ile yazılmışken böyle bir istemcinin hiç olmamasını ya da hâlâ geliştirme aşamasında olmasını soruyor.

• TigerBeetle’ın hâlihazırda büyük bankalar veya aracı kurumlar tarafından kullanılıp kullanılmadığını merak ediyor.

  • TigerBeetle’dan Joran yanıtlıyor: Şu anda Gates Foundation ile birlikte Luanda’nın ulusal dijital ödeme sistemi 2.0 merkez bankası elektronik para altyapısında kullanılmasının planlandığını söylüyor. Kurumsal tarafta ise aylık 100 milyonun üzerinde işlem işleyen müşterilerin canlı sistemlerde zaten çalıştığını, yakın zamanda Avrupa’da 2 milyar dolar değerlemeli bir fintech unicorn ile anlaşma yapıldığını, ABD’de de ek anlaşmaların sürdüğünü belirtiyor. Dünya genelinde gerçek zamanlı işlem işleme ihtiyacı arttıkça TigerBeetle’a talebin büyüdüğünü ekliyor. Nitekim Wall Street’teki orta-büyük ölçekli aracı kurum Clear Street’in kurucularının yatırımcılar arasında yer aldığını söylüyor. İlgili bağlantılar: mojaloop.io, TigerBeetle blogu, şirket sayfası
  • Büyük banka veya borsa olmasa da kendisinin büyük bir fintech şirketinde yeni bir ürün için bunu zaten kullandığını söylüyor.
  • Ana sayfada övünerek paylaşılmamasından dolayı çok büyük isimli referanslar olmayabileceğini tahmin ediyor; şu an için en güçlü onayın etkili bir YouTuber önerisi gibi göründüğünü belirtiyor.