Database per Service & Event Sourcing
Tiap service punya database sendiri
Tujuan Pembelajaran
- Memahami database per service pattern
- Bisa menggunakan event sourcing
Analogi
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?
- Independence — Service bisa ganti tech stack database.
- Scaling — Scale database sesuai kebutuhan service.
- Failure isolation — DB satu service down tidak affect service lain.
- 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
// USER SERVICE — DATABASE SENDIRI
// user-service/db/schema.sql
CREATE TABLE users (
id UUID PRIMARY KEY,
email VARCHAR(255) UNIQUE,
name VARCHAR(255)
);
// ORDER SERVICE — DATABASE 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
Prompt AI
Jelaskan kenapa microservices tidak boleh sharing database.
Pertanyaan Reflektif
Design database schema untuk 3 microservices yang tidak sharing database.