Github Radar — : TigerBeetle

GitHub Trending listesi yine sahte yıldızlarla şişirilmiş LLM wrapper’ları, mülakat hazırlık soru bankaları ve hafta sonu hevesiyle çatallanmış (forked) toy projelerle dolup taşıyor. Bu anlamsız gürültü duvarını ezip geçtiğimizde radarımıza takılan, mühendislik disiplini ve radikal mimari kararlarıyla parlayan gerçek bir altyapı projesi var: TigerBeetle ¹.

TigerBeetle, görev açısından kritik (mission-critical) ödeme sistemleri ve çift taraflı kayıt (double-entry) defter tutma operasyonları için özel olarak tasarlanmış dağıtık bir OLTP veritabanıdır. Projenin mühendislik dünyasındaki karşılığı nettir: Dağıtık finansal mutabakat ve yüksek hacimli bakiye takibi için geleneksel ilişkisel veritabanlarının (RDBMS) hantal kilit mekanizmaları yerine geçen, doğrudan donanıma konuşan özelleşmiş bir depolama ve mutabakat motorudur ². Genel amaçlı bir SQL veritabanı olma iddiası taşımaz; yalnızca tek bir problemi —hesap bakiyeleri ve para transferlerini— donanımın sunduğu fiziksel sınırlara kadar optimize ederek çözmeyi hedefler. Geleneksel sistemlerin bellek parçalanması (fragmentation), çöp toplayıcı (garbage collection) duraklamaları ve disk G/Ç darboğazları altında ezildiği yüksek işlem hacimlerinde, tüm bu parazitleri sistem seviyesinde devre dışı bırakır.

Mimari Deep-Dive: TigerBeetle

TigerBeetle’ın arkasındaki mimari kararlar, modern işletim sistemi katmanlarının soyutlama maliyetlerine ve donanım gerçeklerine karşı açık bir başkaldırıdır. Projenin çekirdeği Zig diliyle yazılmıştır ¹. Dil seçimi rastlantısal değildir: C’nin sunduğu doğrudan bellek ve donanım kontrolünü sağlarken, kontrolsüz makro karmaşasından ve öngörülemeyen örtük kontrol akışlarından (hidden control flow) uzaktır. Rust’ın borrow-checker mekanizmasının çekirdek seviyesindeki bellek içi döngüsel veri yapılarında yarattığı sürtünmeyi ortadan kaldırır; bellek tahsis edicilerinin (allocators) açıkça fonksiyondan fonksiyona parametre olarak aktarılmasını şart koşar ve derleme zamanı meta-programlama (comptime) kabiliyetiyle sıfır maliyetli tip güvenliği sunar.

TigerBeetle’ın benimsediği en radikal sistem kararı, katı statik bellek tahsisidir (static memory allocation). Sunucu süreci işletim sisteminden ayağa kalktığı anda gerekli tüm bellek bloklarını bir defada tahsis eder; bu başlangıç aşamasından sonra sistemin çalışma ömrü boyunca tek bir dinamik bellek tahsisi (malloc / free) çağrısı dahi yapılmaz ³. LSM-tree seviyeleri, yönlendirme tabloları, ağ halkaları ve transfer kuyruklarının kapasiteleri sabittir. Bu yaklaşım, üretim ortamlarında beklenmeyen bellek parçalanmasını (memory fragmentation), çalışma anında işletim sisteminin bellek yetersizliği katili (OOM killer) tarafından sürecin sonlandırılmasını ve tahsisat kilitlerini tamamen ortadan kaldırarak p99.99 seviyesinde deterministik bir kuyruk gecikmesi (tail latency) sağlar.

İkinci kritik tercih, Linux sayfa önbelleğinin (page cache) tamamen devre dışı bırakılmasıdır. Veritabanı diske yazarken işletim sisteminin tamponlama katmanını O_DIRECT bayrağı ile baypas eder ve disk işlemlerini doğrudan Linux çekirdeğinin modern io_uring arabirimi üzerinden asenkron olarak yürütür ⁴. Geleneksel veri tabanlarının sıklıkla kurbanı olduğu işletim sistemi kirli sayfa geri yazma (dirty page writeback) dalgalanmaları ve çift tamponlama (double buffering) maliyeti böylece yok edilir. Sistem geliştirme aşamasında macOS üzerinde kqueue soyutlamasını desteklese de üretim çekirdeği tavizsiz biçimde io_uring halka tamponlarına dayanır.

Ağ katmanından donanıma kadar her detay veri yapılarıyla sıkı sıkıya hizalanmıştır. TigerBeetle, ağ üzerinden aldığı ham baytları herhangi bir JSON veya Protobuf ayrıştırma (deserialization) döngüsüne sokmadan doğrudan 128 baytlık sabit boyutlu Account ve Transfer yapılarına eşler. Bu yapılar işlemci mimarisine tam uyum sağlamak adına 64 ve 128 baytlık önbellek satırlarına (cache-line) tam hizalı (alignment) tutulur ³. Böylece bellek bant genişliği azami düzeyde kullanılırken işlemci L1/L2 önbellek ıskalamaları (cache misses) minimize edilir.

Konsensüs katmanında ise Raft veya standart Paxos yerine Viewstamped Replication (VSR) protokolü tercih edilmiştir ². TigerBeetle ekibi, VSR protokolünü depolama katmanındaki fiziksel disk bozulmalarıyla (bit rot, torn writes) doğrudan haberleşen bir hata modeline entegre etmiştir. Her bir blok seviyesinde işletilen kriptografik sağlama toplamları (checksums), verinin bütünlüğünü sürekli doğrular. Sistemin en etkileyici güvenilirlik ayağı ise VOPR (Viewstamped Operation Processing Replica) adı verilen Deterministik Simülasyon Testidir (DST) ³. Rastgele tohumlanmış (pseudo-random seed) deterministik sanal saatler, yapay ağ gecikmeleri, paket kayıpları ve disk sektör bozulmaları eşliğinde, kümenin onlarca yıllık aşırı yük ve arıza senaryoları saatler içinde test edilir.

