Lewati ke konten utama
menjadi.dev
Chapter 10.4 Architecture Spesialisasi

Database per Service & Event Sourcing

Tiap service punya database sendiri

Tujuan Pembelajaran

  • Memahami database per service pattern
  • Bisa menggunakan event sourcing

Analogi

Diagram

      Monolith = 1 Gudang Besar (semua barang campur)
Microservices = Tiap Toko punya Gudang Sendiri

Event Sourcing = Buku Jurnal (catat semua transaksi,
bisa rebuild history)
    

Tiap service punya database sendiri — tidak sharing database

Penjelasan Konsep

Database per Service

Database per Service adalah aturan emas dalam microservices. Tiap service punya database sendiri dan tidak boleh mengakses database service lain langsung.

Kenapa tidak sharing database?

  1. Independence — Service bisa ganti tech stack database.
  2. Scaling — Scale database sesuai kebutuhan service.
  3. Failure isolation — DB satu service down tidak affect service lain.
  4. Schema evolution — Ganti schema tanpa affect service lain.

Event Sourcing

Simpan setiap perubahan sebagai event, bukan hanya state terakhir. Semua event disimpan dalam event store. State saat ini bisa di-rebuild dengan replay semua event.

CQRS

Separate read dan write model. Command mengubah state, Query membaca optimized view.

Inti yang Perlu Dipahami

Bagian ini berfokus pada memahami database per service pattern., dan bisa menggunakan event sourcing. Jangan terburu-buru menghafal istilahnya. Lebih penting untuk memahami peran setiap konsep dan kapan konsep itu muncul dalam pekerjaan web development.

Saat membaca Database per Service & Event Sourcing, gunakan tujuan belajar sebagai penanda arah. Kalau kamu sudah bisa menjelaskan tujuan itu dengan kata-katamu sendiri, berarti fondasinya mulai terbentuk.

Cara Membayangkannya

Tiap service punya database sendiri — tidak sharing database. Analogi ini dipakai supaya konsep teknis tidak terasa melayang. Hubungkan setiap istilah dengan perannya: siapa yang meminta, siapa yang memproses, data apa yang berpindah, dan hasil apa yang diharapkan.

Kalau analoginya sudah terasa masuk akal, barulah lihat istilah teknisnya. Cara ini membuat materi lebih mudah dipahami daripada langsung menghafal definisi.

Saat Melihat Contoh Kode

Contoh kode pada chapter ini memakai bahasa sql. Bacalah contoh kode sebagai ilustrasi alur, bukan sebagai bagian yang harus langsung dihafal. Tiap service DB terpisah. Event store catat semua perubahan sebagai event.

Perhatikan nama fungsi, urutan langkah, dan data yang berpindah. Biasanya tiga hal itu sudah cukup untuk memahami hubungan antara teori dan praktik.

Konteks dalam Perjalanan Belajar

Setiap konsep di platform ini dipilih karena dipakai di industri. Fokus pada pemahaman, bukan hafalan.

Kamu sudah di bagian lanjutan. Mulai pikirkan bagaimana konsep ini dipakai di dunia kerja — bukan hanya untuk belajar, tapi untuk membangun produk nyata.

Gunakan pertanyaan reflektif dan prompt AI di akhir chapter sebagai latihan aktif. Membaca saja tidak cukup — kamu perlu menjelaskan ulang dengan kata-katamu sendiri.

Contoh Kode

sql
// USER SERVICEDATABASE SENDIRI
// user-service/db/schema.sql
CREATE TABLE users (
  id UUID PRIMARY KEY,
  email VARCHAR(255) UNIQUE,
  name VARCHAR(255)
);

// ORDER SERVICEDATABASE SENDIRI
// order-service/db/schema.sql
CREATE TABLE orders (
  id UUID PRIMARY KEY,
  user_id UUID,      -- referensi, bukan FK
  total DECIMAL(10,2),
  status VARCHAR(50)
);

// EVENT Sourcing EXAMPLE
// Event Store
CREATE TABLE events (
  id SERIAL PRIMARY KEY,
  aggregate_id UUID,
  type VARCHAR(100),   -- 'OrderCreated', 'PaymentReceived'
  payload JSONB,
  created_at TIMESTAMP
);

Penjelasan Kode

Tiap service DB terpisah. Event store catat semua perubahan sebagai event.

Prompt AI

Jelaskan kenapa microservices tidak boleh sharing database.

Pertanyaan Reflektif

Design database schema untuk 3 microservices yang tidak sharing database.