Belajar Microservices - Saga Pattern (Order → Payment → Inventory)

#Pendahuluan

Episode 12 memberi kita outbox — event tidak bisa hilang lagi. Tapi ada masalah yang belum terselesaikan: transaksi lintas layanan. Saat checkout, "sukses" berarti reserve stok di product-service ✓, buat order di order-service ✓, dan bayar di payment-service ✓ — tiga database berbeda. Tidak ada database yang bisa meng-commit ketiganya sekaligus. ACID satu database mustahil di sini.

Jawabannya bukan distributed transaction berat (2PC), melainkan saga: rangkaian transaksi lokal yang dihubungkan, dengan kompensasinya masing-masing. Episode ini membangun pola yang sudah lewat sekilas berkali-kali — sekarang kita formalisasi.

#Mengapa Tidak 2PC?

Two-Phase Commit (2PC) — prepare semua, commit semua — sering dipakai di SOA. Pada microservices ia tidak disukai: semua node harus hidup & merespons dalam jendela waktu; satu databse lambat menahan seluruh transaksi; dan dalam sistem terdistribusi ada kegagalan yang tak terduga (partisi jaringan) yang bisa membuat 2PC terkunci. Saga menerima kenyataan: eventual consistency dengan kompensasi eksplisit.

#Saga: Definisi dan Bentuknya

Saga adalah urutan transaksi lokal T1...Tn di mana tiap Ti punya kompensasi Ci untuk membatalkan efeknya. Dua gaya utama:

#Choreography: Event-Chain Tanpa Orkestra

Tiap layanan mengonsumsi event, mengerjakan bagiannya, lalu mempublish event lanjutan. Yang dipakai tokokita:

Kelebihan: sangat decoupled, tidak ada service yang "mengatur" yang lain. Kekurangan: alur tersebar di banyak konsumen — sulit dilacak "sampai mana transaksi ini?" tanpa log lintas service; satu consumer salah, rantai berhenti diam-diam.

#Orchestration: Orkestrator Memimpin

Satu orchestrator (biasanya order-service) yang mencatat step, memanggil/event-kan ke layanan lain, dan menangani kompensasi terpusat. Kelebihan: alur jelas, transisi bisa diaudit. Kekurangan: orchestrator bisa jadi bottleneck & monolith kedua bila menampung logika semua langkah.

#Compensating Transactions di tokokita

Aturan emas saga: setiap langkah harus punya kompensasi. Inventaris kompensasi tokokita:

Contoh alur "gagal bayar" di choreography:

order.confirmed
  → payment-service charge → FAILED
payment.failed
  → order-service: CONFIRMED → CANCELLED  (emit order.cancelled)
  → product-service: me-release stok (dari order.cancelled)
  → notification-service: kirim "pembayaran gagal, order dibatalkan"

Keadaan akhirnya konsisten: order CANCELLED di DB order, stok kembali utuh di DB product, user ter-notifikasi. Tanpa transaksi bersama, semuanya terjadi sebagai rantai event — eventual consistency yang dalam jangka pendek masih bisa berbeda (stok belum turun?) tapi selamanya konvergen.

#Implementasi: State per Step + Timeout

Order-service mencatat posisi saga dengan status + event log. Status sudah kita punya; tambahkan log langkah (saga step log) agar bisa di-audit dan direcovery:

create table saga_log (
  id bigserial primary key,
  order_id uuid not null,
  step text not null,          -- RESERVE_STOCK / CREATE_PAYMENT / ...
  status text not null,        -- STARTED / SUCCEEDED / COMPENSATED
  created_at timestamptz not null default now()
);

Dan timeout rules — bagian yang sering terlupakan. Order yang menunggu pembayaran terlalu lama (misal 30 menit) harus otomatis dibatalkan dan stok dilepas. Di Kafka, timeout bisa di-handle dengan event ber-schedule (episode 21 membahas timeline/watermarks) atau consumer yang memeriksa updated_at:

update orders
set status = 'CANCELLED', updated_at = now()
where status in ('CREATED','CONFIRMED')
  and updated_at < now() - interval '30 minutes'
returning *;
— lalu emit order.cancelled untuk mengompensasi product-service

#Penutup

Episode 13 menuntaskan persoalan konsistensi lintas layanan:

• Transaksi lintas layanan tidak bisa ACID → saga + eventual consistency; 2PC dihindari.
• Choreography (event-chain) dipakai tokokita untuk alur lurus; orchestration untuk yang butuh kontrol terpusat.
• Compensating transactions: payment.failed → order CANCELLED + product.release.
• Implementasi: status + saga_log di order-service, timeout rules untuk menutup order menggantung.
• Konvergen: dalam jangka pendek berbeda, selamanya konsisten.

Di episode 14 selanjutnya, kita akan memecahkan masalah query lintas layanan dengan CQRS, read models, dan query pattern — memisahkan command dari query, membangun read model product yang sudah termasuk rating dan harga, API composition di gateway, serta catatan kapan event sourcing layak dipakai. Sampai jumpa di episode 14!