Choosing Your Database — System Design

"Database mana yang harus saya pakai?" adalah salah satu pertanyaan system design paling sering ditanyakan — dan paling sering salah dijawab. Jawaban…

Memilih database artinya mencocokkan bentuk data dan cara data itu dibaca dan ditulis dengan database yang dibuat untuk pola itu. Bayangin menyimpan barang di rumah. Surat-surat penting yang saling merujuk masuk lemari arsip dengan map berlabel. Uang yang diambil puluhan kali sehari ada di dompet. Foto diurutkan per tanggal di album. Pertanyaannya bukan "tempat mana yang paling keren", tapi "barangnya seperti apa, dan bagaimana kamu mengambilnya".

🧪 Tebakan cepat: pickDatabase({ shape: 'keyvalue', writesPerSec: 50000, needsAcidTransactions: false, queryPattern: 'range-scan' }) mengembalikan 'KV', 'TimeSeries', atau 'SQL'? Tebak dulu, jawabannya ada di bagian "Urutan aturan: yang pertama cocok menang".

Empat pertanyaan sebelum memilih

Untuk tiap fitur, jawab empat hal ini dulu. Di latihan, keempatnya jadi properti object workload:

Lima keluarga database

Keluarga Contoh Kuat di Fitur TiketNada
Relational (SQL) PostgreSQL, MySQL JOIN, transaksi ACID, query bebas Pesanan & pembayaran
Document MongoDB isi beda-beda per record, dibaca utuh lewat id Detail konser
Key-value Redis ambil satu nilai lewat key, sangat cepat Sesi login & antrean
Graph Neo4j menelusuri hubungan beberapa langkah "Temanmu juga nonton"
Time-series TimescaleDB, InfluxDB, Prometheus banyak titik data per detik, dibaca per rentang waktu Metrik server per detik

Ada juga search engine seperti Elasticsearch untuk pencarian teks yang tahan salah ketik. Dia hampir selalu berisi salinan data dari database lain, bukan sumber aslinya.

Document atau relational?

Document database lebih tepat saat strukturnya beda-beda per record dan query-nya hampir selalu mengambil lewat key atau field di dalam dokumen, bukan JOIN rumit. Detail konser cocok: konser A punya line-up dan rundown, konser B punya aturan venue dan peta kursi, dan halaman konser selalu membaca satu dokumen utuh.

Kalau datanya saling terhubung (user punya pesanan, pesanan punya kursi) dan butuh transaksi, tetap relational. PostgreSQL juga punya kolom JSONB untuk bagian yang bentuknya bebas, jadi sering kamu gak perlu database kedua.

pickDatabase: aturan berurutan

Latihannya mengubah semua itu jadi aturan yang dicek dari atas. Yang pertama cocok langsung dikembalikan:

function pickDatabase(workload) {
  if (workload.shape === 'timeseries' || (workload.queryPattern === 'range-scan' && workload.writesPerSec > 10000)) {
    return 'TimeSeries';
  }
  if (workload.shape === 'graph' || workload.queryPattern === 'traversal') {
    return 'Graph';
  }
  if (workload.needsAcidTransactions === true || workload.queryPattern === 'joins') {
    return 'SQL';
  }
  if (workload.shape === 'document') {
    return 'Document';
  }
  return 'KV';
}

console.log(pickDatabase({ shape: 'relational', writesPerSec: 50, needsAcidTransactions: true, queryPattern: 'joins' })); // SQL

Lima fitur TiketNada, persis lima baris di latihan:

Fitur shape writesPerSec ACID queryPattern Aturan yang cocok Hasil
Pesanan & pembayaran relational 50 true joins 3 SQL
"Temanmu juga nonton" graph 10 false traversal 2 Graph
Metrik server per detik timeseries 50.000 false range-scan 1 TimeSeries
Detail konser document 200 false lookup 4 Document
Sesi login & antrean keyvalue 1.000 false lookup default KV

Urutan aturan: yang pertama cocok menang

Workload di tebakan tadi bentuknya keyvalue, tapi range-scan dengan 50.000 write per detik masuk lewat jalan kedua aturan 1. Hasilnya 'TimeSeries'. Itu jawaban tebakannya. Dua kasus lain yang dicek latihannya:

Workload Kenapa Hasil
keyvalue, 500 write/s, range-scan 500 gak lebih dari 10.000, jadi aturan 1 lewat; gak ada aturan lain yang cocok KV
graph, 5 write/s, ACID, joins aturan 2 (graph) dan aturan 3 (ACID, joins) sama-sama cocok; aturan 2 dicek duluan Graph

Jadi urutan aturan bagian dari jawabannya. Tukar urutan aturan 2 dan 3, maka hasil kasus kedua berubah jadi SQL.

Polyglot persistence: satu source of truth

Sistem nyata jarang memakai satu database saja. Memakai beberapa database, masing-masing untuk kebutuhannya, disebut polyglot persistence. Stack yang umum, dan yang dipakai TiketNada:

Yang penting: cuma satu source of truth. Database lain berisi salinan yang boleh dibuang dan dibangun ulang.

📌 Database yang membosankan itu bagus

⚠️ Jebakan yang sering ketemu

TL;DR: Pilih database dari bentuk data, pola query, kebutuhan transaksi ACID, dan jumlah write per detik, bukan dari tren. Relational (PostgreSQL) untuk data yang saling terhubung dengan JOIN dan transaksi; document (MongoDB) saat isinya beda-beda per record dan selalu dibaca lewat key; key-value (Redis) untuk ambil satu nilai super cepat; graph (Neo4j) untuk menelusuri hubungan; time-series untuk data berurutan waktu yang ditulis sangat banyak. pickDatabase mengecek aturan dari atas dan yang pertama cocok menang: time-series (atau range-scan di atas 10.000 write per detik), graph (atau traversal), SQL (ACID atau joins), document, lalu default 'KV'. Sistem nyata memakai beberapa database (polyglot persistence) dengan satu source of truth: PostgreSQL untuk pesanan dan user, Redis untuk cache dan session, Elasticsearch untuk pencarian.

Yang akan kamu pelajari