Kod ve Topluluk Sağlığı (Health Check)

TigerBeetle, açık kaynak kodlu altyapı ekosisteminde benzerine az rastlanan bir mühendislik disiplini ve kurumsal ciddiyetle yönetilmektedir. Proje, tek bir geliştiricinin hafta sonu macerası değildir; Joran Dirk Greef liderliğinde kurulan TigerBeetle Inc. şirketi tarafından finanse edilmekte ve rust-analyzer mimarı Alex Kladov (matklad) gibi düşük seviye sistem programlama uzmanlarından oluşan kıdemli bir çekirdek ekip tarafından sürdürülmektedir ¹.

Kod tabanının kalitesi, açıkça dokümante edilmiş TIGER_STYLE.md mühendislik prensipleriyle güvence altına alınmıştır ³. NASA’nın görev açısından kritik yazılım geliştirme standartlarından esinlenen bu rehber; her fonksiyonda ortalama en az iki açık assertion bulunmasını, tüm döngülerin sabit üst sınırlarının (bounded loops) olmasını, özyinelemenin (recursion) yasaklanmasını ve sızdıran soyutlama katmanlarının (leaky abstractions) kesinlikle reddedilmesini zorunlu kılar. Bu katı standartlar nedeniyle dışarıdan gelen topluluk PR’larının kabul edilme çıtası olağanüstü yüksektir. Dış katkıların mimari determinizmi ve bellek kısıtlarını bozmasına asla izin verilmez; PR incelemelerinde her bir baytın ve CPU döngüsünün hesabı sorulur.

Sürümleme stratejisi, ana dala (main branch) plansız kod birleştirme alışkanlığından uzaktır. Proje, semantik versiyonlama kurallarını (semver) titizlikle izlemekte ve haftalık yayın döngüsünü aksatmadan sürdürmektedir; şu anda 0.17.x sürüm ailesi altında düzenli protokol uyumluluk doğrulamalarıyla ilerlemektedir ⁵. GitHub issue listesindeki etkileşimler, ekibin teknik derinliğini kanıtlar niteliktedir. Örneğin, üç düğümlü bir kümede tek bir düğümün arızalanması durumunda kuyruk gecikmelerinin fırladığını belgeleyen #2739 numaralı issue, geçici yamalarla kapatılmamış; VSR hazırlık onarım protokolünün (prepare repair) küme hızına göre dinamik olarak ayarlanması ve VOPR simülasyonuna özel bir “performans modu” eklenmesiyle kök nedeninden çözülmüştür ⁶. Açık sorunlara verilen yanıtların tamamı ölçülebilir profilleme çıktıları ve izleme grafiklerine dayanır.

Production Riski: Gerçekten Kullanılır mı?

TigerBeetle’ı canlı sisteme (production) almayı düşünen bir mimarın romantik heveslerden arınıp soğukkanlı bir risk analizi yapması şarttır. Lisans tarafında kurumsal risk bulunmamaktadır; proje, herhangi bir Gizli Kaynak (BSL) ya da agresif copyleft tuzağı içermeyen, Kullanıcı Lisans Anlaşması (CLA) dayatması olmayan temiz bir Apache 2.0 lisansı ile dağıtılmaktadır ⁷.

Aracın üretim ortamında hayat kurtaracağı senaryo son derece belirgindir: Günde on milyonlarca transfer kaydı işleyen, geleneksel PostgreSQL veya MySQL altyapılarında satır seviyesinde kilitlenme (row-level locking), sayfa temizleme (vacuuming) duraklamaları ve bellek şişmesi nedeniyle çöken finansal teknolojiler, dijital cüzdanlar ve takas/eşleme platformları. Bu özelleşmiş görev sınırları içinde TigerBeetle, donanımı son damlasına kadar kullanarak benzeri görülmemiş bir maliyet avantajı ve gecikme öngörülebilirliği sağlar.

Buna karşın, yanlış kullanım senaryolarında TigerBeetle tüm sisteminizi havaya uçurabilir. Bu araç kesinlikle genel amaçlı bir veritabanı değildir; ikincil indeksler, rastgele JSON alanları, dinamik JOIN sorguları veya metin aramaları desteklenmez. Mimarinizi Komut ve Sorgu Sorumluluklarının Ayrılması (CQRS) prensibine göre tasarlamadıysanız ve raporlama yüklerini harici bir analitik veri tabanına aktarmayı planlamadıysanız TigerBeetle operasyonunuzu kilitler. İkinci temel risk ise operasyonel ekosistemin göreceli toyluğudur. Go, Java, Node.js, .NET ve Rust istemcileri resmi olarak sağlansa da, çeyrek asırlık ilişkisel veritabanlarının sunduğu yaygın yedekleme, küme orkestrasyonu, telemetri ve hata ayıklama araç seti henüz oluşum aşamasındadır. Ekibinizde işletim sistemi çekirdeği, G/Ç halkaları ve dağıtık konsensüs arıza dinamiklerini anlayacak kıdemli sistem mühendisleri yoksa, bu altyapıyı yönetmek ciddi bir operasyonel yük getirecektir.

Mimari Deep-Dive: TigerBeetle

Kod ve Topluluk Sağlığı (Health Check)

Production Riski: Gerçekten Kullanılır mı?

Kaynaklar