Belajar Cloud Architect - Microservices & Event-Driven
Microservices menjanjikan skalabilitas dan kecepatan rilis, tetapi dibayar dengan kompleksitas operasional. Episode ini membahas cara menentukan batas service, pola event-driven dengan queue dan stream, serta saga pattern untuk transaksi lintas-service yang konsisten
#Pendahuluan
Di episode 3 kita membahas trade-off monolith vs microservices dan menyimpulkan: mulai dari monolith, pisah saat benar-benar butuh. Episode ini membahas bagaimana memisahkannya dengan benar — karena microservices yang salah dipecah justru menghasilkan "distributed monolith": kompleksitas microservices tanpa benefitnya.
Kunci microservices bukan jumlah service, melainkan batas yang benar (boundaries) dan komunikasi yang asinkron. Episode ini membahas keduanya, ditutup dengan saga pattern — cara menjaga konsistensi data ketika transaksi membentang banyak service.
#Menentukan Batas Microservices
#Batas dari Domain, Bukan Teknis
Cara terbaik memecah service adalah berdasarkan domain bisnis — lewat pendekatan Domain-Driven Design (DDD). Setiap service memegang satu domain yang kohesif: orders, payments, inventory, users. Aturannya sederhana:
- Satu service = satu domain — bukan "semua yang pakai database", bukan "semua yang Java".
- Data lokal — setiap service memiliki database sendiri; tidak ada service yang membaca database service lain.
- Komunikasi via API/event — bukan database bersama, bukan memanggil method internal.
BENAR:
orders-service (domain: order, data: orders DB)
payment-service (domain: pembayaran, data: payments DB)
inventory-service (domain: stok, data: inventory DB)
SALAH (distributed monolith):
service-akses-database ← semua service baca DB yang sama
service-util ← "fungsi umum" tanpa domain jelas#Red Flag Distributed Monolith
Waspadai tanda-tanda ini di arsitektur kalian:
- Satu deployment pipeline untuk banyak "service".
- Service saling memanggil synchronous secara berantai (A → B → C → D).
- Perubahan schema database mengharuskan deploy banyak service sekaligus.
- Tim yang memilikinya tidak jelas per domain.
Jika tanda ini muncul, batas service belum benar — dan kompleksitas yang dibayar tidak sebanding.
#Event-Driven: Komunikasi Asinkron
#Queue vs Stream
Salah satu keputusan arsitektur utama: bagaimana service berkomunikasi. Dua pola asinkron yang paling umum:
| Pola | Karakter | Contoh Cloud |
|---|---|---|
| Queue | Satu event dikonsumsi satu consumer, pesan dihapus | SQS, RabbitMQ |
| Stream | Event bertahan, banyak consumer, replayable | Kafka, Kinesis |
Perbedaan praktisnya: queue untuk work distribution (task diproses sekali), stream untuk event log (banyak sistem memakannya). Pilih berdasarkan kebutuhan.
#Pola Event-Driven Dasar
Ketika order dibuat, satu event dipublish. Banyak service bereaksi secara independen — inventory mengurangi stok, notification mengirim email, analytics mencatat. Tidak ada yang memblokir yang lain, dan masing-masing bisa diskalakan sendiri.
Tip
Manfaat tersembunyi dari event-driven: tim bisa menambahkan consumer baru tanpa mengubah publisher. Ingin fitur "rekomendasi produk"? Cukup subscribe ke event yang sudah ada. Ini contoh nyata cara arsitektur mengurangi biaya perubahan.
#Saga Pattern: Transaksi Lintas-Service
#Masalahnya
Transaksi bisnis sering membentang banyak service. Contoh: order → bayar → kirim. Tidak ada satu database yang bisa menjamin atomik semuanya (episode 5). Saga adalah jawabannya: transaksi besar dipecah menjadi langkah-langkah lokal, masing-masing dengan transaksi sendiri dan compensation bila langkah berikutnya gagal.
#Choreography Saga
Setiap service mendengar event dan melakukan aksinya; jika gagal, mempublish event kompensasi.
Choreography sederhana tanpa orchestrator, tapi alurnya menyebar dan sulit dilacak.
#Orchestration Saga
Satu saga orchestrator (service sentral) mengarahkan langkah demi langkah dan memutuskan kompensasi.
Orchestration lebih mudah dipahami dan di-debug — alurnya terpusat. Ini pilihan yang tepat untuk saga yang kompleks. Rule of thumb: mulai dari orchestration; gunakan choreography hanya untuk alur sederhana.
#Praktik: Mendesain Event-Driven System
Kerangka desain untuk sistem event-driven baru:
- Tentukan domain events (kata benda + lampau:
order.created,payment.completed). - Pilih transport: queue untuk task-once, stream untuk event yang banyak dikonsumsi.
- Desain event schema yang versioned (
order.created.v1) agar consumer lama tidak rusak. - Tentukan konsistensi: synchronous hanya untuk yang benar-benar butuh (login), asinkron untuk sisanya.
- Tambahkan idempotency pada consumer (episode 8) — event bisa terkirim lebih dari sekali.
- Dokumentasikan di ADR, termasuk alasan memilih saga pattern.
#Penutup
Inti yang harus dibawa pulang:
- Batas microservices datang dari domain bisnis, bukan teknis; hindari distributed monolith.
- Satu service = satu domain = satu database yang dikontrol sendiri.
- Queue untuk task-once; stream untuk event yang banyak dikonsumsi.
- Saga memecah transaksi lintas-service; orchestration lebih mudah dikelola.
- Event schema versioned + consumer idempotent = fondasi yang aman.
Di episode 13 selanjutnya kita akan membahas serverless & event pipeline — event-driven serverless, workflow orchestration, dan trade-off-nya. Sampai jumpa di episode 13!