Belajar System Design - Database Fundamentals untuk Scale

#Pendahuluan

Setelah di episode 3 kita memahami caching strategies, pada episode ini kita masuk ke komponen paling kritis dalam hampir semua sistem: database. Database menentukan bagaimana data disimpan, diakses, dan di-scale. Keputusan database yang salah bisa membuat sistem tidak bisa scale; keputusan yang tepat bisa menghemat bulan-bulan perbaikan.

Pertanyaan paling umum dalam system design: "SQL atau NoSQL?" Jawabannya bukan "selalu SQL" atau "selalu NoSQL" — tapi "tergantung requirement." Di episode ini kita bedah keduanya secara mendalam, termasuk replikasi dan sharding yang membuat database bisa menangani traffic masif.

#SQL vs NoSQL

#Relational Database (SQL)

PostgreSQL, MySQL, MariaDB — database berbasis tabel dengan schema yang didefinisikan sebelumnya.

CREATE TABLE users (
    id SERIAL PRIMARY KEY,
    name VARCHAR(100) NOT NULL,
    email VARCHAR(255) UNIQUE NOT NULL,
    created_at TIMESTAMP DEFAULT NOW()
);
 
CREATE TABLE orders (
    id SERIAL PRIMARY KEY,
    user_id INTEGER REFERENCES users(id),
    total DECIMAL(10,2),
    status VARCHAR(20) DEFAULT 'pending'
);

Kelebihan:

• ACID (Atomicity, Consistency, Isolation, Durability) — data integrity terjamin.
• JOIN — relasi antar tabel ditangani secara native.
• Schema enforcement — data tidak bisa corrupt karena invalid type.
• Mature ecosystem — tool, backup, monitoring, driver semuanya mature.

Kekurangan:

• Schema rigidity — perubahan schema memerlukan migration.
• Horizontal scaling sulit — sharding relational database kompleks.
• Write throughput terbatas — single leader untuk writes.

#Document Database (NoSQL)

MongoDB, DynamoDB, CouchDB — data disimpan sebagai dokumen (JSON/BSON).

{
  "_id": "user1234",
  "name": "Budi",
  "email": "budi@example.com",
  "orders": [
    {"id": "order1", "total": 150000, "status": "delivered"},
    {"id": "order2", "total": 75000, "status": "pending"}
  ]
}

Kelebihan:

• Schema-flexible — field bisa berbeda antar dokumen.
• Horizontal scaling mudah — sharding built-in (MongoDB, DynamoDB).
• Deklarasi relasi — embedded documents untuk data yang sering diakses bersama.

Kekurangan:

• Tidak ada JOIN native — relasi harus di-handle di aplikasi (N+1 problem).
• Duplikasi data — embedded documents menyebabkan data redundancy.
• Konsistensi lemah — beberapa database NoSQL default ke eventual consistency.

#Key-Value Store

Redis, DynamoDB, etcd — interface paling sederhana: GET(key), SET(key, value).

Kapan pakai: session store, caching, rate limiting, feature flags. Simple dan sangat cepat (sub-millisecond latency).

#Wide-Column Store

Cassandra, ScyllaDB, HBase — seperti relational tapi column bisa dinamis per row.

Kapan pakai: time-series data, logging, write-heavy workload yang butuh horizontal scale. Cassandra dipakai oleh Instagram, Apple, Netflix.

#Time-Series Database

InfluxDB, TimescaleDB, Prometheus — dioptimasi untuk data timestamped.

Kapan pakai: metrics, IoT sensor data, monitoring, logging.

#Kapan Pakai Mana

#Replikasi: Leader-Follower

Replikasi artinya menyimpan copy data di beberapa server untuk redundancy dan read scaling.

#Synchronous vs Asynchronous

#Replication Lag

Pada asynchronous replication, ada delay antara write ke leader dan propagasi ke follower. Dampaknya:

1. User A write "name = Budi" ke leader
2. Leader propagate ke follower (delay 100ms)
3. Dalam 100ms itu, User B read dari follower → dapat "name = Ani" (lama)
4. User B bingung: baru update tapi masih dapat data lama

Solusi: read-after-write consistency — setelah write, baca dari leader untuk N detik berikutnya.

#Partitioning/Sharding

Sharding artinya memecah database menjadi beberapa partisi (shard) yang masing-masing menyimpan sebagian data.

#Hash-Based Sharding

Hash dari shard key menentukan shard tujuan.

Shard key: user_id
shard = hash(user_id) % number_of_shards
 
user_id=1 → hash(1) % 4 = 1 → Shard 1
user_id=2 → hash(2) % 4 = 3 → Shard 3
user_id=3 → hash(3) % 4 = 2 → Shard 2
user_id=4 → hash(4) % 4 = 0 → Shard 0

Kelebihan: distribution merata. Kekurangan: range query sulit (data tersebar di semua shard).

#Range-Based Sharding

Berdasarkan range dari shard key.

Shard key: user_id
Shard 0: user_id 1-1000
Shard 1: user_id 1001-2000
Shard 2: user_id 2001-3000

Kelebihan: range query efisien. Kekurangan: hotspot (semua write baru ke shard terakhir).

#Shard Key Selection

Pemilihan shard key adalah keputusan kritis — ia menentukan distribusi data dan query pattern.

#Praktik: Bandingkan Desain Tabel Produk

#PostgreSQL (E-commerce)

CREATE TABLE products (
    id SERIAL PRIMARY KEY,
    name VARCHAR(255),
    category_id INTEGER REFERENCES categories(id),
    price DECIMAL(10,2),
    stock INTEGER DEFAULT 0
);
 
CREATE TABLE categories (
    id SERIAL PRIMARY KEY,
    name VARCHAR(100)
);
 
-- Query dengan JOIN
SELECT p.name, c.name as category, p.price
FROM products p
JOIN categories c ON p.category_id = c.id;

#MongoDB (E-commerce)

{
  "_id": "product1234",
  "name": "Laptop ASUS",
  "category": {"id": "cat1", "name": "Electronics"},
  "price": 12000000,
  "stock": 50
}

#Kapan Sharding Diperlukan

• Database mencapai storage limit satu mesin.
• Write throughput melebihi kapasitas satu leader.
• Query latency meningkat karena ukuran data.
• Geographic distribution data diperlukan.

Di episode 13 kita bedah sharding lebih dalam: resharding, cross-shard query, dan distributed transactions.

#Penutup

Inti yang harus dibawa pulang:

• SQL untuk ACID, JOIN, dan data integrity; NoSQL untuk flexibility, horizontal scale, dan write throughput.
• Replikasi leader-follower: sync konsisten tapi lambat, async cepat tapi eventual, semi-sync balance.
• Sharding: hash-based merata tapi hard range query, range-based efisien tapi hotspot risk.
• Shard key selection adalah keputusan kritis — analisis query pattern sebelum memilih.

Di episode 5 selanjutnya kita akan membahas database deep dive: indexing & optimization — B-Tree, LSM-Tree, EXPLAIN ANALYZE, dan cara optimasi query lambat di PostgreSQL. Database yang sudah di-shard pun tetap butuh indexing yang tepat untuk performa optimal!