Belajar Microservices - Studi Kasus & Refleksi (tokokita Production)

#Pendahuluan

Inilah episode pamungkas. 27 episode sudah membangun tokokita dari nol: tujuh layanan, event bus, observability, keamanan, testing, CI/CD, scaling, sampai platform. Episode terakhir ini kita mundur satu langkah dan memandang semuanya — arsitektur akhir secara utuh, simulasi skenario kegagalan nyata, keputusan optimasi yang jujur, dan pelajaran yang seharusnya kalian bawa pulang.

Mengapa studi kasus & refleksi penting? Karena setelah semua pola dipelajari terpisah-pisah, di sinilah kalian melihat bagaimana mereka bekerja sama saat produksi berbicara — dan kapan kita sebaiknya berhenti memecah sesuatu.

#Recap Arsitektur Final

Satu alur user: register → email selamat datang → login → browse → add to cart → checkout → bayar → status PAID → email bukti pembayaran.

• Stateless flow (gateway, product, cart) diskalakan dengan HPA.
• Worker (notification) diskalakan dengan KEDA dari consumer lag.
• Data: database per service + Redis cache/session + read model ter-denormalisasi.
• Reliability: outbox, saga + kompensasi, idempotency, circuit breaker, dedup.
• Keamanan: JWT di gateway, mTLS/internal token antar service, zero trust NetworkPolicy, secrets via External Secrets.
• Observability: trace, metric, log (Prometheus/Grafana/Tempo/Loki).
• Delivery: CI per service (path-filtering), GitOps Argo CD, canary + auto-rollback.

#Skenario Simulasi: Bagaimana Sistem Bertahan

#Skenario 1: Payment-Service Down

Saat payment-service mati:

1. User checkout → order mencapai CONFIRMED (stok sudah di-reserve).
2. Publish order.confirmed ke Kafka — seluruh event di-buffer oleh event bus; tidak ada yang hilang.
3. Payment-service kembali hidup → konsumen membaca event tertunda → proses pembayaran → payment.succeeded.
4. Notification mengantre di outbox & consumer lag — semuanya mengejar.

order CONFIRMED → (payment down, event mengendap di Kafka)
  → payment up → consume backlog → bayar → order PAID → email bukti
lewati 30 menit? → timeout saga (episode 13) membatalkan & me-release stok

Pelajaran: event bus + outbox adalah buffer kegagalan bawaan. Sistem tidak crash — ia melambat dan mengejar. Tidak perlu panik-reboot.

#Skenario 2: Kafka Down

1. Producer (order-service) gagal publish → relay outbox tidak mendapat konfirmasi → baris outbox tetap pending.
2. Relay mencoba ulang (retry + backoff) sampai broker kembali.
3. Setelah Kafka pulih, relay mencairkan antrean — tidak ada event hilang, hanya terlambat.

Pelajaran: transactional outbox (episode 12) mengubah "Kafka down" dari insiden data-hilang menjadi insiden delay terkendali. Tanpa outbox, skenario ini adalah pemadaman senyap.

#Skenario 3: Deploy Canary Bermasalah

GitOps merilis canary 5% untuk order-service v1.4.4:

1. Error rate canary melonjak (regresi validasi stok).
2. Auto-rollback menarik revisi (episode 26) → traffic balik ke v1.4.3.
3. Trace dari jendela kegagalan siap dibuka untuk analisis root cause (episode 20).

Pelajaran: canary + metric gate + auto-rollback membuat regresi jadi insiden kecil yang terukur, bukan downtime besar.

#Optimasi yang Jujur

Kita tidak menutup-tutupi: arsitektur tokokita bisa lebih kecil.

• Gabung cart + order bila memungkinkan. Cart dan order adalah alur pembelian yang berurutan dan sering dipegang tim yang sama. Read/write cart yang sederhana bisa disatukan ke order-service menjadi satu domain pembelian dengan satu database + satu pipeline — hemat satu set pod, pipeline, dan dashboard tanpa merusak boundary payment/product.
• Reuse product read model — katalog yang sudah ter-denormalisasi (episode 14) cukup dipakai cart (harga snapshot) dan order (nama/harga) — tidak perlu query live product-service di tiap halaman.
• Tetap pisahkan payment (finansial, SLO ketat) dan notification (worker, boleh toleran) — domainnya beda, perilaku skala-nya beda, SLO-nya beda.

#Pelajaran & Roadmap

#Kapan Microservices (Benar-Benar) Layak

Refleksi jujur dari seluruh series:

PERTIMBANGKAN microservices saat:
  - volume traffic membuat skala selektif benar-benar perlu
  - 3+ tim dengan domain yang jelas berbeda
  - kebutuhan deploy independen nyata
MULAI dari modular monolith (episode 1) kecuali ada alasan di atas

Microservices dengan satu tim kecil dan traffic kecil tetap bisa, tapi kalian membayar kompleksitas (jaringan, observability 7x, deploy 7x) tanpa menikmati manfaatnya. Series ini mengajarkan keterampilan mengambil keputusan itu, bukan hanya menulis manifest.

#Teknologi Berikutnya untuk Dijajal

• Next.js full-stack module — modular monolith modern untuk tim kecil; batas module jelas, satu deploy, satu database.
• Dapr workflow — ubah saga choreography (episode 13) menjadi orchestrasi deklaratif di atas runtime building blocks Dapr (episode 25): state per step, retry, dan timeout menjadi milik runtime.
• Dapr + actor untuk agregat yang butuh concurrency ketat (misal inventory) bila diperlukan.

#Penutup

Sampai di akhir perjalanan, mari kita rekap apa yang sudah dibangun:

• Fase 1 (0-2): setup environment, sejarah, dan empat pilar arsitektur (bounded context, database per service, gateway/BFF, sinkron vs asinkron).
• Fase 2 (3-10): tujuh layanan tokokita + gateway + web, dengan satu alur end-to-end utuh.
• Fase 3 (11-15): REST/gRPC, Kafka + outbox, saga, CQRS/read model, cache & konsistensi.
• Fase 4 (16-19): Docker/K8s networking, service mesh & mTLS, zero trust, platform security.
• Fase 5 (20-23): OpenTelemetry, scaling HPA/KEDA, testing piramida, CI/CD & GitOps.
• Fase 6 (24-27): production checklist, Dapr, platform engineering & AIOps, dan refleksi ini.

Satu hal yang ingin selalu kalian ingat: microservices adalah keputusan arsitektur yang menjawab masalah organisasi dan volume — bukan tren, dan bukan lawan dari monolith. Mulai dari modular monolith, pecah dengan disiplin bounded context, dan jadikan event-driven serta observability sebagai bahasa pertama kalian. Terima kasih sudah menemani 28 episode Belajar Microservices — sampai jumpa di seri berikutnya, dan tetap semangat membangun!