TigerBeetle adalah database paling menarik di dunia
(amplifypartners.com)- TigerBeetle, database transaksi keuangan, adalah database baru yang secara native mendukung debit dan credit, dan tidak seperti database SQL lama yang membutuhkan 10–20 query untuk satu transaksi, ia dapat memproses 8.190 transaksi dalam satu roundtrip
- Saat banyak sistem memilih coding cepat dan perluasan dependensi, proyek ini justru memegang strategi yang bertentangan dengan arus seperti menulis kode secara perlahan, Deterministic Simulation Testing (DST), dan zero dependency
- Berbeda dari database OLTP lama yang bergantung pada arsitektur single-node, desainnya sejak awal memasukkan distributed by default, toleransi kegagalan clock (cluster time), dan toleransi kegagalan storage, sambil menjaga kesederhanaan implementasi dan visibilitas lewat Viewstamped Replication dan pemilihan Zig
- Dengan menerapkan metodologi TigerStyle yang terinspirasi dari Power of Ten milik NASA, proyek ini mengikuti standar coding ketat seperti rata-rata lebih dari 2 assertion per fungsi, pemaksaan alokasi memori statis, dan assertion tetap aktif bahkan di lingkungan produksi
- Dengan struktur yang dirancang untuk era hyper-transactional seperti pembayaran real-time, gaming, dan penagihan energi, TigerBeetle menawarkan tolok ukur performa dan akurasi untuk OLTP generasi berikutnya dan muncul sebagai sistem pemrosesan transaksi generasi baru yang dapat menggantikan database SQL lama berusia 20–30 tahun
Kebutuhan akan database yang berpusat pada debit/credit
- TigerBeetle adalah "database transaksi keuangan" yang menggunakan debit dan credit sebagai primitif inti
- Hakikat transaksi yang didefinisikan Jim Gray pada 1985 bukanlah transaksi SQL, melainkan transaksi bisnis (debit/credit)
- Bahkan 20 tahun kemudian, Gray masih mendefinisikan pemrosesan transaksi standar sebagai "DebitCredit": memproses debit pada rekening bank, melakukan pembukuan berpasangan, lalu merespons terminal
- Debit/credit bukan hanya untuk akuntansi atau perbankan, melainkan bahasa umum yang mewakili hakikat transaksi, dan alasan mengapa jaminan seperti ACID dibutuhkan
- Masalah saat mengimplementasikan debit/credit di database SQL lama
- Untuk satu proses debit/credit diperlukan 10–20 query SQL seperti memeriksa saldo akun, mengunci baris, menunggu pengambilan keputusan di dalam kode, dan mencatat debit/credit
- Kunci baris harus dipertahankan selama network roundtrip, yang memperparah masalah hot row ketika banyak transaksi mengakses "house account" yang sama
- Dengan miliaran pembayaran instan bulanan di India dan Brasil, FedNow di AS, serta billing real-time di energi, gaming, dan cloud, dunia menjadi jauh lebih transaction-centric setidaknya hingga tiga digit dalam 10 tahun, tetapi database SQL yang digunakan saat ini masih teknologi 20–30 tahun lalu
- Titik diferensiasi TigerBeetle
- Debit/credit dirancang sebagai primitif kelas satu, sehingga 8.190 transaksi dapat diproses dalam satu roundtrip melalui satu query 1MiB
- Pendiri Joran menyebutnya sebagai "ide performa 1000x", tetapi juga mengatakan bahwa itu "bukan sesuatu yang istimewa"
- Biasanya database membutuhkan 10 tahun untuk dibangun, tetapi TigerBeetle selesai dalam 3,5 tahun dan lolos pengujian Jepsen
- Pada Juni 2025, Kyle Kingsbury tidak mampu merusak fondasi TigerBeetle meskipun merusak berbagai lokasi di semua mesin (hanya menemukan 1 bug correctness pada read query engine yang tidak memengaruhi durability)
Desain database modern
Arsitektur terdistribusi sebagai default
- Pada era ketika Postgres dan MySQL dibangun, paradigma single-node mendominasi, tetapi di era hardware cloud bersama saat ini, paradigma distributed menjadi arus utama
- Database modern perlu menyediakan serializability yang ketat dan mereplikasi transaksi antar mesin untuk mendapatkan redundansi, toleransi kegagalan, dan high availability
- Sebagian database OLTP paling populer saat ini masih sangat bergantung pada arsitektur single-node, dan ada yang bahkan tidak memiliki automatic failover bawaan secara default
- Desain terdistribusi TigerBeetle
- Dibangun agar distributed by default, sehingga cukup memasang binari pada sebanyak mungkin mesin yang diinginkan dalam cluster
- Tidak memerlukan asynchronous replication, Zookeeper, dan sejenisnya; sebagai gantinya berinvestasi pada implementasi protokol konsensus pionir MIT, Viewstamped Replication
- Menjaga zero dependency selain toolchain Zig, dan berinvestasi langsung pada seluruh dependensi inti
Toleransi terhadap kegagalan clock
- Sebagai database transaksi, TigerBeetle menilai akurasi physical timestamp penting untuk audit dan kepatuhan regulasi
- Linux memiliki beberapa clock:
CLOCK_MONOTONIC_RAW,CLOCK_MONOTONIC,CLOCK_BOOTTIME - Karena ketidaksempurnaan fisik hardware clock, clock dapat berjalan dengan kecepatan berbeda dan menimbulkan error "drift", yang lalu terakumulasi menjadi error "skew" dalam waktu singkat
- Biasanya NTP memperbaiki error ini, tetapi jika NTP diam-diam berhenti karena gangguan jaringan parsial, cluster konsensus high-availability bisa berjalan dalam kegelapan
- Linux memiliki beberapa clock:
- Implementasi cluster time
- Dengan menggabungkan mayoritas clock dalam cluster, dibentuk clock yang fault-tolerant bernama "cluster time"
- Jika perlu, waktu sistem server disejajarkan kembali, atau sistem dimatikan dengan aman bila terlalu banyak clock yang rusak
- Dapat benar-benar mendeteksi jika Chrony, PTP, atau NTP berhenti bekerja dan memberi peringatan kepada operator
- Melacak dan mengambil sampel offset waktu clock antarseserver, lalu memakai algoritma Marzullo untuk memperkirakan interval paling akurat
Menangani kegagalan storage
-
Asumsi database lama
- Mengasumsikan bahwa saat disk gagal, sistem akan gagal secara dapat diprediksi disertai pesan error
- Dokumentasi SQLite: "SQLite does not add redundancy to the database file for the purpose of detecting corruption or I/O errors, and assumes that the data it reads is exactly the same data that it previously wrote."
-
Skenario kegagalan storage di dunia nyata
- Disk dapat diam-diam mengembalikan data yang korup, salah mengarahkan I/O (jalur baca/tulis), atau tiba-tiba melambat tanpa kode error sebagai gray failure
-
Toleransi kegagalan storage TigerBeetle
- Menggunakan Protocol Aware Recovery sehingga ketersediaan tetap terjaga selama salinan data tidak korup di semua replika
- Semua data bersifat immutable, dan checksum serta hash chain memberi jaminan kuat bahwa tidak ada korupsi atau manipulasi
- Dengan page cache sendiri, menulis ke disk melalui O_DIRECT, dan berjalan langsung pada raw block device tanpa filesystem, TigerBeetle meminimalkan layer antara disk dan software
- Menggunakan LSM Forest buatan sendiri (sekitar 20 pohon LSM), bukan LSM siap pakai
- Bukan hanya mengklaim toleransi kegagalan storage, tetapi juga satu-satunya database terdistribusi yang diverifikasi oleh Jepsen untuk hal tersebut
- Saat mesin lokal gagal, bahkan jika hanya sektor disk yang rusak, storage engine terhubung ke konsensus global dan memulihkan dirinya melalui cluster
Alasan memilih bahasa pemrograman Zig
-
Bahasa yang digunakan database lama
- Postgres ditulis dalam C (1970-an), MySQL dalam C dan C++ (1979), dan MSSQL juga ditulis dalam C dan C++
- Bahasa pemrograman telah berkembang pesat selama 40 tahun terakhir, dan jika dibangun secara modern, pilihannya bisa Rust atau Zig
-
Mengapa TigerBeetle memilih Zig
- Dapat memanfaatkan seluruh ekosistem C, serta menyediakan toolchain dan compiler yang sangat baik
- Mudah ditulis dan terutama mudah dibaca, dalam beberapa kasus semudah TypeScript tetapi jauh lebih cepat
- Memungkinkan alokasi memori statis, yang merupakan prinsip inti TigerBeetle
- Pengalaman developer yang baik dan cepat dipelajari, sehingga developer dapat cepat memahami source code TigerBeetle
- Anggota awal tim Rust seperti Matklad (pendiri Rust Analyzer) dan Brian Anderson (co-creator Rust bersama Graydon) bekerja di TigerBeetle
- Tidak memakai alokasi memori dinamis di Rust adalah "hard mode", tetapi di Zig hal itu mudah
Deterministic Simulation Testing dan VOPR
Konsep dasar DST
-
Deterministic Simulation Testing (DST) adalah teknik pengujian inovatif yang dipopulerkan oleh tim FoundationDB (kini dimiliki Apple)
- Digunakan untuk mengembangkan database terdistribusi yang lebih aman dan minim bug dalam waktu lebih singkat dibanding sebelumnya
- Sistem terdistribusi memiliki kombinasi masalah konkurensi yang tak terbatas: hilangnya pesan, urutan eksekusi thread yang tak terduga, dan lain-lain
- Unit test dan integration test tradisional tidak cukup, sedangkan formal verification mahal dan lambat
-
Cara kerja DST
- Sebuah simulator yang menjalankan secara deterministik hampir semua skenario yang mungkin dihadapi sistem pada timeline tertentu
- Juga mempertimbangkan faktor eksternal seperti OS, jaringan, masalah disk, atau berbagai jenis latensi
- Memberikan pengujian setara bertahun-tahun dalam waktu singkat (waktu itu sendiri menjadi deterministik sehingga loop
while truedimungkinkan) - Sangat cocok untuk database yang intensif I/O dan bukan intensif komputasi
- Pengujian Jepsen adalah subset dari apa yang dapat dilakukan DST
VOPR milik TigerBeetle
-
Ikhtisar VOPR (Viewstamped Operation Replicator)
- Cluster pengujian buatan sendiri yang namanya diambil dari simulator WOPR di film WarGames
- Terus-menerus menguji TigerBeetle dalam sangat banyak kondisi berbeda, mulai dari cara node memilih leader hingga kegagalan state individual dan jaringan
- Dapat mensimulasikan seluruh cluster terdistribusi secara virtual dalam satu thread
-
Skala VOPR
- Merupakan cluster DST terbesar di dunia, berjalan pada 1.000 CPU core
- Skalnya sangat tidak biasa sampai Hetzner mengirim email khusus untuk memastikan apakah mereka benar-benar menginginkan sebanyak itu core
- VOPR-1000 berjalan 24x7x365 untuk menangkap kondisi langka sebanyak mungkin sebelum produksi
- Dalam simulator, waktu diabstraksikan secara deterministik dan dipercepat sekitar 700 kali, sehingga mengakumulasi sekitar 2.000 tahun runtime simulasi per hari
Mengubah DST menjadi game
- TigerBeetle mengubah DST menjadi game, sehingga berbagai skenario kegagalan dapat dimainkan melalui respons sistem
- Game tersebut dapat dimainkan di sim.tigerbeetle.com
- Menjalankan instance VOPR nyata di browser untuk mensimulasikan TigerBeetle
- Dikompilasi ke WebAssembly, dan frontend game dibuat oleh para engineer TigerBeetle untuk memvisualisasikan sistem nyata
TigerStyle dan Power of Ten
Metodologi TigerStyle
-
TigerStyle adalah metodologi engineering TigerBeetle dan dipublikasikan di GitHub
- "Sebuah pertukaran kolektif yang terus berkembang di persimpangan engineering dan seni, angka dan intuisi manusia, nalar dan pengalaman, prinsip pertama dan pengetahuan, presisi dan puisi"
- Mengadopsi konsep "Biodigital Jazz" dari film Tron: Legacy: keterjalinan unsur manusia dan digital, sifat "Grid" yang kacau namun terstruktur, dan ekspresi semangat improvisasional dari potensi manusia di dalam teknologi
- Di TigerBeetle, semangat kode ini tidak hanya menyuntikkan sains tetapi juga seni
-
Pengaruh TigerStyle
- Menawarkan prinsip engineering dan coding yang diturunkan dari Power of Ten, prinsip NASA untuk menulis kode yang sempurna
- Mencakup tema seperti kesederhanaan dan keanggunan hingga penerapan seperti cara penamaan
- Mulai memengaruhi perusahaan lain seperti Resonate dan Turso
- Juga dibahas di podcast Lex Fridman
Penggunaan assertion
-
Aturan 5 Power of Ten: Assertion
- Konsep untuk secara eksplisit mengodekan ekspektasi terhadap perilaku kode pada saat yang sama ketika menulisnya, bukan setelahnya
- Ditulis sebagai boolean dalam satu baris: assert(a > b)
-
Aturan assertion dalam TigerStyle
- Melakukan assert pada semua argumen fungsi, nilai balik, prasyarat, dan invariant, dengan rata-rata minimal 2 assertion per fungsi
- Jika assertion penting dan mengejutkan, gunakan assertion alih-alih komentar
- Melakukan assert pada hubungan antarkonstanta saat compile time agar integritas desain terverifikasi sebelum program dijalankan
- Melakukan assert bukan hanya pada hal yang seharusnya terjadi, tetapi juga pada ruang negatif yang tidak diharapkan, tempat bug menarik bisa muncul
Cara berpikir tentang performa
-
Lebih penting bernalar dan mendesain kode daripada sekadar menulis kode
- Waktu terbaik untuk menyelesaikan masalah performa dan meraih kemenangan besar 1000x adalah pada tahap desain, tepat pada momen ketika hal itu belum bisa diukur atau diprofilkan
-
Prinsip performa TigerStyle
- Melakukan napkin math dasar terhadap "empat warna primer" (network, storage, memory, CPU) dan "dua tekstur" (bandwidth dan latency)
- Memberikan kiat taktis seperti membedakan control plane dan data plane, melakukan batching akses, dan mengekstrak hot loop menjadi fungsi standalone untuk mengurangi dependensi compiler
Mencoba langsung
- TigerBeetle menerapkan riset modern ke format lama untuk menghadirkan jaminan performa dan keandalan yang belum pernah ada sebelumnya
- Merupakan engine OLTP modern yang menggabungkan pemodelan debit/credit secara native, distributed by default, toleransi kegagalan storage dan clock, serta quality assurance berbasis DST
- Mengembangkan bentuk seni dalam engineering sistem dan storage, sambil tetap tidak melupakan kesenangan dalam prosesnya
- Berkat pemanfaatan DST yang cerdas, sistem ini dibangun hingga standar Jepsen hanya dalam beberapa tahun
- Instalasinya mudah dengan satu binari, dan Anda bisa cepat memulai serta mencobanya hanya dengan perintah curl melalui skrip instalasi sederhana di situs resmi
6 komentar
Kalau memikirkan kenapa database tidak memakai node terdistribusi, kamu bisa memahami kenapa Postgres itu node tunggal
Coba pikirkan, apa yang lebih penting daripada performa
Komentar Hacker News
TigerBeetle memang hebat, tetapi perlu diketahui bahwa tulisan ini dibuat oleh firma investasi yang berinvestasi di TigerBeetle tautan terkait
Selama beberapa bulan ke depan, saya kemungkinan akan terus menulis posting seperti ini, dan saya harap orang-orang akan berdiskusi lebih aktif; saya penasaran apakah lebih baik menambahkan disclaimer di bagian atas, karena itu tidak sulit dilakukan
Artikel tersebut jelas dipasang di situs firma investasi dengan label “Portfolio Spotlight”, jadi ekspektasi perlu disesuaikan
Saya tidak akan secara khusus menyinggung gaya penulisannya, tetapi sangat mudah terlihat bahwa ini tulisan dari firma investasi
Saya penggemar komitmen TigerBeetle terhadap correctness, praktik pemrograman, dan arah yang sangat terspesialisasi, tetapi saya ingin mengkritik beberapa poin dalam posting tersebut
Penjelasan tentang multi-node agak menyesatkan. Apa pun kata orang cloud-native, single DB yang dituning dengan baik plus connection pooler saja sudah bisa menangani QPS yang sangat besar. Di perusahaan lama saya, saat maintenance kami pernah keliru mengarahkan seluruh traffic ke satu instance MySQL 8 RDS, dan itu tetap sanggup menangani 80~90K QPS tanpa masalah. Instancenya juga tidak besar; kami hanya menata schema, query, dan tuning ProxySQL/MySQL dengan baik. Saat puncak, dengan satu writer dan dua read replica, 120K QPS juga sanggup ditangani
Jika memakai NVMe node-local di server, kemungkinan besar batas CPU akan tercapai lebih dulu
Soal redundansi, jika itu RDBMS yang dirancang sesuai lingkungan jaringan, pada akhirnya semuanya punya fitur failover dan hot standby
Sistem consensus TigerBeetle cerdas dan tidak memiliki dependensi eksternal, tetapi tidak mencoba menangani row berukuran besar. Jika ribuan transaksi diproses sekaligus dalam satu paket 1MiB, itu bisa memungkinkan hal-hal yang tidak mungkin dilakukan di RDBMS tradisional
Kritik ini tidak dimaksudkan untuk meremehkan pencapaian mereka; saya tetap sangat terkesan dengan produk ini
Penunjukan keterbatasan protokol consensus itulah justru poin utamanya. TigerBeetle ingin memisahkan dan menangani hanya pekerjaan transaksi, bukan menggantikan semua OLGP db. Maksudnya adalah memindahkan hanya data penting ke DB transaksi terpisah. Pendekatan seperti ini juga dapat dilihat di TurboPuffer
Memang benar RDBMS modern sudah cukup cepat, tetapi use case TigerBeetle adalah lingkungan khusus dengan contention tinggi. Faktanya, melalui pengujian nyata, kami telah menunjukkan bahwa ketika banyak transaksi menyentuh satu akun yang sama, throughput seluruh cluster turun drastis. (Referensi: komentar HN terkait)
Saya sangat menyukai pekerjaan Joran dan tim soal DST, pemahaman distributed systems, dan performance testing, terutama obsesi mereka untuk meminimalkan dependensi sangat mengesankan (meski tentu saja OS juga bisa dianggap sebagai dependensi)
Tetapi saya selalu merasa cara mereka membahas OLTP umum (yang oleh tim disebut OLGP) itu tidak adil. Misalnya, mereka membandingkan hanya kasus transaksi SQL berperforma rendah seperti transaksi finansial yang hanya memakai row locking, lalu menjelaskannya seolah-olah semua orang masih bertahan pada desain OLTP dari 50 tahun lalu
Di halaman performa resmi, contention hanya bisa diturunkan sampai 1%. Saya tidak menganggap tempat seperti Stripe punya 1% contention di OLTP DB mereka
Kita bisa membangun sistem yang memprediksi contention, menanganinya dengan elegan, dan mewujudkan throughput transaksi ekstrem. Sistem seperti ini melindungi DB dari contention sehingga bisa terus diskalakan. Faktanya, angka throughput pada sistem pembayaran skala besar jauh lebih tinggi daripada perbandingan performa resmi itu
Materi marketing mereka cenderung mengabaikan hal-hal ini, dan memperlakukan semua developer seolah hanya melempar transaksi yang naif, padahal kebanyakan adalah engineer yang jauh lebih cerdas. Di industri pembayaran bahkan ada profesi khusus bernama 'payments engineer'
TigerBeetle luar biasa, tetapi pola marketing yang menggiring kesalahpahaman tentang OLTP lain terasa mengganggu
Terima kasih atas pujiannya
Anda mengatakan Stripe tidak punya 1% contention di OLTP DB mereka, tetapi Stripe berbasis MongoDB. Membandingkannya dengan RDBMS itu seperti membandingkan apel dan jeruk
Mengenai apakah underlying OS bisa dianggap sebagai dependensi, saya pernah menangani sistem yang berjalan sepenuhnya in-memory dan tetap bertahan bahkan saat kexec. Dalam situasi di mana syscalls pun tidak bisa dilakukan, OS jelas bisa menjadi dependensi
Saya penasaran apakah Anda bisa memberi contoh transaksi berbasis lock dan pendekatan optimisasi yang menangani pengecekan kondisi pada commit time
Kami sempat mempertimbangkan TigerBeetle, tetapi ada hambatan seperti di bawah ini
Kami menggunakan Cloudflare Workers, dan aplikasi klien TigerBeetle tidak didukung. tautan isu Mungkin bisa di Cloudflare Containers, tetapi workflow kami berpusat pada Workers
Tidak ada fitur autentikasi (auth). Di server (seperti VPS) hanya pembatasan IP yang dimungkinkan, tetapi di lingkungan serverless tidak ada IP tetap isu terkait
Wireguard dengan cara mengautentikasi IP memakai kunci ECC juga bisa menjadi solusi
Faktanya, di lingkungan Cloudflare Workers atau AWS Lambda, jika 1000 worker semuanya membuka koneksi ke DB, masalah akan muncul. Karena itu biasanya diselesaikan dengan menempatkan proxy atau service layer di depan DB. Proxy mengetahui cara mengakses DB, jadi dalam jaringan privat tidak perlu terlalu memikirkan masalah auth
Jika Anda berdiskusi dengan tim solusi TigerBeetle, Anda mungkin akan ditawari solusi kustom seperti autentikasi pada level logis melalui enkripsi end-to-end
Sulit dipercaya ada DB tanpa fitur autentikasi di tahun 2025. Jika ini DB finansial, setidaknya mereka harus memuat panduan di situs tentang cara menambahkan proxy/layer autentikasi. Jika tidak menggunakan HTTP (yang tidak jelas hanya dari dokumentasi), semua orang akan bertanya bagaimana memasang proxy autentikasi tanpa HTTP. Dalam kondisi seperti itu, mengeksposnya ke internet sangat berbahaya
Ada pertanyaan, “Dalam 10 tahun volume transaksi meningkat lebih dari 1000 kali, dan DB yang digunakan adalah SQL berusia 20-30 tahun. Apakah itu bisa bertahan?” Menurut saya sangat bisa.
Walaupun software-nya berusia 30 tahun, ia terus diperbarui dan fondasinya memang dirancang kokoh sejak awal
Saya Joran (TigerBeetle). Untuk workload umum, itu tidak masalah, tetapi dalam pemrosesan transaksi, masalah SQL row lock muncul karena contention yang mengikuti power law (lihat Hukum Amdahl). Kami juga menaruh contention calculator di situs untuk menghitung batas performa maksimum secara teoretis, silakan lihat contetion calculator
DNS juga dirilis pada 1983 dan hingga kini masih menjadi fondasi internet; itu menunjukkan bahwa jika dasarnya bagus, sistem yang berusia lebih dari 30 tahun pun cukup kuat bertahan. SQL cukup baik untuk sebagian besar workload
Tidak selalu teknologi yang baru dan tampak keren lebih baik daripada teknologi lama yang sudah dipakai habis-habisan dan teruji. Kadang rasanya software engineer adalah engineer yang paling ‘pelupa’ di industri
Saat menangani puluhan DB dalam distributed system, distributed transaction (seperti Sagas) memang diperlukan. Tetapi dalam skenario single machine, relational DB tetap sangat bagus
Dulu performa hardware kurang memadai, tetapi sekarang teknologinya sudah maju sehingga justru berjalan lebih cepat dan lebih baik
FoundationDB juga punya banyak kesamaan dengan diskusi tentang TigerBeetle
Penulisan kode yang lambat, DST, tanpa dependensi, distributed environment sebagai default di production, optimistic locking yang menoleransi clock skew, pengujian keras ala Jepsen, pengujian dengan bahasa baru (Flow), dan seterusnya. Dengan FDB, masalah serupa juga bisa diselesaikan, dan saya rasa TigerBeetle hanya lebih dioptimalkan untuk use case tertentu
Satu-satunya alasan FDB tidak populer adalah kurangnya layer yang dibuat dengan baik. Namun, beberapa orang sedang mengembangkan layer untuk SQS, DynamoDB, dan SQLite secara terpisah
Alasan sebenarnya FDB tidak populer adalah Apple. Setelah diluncurkan pada 2013 dan produknya sangat disukai hingga perusahaannya diakuisisi, semua pengguna lama kemudian diputus layanannya. Bahkan setelah masa eksklusif berakhir, kepercayaan tidak pulih kembali
Kami juga sedang menyiapkan posting tentang DST sambil berkolaborasi dengan tim FDB
Saya penasaran bagaimana jadinya setelah akuisisi itu
Saya benar-benar menganggapnya sebagai 'the one true database'
Saya bertanya, “mengapa semua hyperscaler tidak memakai FDB”, lalu setelah mencari di github ternyata memang sudah berada di bawah Apple
Belakangan saya mencoba menerapkan gaya pengembangan TigerBeetle ke Rust, Go, dan lainnya, dan saya benar-benar ingin sangat merekomendasikannya
Single entry point, dependensi yang nyaris nol
CI lokal, menjalankan test/coverage/lint dan sebagainya dengan satu perintah
Jadi tertarik untuk memperkenalkan simulasi dengan property/snapshot/swarm test
Pembedaan cepat/lambat, semua test menggunakan seed secara deterministic
Upper bound yang eksplisit + pengelolaan resource pool, bahkan alokasi dinamis jadi lebih mudah dipahami dalam kode
Semua ini berkat video dan dokumentasi dari tim TB
Bagian “assertion tetap dinyalakan di production” sangat mengesankan
Saya tidak pernah benar-benar paham mengapa assertion dimatikan. Jika assert gagal di production, kita harus langsung tahu (ungkapan retoris)
Secara historis, mematikan assertion memang memberi peningkatan performa. Tetapi sekarang, melakukan beberapa perbandingan tambahan hampir tidak berdampak besar
Pada dasarnya assertion adalah pengecekan untuk mencegah penyalahgunaan API oleh developer. Pada tahap input pengguna, lebih masuk akal mengubahnya menjadi business logic seperti pesan error yang layak
Kadang ada hal yang sulit dicek tetapi tetap ingin dijadikan assertion. Misalnya, memeriksa apakah sebuah daftar sudah terurut
Tujuan asli assertion adalah pengecekan saat compile/test time. Jika ingin dipakai di prod, cukup ubah menjadi pernyataan if. Kita perlu memikirkan apakah assert itu hanya sekadar sintaks gula yang nyaman
Saya berharap tim TB memperkenalkan model double-entry mereka secara lebih luas untuk skenario selain finansial. Ini juga sangat berguna untuk saham, tiket konser, dan sebagainya. Perbaikan API sudah selesai, sekarang waktunya menjelaskan cara memakainya
Saya seorang analis dan banyak memakai SQL, tetapi bukan developer kode. Secara umum saya paham penjelasan gambaran besar dan keuntungan performanya. Saya punya beberapa pertanyaan a) Seperti apa sebenarnya bentuk struktur data TigerBeetle? Rasanya bukan tabel biasa b) Jika tidak bisa memakai query SQL, bagaimana cara menggunakannya c) Jika model double-entry diterapkan ke saham, tiket, dan sebagainya, seperti apa bentuknya? Misalnya sebuah venue memiliki 1000 tiket konser lalu menjual satu; apakah dipindahkan dari inventaris ke kas, dan dari pendapatan ditangguhkan ke kewajiban pelaksanaan? Atau sebelum tiket terjual belum ada entri apa pun?
Implementasi double-entry serupa juga bisa dibuat di Postgres
Pernyataan “kebanyakan tim menulis kode dengan cepat, menganggap pengujian sebagai beban, dan menumpuk banyak dependensi” justru merupakan standar 25 tahun lalu. Sebelum Google dan Facebook memperkenalkan budaya “move fast and break things”, semua orang justru membangun dengan sangat hati-hati, menguji dengan baik, dan mengembangkan secara lambat. Saya berharap TigerBeetle mendapat lebih banyak pengakuan. Laporan Jepsen juga layak dibaca laporan Jepsen
Mari tunggu 25 tahun lagi dan lihat apakah TigerBeetle akan menjadi Google, atau apakah produk yang lambat tetapi sempurna akan dimakan oleh pesaing yang lebih cepat
“Move fast and break things” adalah moto Facebook. Google justru lebih terobsesi pada pengujian. Tentu tetap harus menyesuaikan dengan kebutuhan yang benar-benar ada, dan engineer sering kali menciptakan terlalu banyak kebutuhan hipotetis hingga menyebabkan inefisiensi. Mengirim produk lebih cepat ke pengguna nyata lalu menerima dan menerapkan umpan balik jauh lebih berharga daripada menyempurnakan produk tanpa henti ‘di dalam gelembung’
Terlepas dari isi tulisan di atas, situs web TigerBeetle sendiri juga cukup mengesankan.
Entah bagaimana, situs itu memberi kesan sangat cepat, dan desainnya terasa menyenangkan karena tampak berusaha menyajikan sesuatu yang berat secara teknis dengan cara yang lebih ringan.
Tautan: https://tigerbeetle.com
Koreksi. Setelah saya lihat lagi, memang ada kesan berat. Tapi secara estetika terasa mengesankan, jadi saya bagikan :)
Benar juga. Animasinya cepat, jadi mereka membuat tampilan yang tidak membosankan tanpa mengganggu fokus pada isinya. Dan juga memberi kesan yang sangat kuat bahwa TigerBeetle itu sangat cepat wkwk
Sangat menarik.
Dibandingkan situs pada umumnya, durasi animasinya diatur jauh lebih singkat. Ternyata hal seperti ini juga bisa diuraikan dengan cara seperti ini...