Monolith vs microservices

Sebelumnya, di lesson 0023, Anda melihat trace melintasi empat service. Lesson ini bertanya: kenapa ada empat service sejak awal? Ini salah satu tempat kandidat paling sering terlihat over-engineer di interview.

1. Tiga bentuk

• Monolith: satu aplikasi yang di-deploy sebagai satu unit, biasanya dengan satu database. Panggilan antar fitur adalah pemanggilan fungsi biasa, dan satu transaksi database bisa mencakup apa saja.
• Modular monolith: tetap satu deployable dan satu database, tapi kode dibagi menjadi modul dengan batas tegas: setiap modul punya tabelnya sendiri dan modul lain memanggilnya lewat interface publik, bukan membaca tabelnya langsung. Ini persiapan murah kalau suatu hari satu modul perlu dipisah.
• Microservices: kumpulan service kecil dan otonom; setiap service punya codebase sendiri yang bisa dikelola satu tim kecil, di-deploy sendiri, dan bertanggung jawab atas persistensi datanya sendiri. ^[1]

2. Harga microservices

Keuntungannya nyata: tim kecil men-deploy service sendiri tanpa menunggu tim lain, service di-scale terpisah, dan perubahan skema hanya memengaruhi satu service. Azure Architecture Center juga mendaftar tantangannya ^[1]:

• Kompleksitas. Setiap service lebih sederhana, tapi sistem secara keseluruhan lebih kompleks: service discovery, konsistensi data, manajemen transaksi, komunikasi antar service.
• Latency dan jaringan. Pemanggilan fungsi menjadi panggilan jaringan yang bisa lambat atau gagal. Rantai A → B → C menumpuk latency, dan setiap panggilan butuh timeout, retry, dan circuit breaker (lesson 0022).
• Integritas data. Karena setiap service memegang datanya sendiri, konsistensi lintas service menjadi tantangan.
• Testing dan skill. Menguji service yang bergantung pada service lain lebih sulit, dan tim harus punya pengalaman sistem terdistribusi.

3. Distributed transaction dan saga

Di monolith, "buat order, tagih kartu, kurangi stok" adalah satu transaksi database: semua berhasil atau semua dibatalkan. Di microservices, ketiga data itu ada di tiga database berbeda, dan jaminan ACID tradisional tidak langsung berlaku untuk beberapa data store yang dikelola terpisah. Model transaksi tradisional seperti two-phase commit (protokol yang menahan semua peserta sampai semuanya setuju untuk commit) ada, tapi Azure mengarahkan arsitektur seperti ini ke pola saga. ^[2]

Alternatifnya pola saga: urutan transaksi lokal, satu per service. Setiap langkah menyelesaikan transaksinya, memperbarui database-nya, lalu memicu langkah berikutnya lewat event atau pesan. Kalau satu langkah gagal, saga menjalankan compensating transaction yang membalik langkah yang sudah selesai. ^[2]

Konsekuensinya: di antara langkah, sistem berada di state sementara (order PENDING terlihat oleh user), dan setiap langkah harus idempotent karena pesannya bisa terkirim ulang (lesson 0017). Ini biaya yang tidak ada sama sekali di monolith.

4. Service discovery, singkat

Instance service berganti terus (deploy, autoscaling, crash), jadi alamat IP tidak bisa ditulis di konfigurasi. Service discovery memberi nama stabil di depan instance yang berubah. Di Kubernetes (platform yang menjalankan dan mengatur container di banyak mesin), client di dalam cluster menemukan Service lewat environment variable atau DNS; server DNS seperti CoreDNS memantau Service baru dan membuat record DNS untuk masing-masing. ^[3] Jadi service A cukup memanggil http://payment. Di interview, cukup sebut namanya dan fungsinya.

5. Kapan tidak perlu

Track ini memakai monolith sebagai default, dan di interview Anda sebaiknya juga begitu. Ini prinsip inti track (ukur dulu, perubahan termurah dulu), bukan kutipan dari satu sumber: microservices menyelesaikan masalah organisasi dan skala yang berbeda per bagian, dan masalah itu harus terlihat dulu sebelum biayanya dibayar.

Sinyal yang membenarkan memecah service: beberapa tim (bukan beberapa engineer) saling menunggu untuk deploy atau sering konflik di codebase yang sama; satu modul punya kebutuhan sumber daya yang sangat berbeda (misalnya pemrosesan video butuh CPU sepuluh kali lipat dari bagian lain dan harus di-scale terpisah); atau satu bagian butuh siklus rilis atau isolasi kegagalan yang berbeda. Jumlah user saja hampir tidak pernah menjadi alasan: 1.000 sampai 100.000 user aktif harian masih di bawah kapasitas beberapa server di belakang load balancer.

Biaya dan risiko: pipeline deploy, monitoring, dan tracing per service; panggilan jaringan yang bisa gagal; saga dan state sementara untuk transaksi; data yang dulu satu JOIN sekarang dua panggilan API. Batas service yang salah lebih mahal diperbaiki daripada batas modul yang salah.

Alternatif lebih murah: modular monolith (batas modul yang dijaga), scale horizontal monolith yang stateless di belakang load balancer (lesson 0005), dan memindahkan pekerjaan berat ke worker lewat queue (lesson 0016). Kalau sinyal di atas muncul, pecah satu modul yang terbukti perlu, bukan semuanya.

Berikutnya, lesson 0025: memecah service adalah anak tangga terakhir. Lesson penutup modul ini merangkai semua anak tangga sebelumnya, dari mengukur sampai memecah.

Istilah: GLOSSARY.md (bagian "Reliabilitas & API") · Indeks: semua lesson System Design

Ada yang belum jelas? Tanyakan ke saya (agent) di terminal, misalnya: "Apa beda saga choreography dan orchestration?", "Bagaimana menjaga batas modul di modular monolith supaya tidak bocor?"

Sumber: [1] Azure Architecture Center: Microservices architecture style · [2] Azure Architecture Center: Saga pattern · [3] Kubernetes docs: Service, Discovering services