Belajar Microservices - CQRS, Read Models & Query Pattern

#Pendahuluan

Sampai episode 13, kita memusatkan energi pada sisi write sistem: menulis order, memvalidasi stok, memproses pembayaran. Sekarang giliran sisi yang sering diremehkan: membaca data. Di microservices, membaca itu sulit dengan cara yang tidak biasa — data terpecah di banyak layanan, dan join lintas layanan dilarang (database per service, episode 2).

Mengapa episode ini penting? Karena di e-commerce, permintaan baca jauh melebihi tulis — bisa 20:1. Kalau membaca mahal (banyak join, query berat, panggilan berantai), pengalaman user hancur walau sistem menulisnya sempurna. CQRS dan read model adalah jawaban arsitekturalnya.

#Masalah Query di Microservices

Data domain tersebar. Halaman "Rekomendasi produk" butuh: produk (product-service), harga dan stok (product-service), rating (layanan review), dan mungkin riwayat pembelian (order-service). Tidak ada satu database yang menyimpan semuanya, dan kita tidak boleh JOIN lintas schema.

Masalah tambahan: model write dibentuk untuk integritas (normalisasi, constraint), sementara model read butuh kecepatan (denormalisasi, cache).

Halaman Detail Produk =
  produk (product-service)
  + rating & ulasan (rating-service)
  + stok real-time (product-service/inventory)
  → join lintas layanan? Dilarang (episode 2)

#CQRS: Command dan Query Dipisah

CQRS (Command Query Responsibility Segregation) memisahkan model yang mengubah data (command) dari model yang membaca (query):

• Command side: POST /orders, PATCH /products/:id — model ternormalisasi, validasi ketat, transaksi. Satu jalan masuk write per layanan.
• Query side: GET /products?sort=... — model ter-denormalisasi, bebas di-cache, layanan baca bisa terpisah (read replica atau store khusus).

CQRS tidak mengharuskan teknologi berbeda — cukup mindset dan endpoint berbeda. Tahap awal tokokita tidak butuh database terpisah untuk read model; cukup cache Redis + query yang dioptimalkan. Baru saat beban query melonjak, kita pisahkan read store.

#Read Model / Denormalisasi

Read model adalah representasi data yang dibentuk khusus untuk query. Idenya: bangun sekali lewat event, simpan dalam bentuk siap-baca, lalu layani jutaan pembaca tanpa nanya ke pemilik data.

Contoh nyata di tokokita: halaman katalog Butuh produk + rating + stok dalam satu tampilan. Kita bangun read model product_catalog yang dikonsumsi dari event dan dicache di Redis:

product.updated ──┐                ┌── read model product_catalog
rating.updated ────→ [projector] →─┤   { product_id, name, price,
stock.changed ────┘                │     rating, stock, image_key }
                                   └──→ Redis / PG read replica

Projector (konsumen event) menjaga read model tetap segar. Ini adalah kompensasi yang adil untuk larangan join: data diduplikasi dengan sengaja, selalu di-update via event.

consume('product-events', 'catalog-projector-group', {
  'product.updated': async (e) =>
    db.query(
      `insert into catalog (product_id, name, price, image_key)
       values ($1,$2,$3,$4)
       on conflict (product_id)
       do update set name = excluded.name, price = excluded.price`,
      [e.data.id, e.data.name, e.data.price, e.data.imageKey]
    ),
  'rating.updated': async (e) =>
    db.query('update catalog set rating = $1 where product_id = $2', [e.data.rating, e.data.id]),
})

Query katalog lalu membaca catalog dengan join lokal penuh — cepat, tanpa panggilan lintas layanan. Trade-off: read model bisa tertinggal sesaat setelah write (eventual consistency) — diterima untuk katalog.

#API Composition

Saat read model belum ada (atau untuk halaman yang menggabungkan data sangat dinamis), gunakan API composition: gateway atau layanan agregator memanggil beberapa layanan dan menggabungkan hasil — yang sudah kita buat di episode 10 untuk detail produk.

Kapan memilih mana:

#Event Sourcing (Opsional, dan Catatan Khusus)

Event sourcing menyimpan event sebagai source of truth, bukan state saat ini. State hanyalah proyeksi dari event. Keuntungan: audit lengkap, bisa replay, history utuh. Tapi biayanya nyata: model mental baru, event schema harus immutable, event store berukuran besar, dan query perlu proyeksi.

State DB:  orders(id, status='PAID')
Event DB:  order.created → order.confirmed → payment.succeeded → order.paid
           (state PAID adalah proyeksi dari deret event ini)

Untuk learner awal, event sourcing tidak disarankan sebagai default. Outbox (episode 12) sudah memberi jalur event yang solid tanpa mengorbankan kebiasaan berpikir state-based. Bahkan tim senior memakai event sourcing hanya untuk agregat tertentu (misal akun keuangan, wallet) di mana history tak ternilai — bukan untuk semua data.

#Penutup

Episode 14 menuntaskan sisi baca microservices:

• Masalah read di microservices: data tersebar, join lintas layanan dilarang.
• CQRS: command side (write ketat) vs query side (read cepat) — mindset + endpoint berbeda.
• Read model ter-denormalisasi dibangun oleh projector via event; boleh duplikat & tertinggal sesaat, tapi tidak boleh jadi sumber kebenaran untuk write.
• API composition di gateway untuk halaman dinamis; pilih sesuai frekuensi baca.
• Event sourcing: powerful tapi berat — catatan: mulai dari agregat kecil, jangan default.

Di episode 15 selanjutnya, kita membahas cache, session, dan distribusi — lapisan Redis untuk cache-aside dan invalidation via event, perbandingan distributed session vs JWT (access pendek + refresh rotate + blacklist), menerima eventual consistency untuk keranjang, serta validasi stok benar saat checkout. Sampai jumpa di episode 15!