Belajar Backend Developer - NoSQL & Pilihan Database

#Pendahuluan

Setelah di episode 5 kalian membangun skema relasional yang solid, sekarang saatnya melihat sisi lain: database NoSQL. Pertanyaan "relasional atau NoSQL?" adalah salah satu keputusan arsitektur paling umum di dunia backend — dan jawabannya hampir selalu "tergantung". Episodi 5-6 harus dibaca berpasangan: bukan untuk memilih "pemenang", melainkan untuk memahami kapan setiap database adalah alat yang tepat.

Mengapa ini penting? Karena data punya bentuk dan kebutuhan yang berbeda. Data transaksi keuangan butuh konsistensi ketat (relasional); data session login butuh akses secepat kilat (key-value); data katalog produk dengan skema yang sering berubah bisa nyaman di document store. Backend developer yang baik adalah yang tahu kapan memakai database mana.

#Keluarga NoSQL

"NoSQL" bukan satu jenis database — ia payung untuk banyak model:

#Document Store: MongoDB

MongoDB menyimpan data sebagai dokumen JSON dalam koleksi. Alih-alih tabel dengan kolom tetap, tiap dokumen bisa punya struktur yang sedikit berbeda:

Dokumen produk di MongoDB

{
  "name": "Keyboard Mechanical",
  "price": 750000,
  "category": "accessories",
  "specs": { "switch": "red", "layout": "65%" },
  "variants": [
    { "color": "black", "stock": 20 },
    { "color": "white", "stock": 5 }
  ]
}

Perhatikan specs dan variants yang bersarang — di PostgreSQL ini butuh tabel tambahan dan join; di document store tersimpan alami. Kapan MongoDB cocok?

• Skema berubah cepat dan tidak terdefinisi ketat di awal.
• Data dibaca sebagai satu dokumen utuh (bukan dipecah di banyak tabel).
• Perlu horizontal scaling bawaan (sharding) sejak awal.

Tapi ada trade-off penting: tidak ada JOIN native (denormalisasi manual), dan konsistensi transaksi multi-dokumen baru bisa setelah MongoDB 4.0 — tetap lebih lemah daripada relational untuk domain yang sensitif.

#Query di MongoDB

Query MongoDB - Node.js driver

const products = await db.collection("products").find({
  price: { $gt: 500000 },
}).sort({ price: -1 }).limit(10).toArray()

#Key-value: Redis

Redis adalah database in-memory — data tinggal di RAM sehingga aksesnya mikrodetik. Dua kasus paling umum di backend:

#Cache

docker exec -it redis-lab redis-cli
redis-cli> SET product:42 '{"id":42,"name":"Keyboard","price":750000}' EX 300
redis-cli> GET product:42

EX 300 memberi TTL 300 detik — data otomatis hilang. Pola cache ini menjadi dasar episode 9.

#Counter dan Session

redis-cli> INCR login:user:5:attempts
redis-cli> EXPIRE login:user:5:attempts 900

INCR adalah operasi atomik — aman dari race condition, persis yang kita butuhkan untuk menghitung percobaan login per menit (episode 20).

#Relasional vs NoSQL: Kerangka Keputusan

Tanyakan lima hal ini saat memilih database:

#1. Seberapa Kritis Konsistensi Data?

Order, saldo, pembayaran → relational (ACID). Ini bukan wilayah NoSQL kecuali dengan pengorbanan besar.

#2. Bagaimana Data Dibaca?

Satu objek utuh yang dinikmati apa adanya (profil, konten) → document store. Data yang dipecah dan digabung dengan berbagai cara → relational.

#3. Bagaimana Skema Berubah?

Skema berubah tiap minggu tanpa migration berat → document store fleksibel. Skema stabil dan jadi kontrak → relational lebih aman.

#4. Seberapa Besar Traffic Baca?

Baca masif dengan latency mikrodetik → Redis/DynamoDB. Baca normal dengan konsistensi → relational + cache.

#5. Bagaimana Skalanya?

Satu node utama dengan replika → relational biasa. Scale-out horizontal sejak awal → NoSQL (MongoDB, Cassandra).

#Praktik: Pilih Database untuk Kasus Nyata

#Kasus 1: Transaksi pembayaran

PostgreSQL. Setiap sen harus akurat, audit lengkap, dan atomic — relational dengan ACID adalah pilihan wajib.

#Kasus 2: Keranjang belanja user

Redis (key-value). Akses cepat, TTL untuk keranjang yang ditinggalkan, struktur hash untuk item: HSET cart:5 item:1 2. Keranjang tidak butuh query kompleks.

#Kasus 3: Katalog produk yang berubah cepat

MongoDB. Produk punya field opsional, variant, dan spesifikasi yang berbeda per kategori — document store sangat nyaman tanpa migration.

#Kasus 4: Leaderboard game real-time

Redis Sorted Set — ZINCRBY leaderboard 5 user:42 memberi ranking terurut dengan performa luar biasa.

#Common Pitfalls

#NoSQL sebagai Jawaban atas Segalanya

Memindahkan semua data ke MongoDB karena "lebih cepat" justru melahirkan data tidak konsisten. Database bukan PR — pilih berdasarkan kebutuhan data, bukan tren.

#Mengira Cache dan Database adalah Hal yang Sama

Redis tidak menggantikan PostgreSQL — ia lapisan di depan untuk kecepatan. Saat Redis kosong (cold start), database tetap harus bisa melayani. Episode 9 membahas pola ini.

#Denormalisasi Tanpa Rencana

Denormalisasi di document store mempercepat baca tapi menyulitkan update (data diduplikasi di banyak tempat). Sebelum denormalisasi, tanyakan: seberapa sering field ini berubah?

#Penutup

Episode 6 memetakan dunia NoSQL: document store (MongoDB) untuk data fleksibel, key-value (Redis) untuk kecepatan ekstrem, plus column-family dan graph, dengan kerangka keputusan lima pertanyaan dan praktik memilih database per kasus.

Inti yang harus dibawa pulang:

• NoSQL adalah payung untuk banyak model — document, key-value, column, graph.
• MongoDB cocok untuk skema fleksibel dan baca utuh; Redis untuk akses mikrodetik.
• Data uang dan transaksi tetap milik relational (ACID).
• Sistem sehat biasanya memakai keduanya: relational untuk data inti, NoSQL untuk kebutuhan spesifik.
• Pilih database berdasarkan cara data dibaca dan seberapa kritis konsistensinya.

Di episode 7 selanjutnya kita akan mengamankan akses: authentication & authorization — session dan JWT, OAuth2/OIDC, RBAC, dan keamanan password, lengkap dengan implementasi end-to-end. Sampai jumpa di episode 7!