UNDER PRESSURE

Level 3 · Sistem yang Saling Bergantung

Sesi 22: Ketika Layanan Dipecah: Dari Monolith ke Microservices & Bahaya Fan-Out

Bagaimana jika memecah satu aplikasi besar menjadi 30 layanan kecil independen justru membuat satu klik pengguna memicu 30 panggilan jaringan tersembunyi yang menggandakan latensi dan melumpuhkan sistem?

Sesi 22 / 344 menit baca

1. Bayangkan Jika

Di sebuah restoran tradisional (Monolith), seorang pelayan mencatat pesanan, langsung berteriak ke koki di dapur sebelah, mengambil piring, dan menyajikannya ke meja dalam 2 menit. Semuanya terjadi di satu ruangan tanpa perantara.

Lalu restoran tersebut berganti konsep menjadi "Restoran Microservices Tersebar": - Pelayan harus menelpon Pos Daging di lantai 2. - Pos Daging menelpon Pos Bumbu di gedung seberang jalan. - Pos Bumbu menelpon Pos Sayur di gudang kota lain. - Jika sambungan telepon ke Pos Sayur putus selama 5 detik, tamu di restoran menunggu dengan meja kosong. Satu pesanan makan siang memicu 30 panggilan telepon internal.

2. Apa yang Sebenarnya Terjadi

Ketika tim memecah arsitektur Monolith menjadi Microservices, batas komputasi bergeser: 1. Dari In-Memory Function Call Menjadi Network RPC: - Di Monolith: orderService.getInventory() adalah pemanggilan memori lokal yang memakan waktu 0,0001 milidetik (sub-mikrodetik) dengan keandalan 100%. - Di Microservices: Pemanggilan tersebut menjadi panggilan HTTP/REST atau gRPC lintas jaringan fisik yang memakan waktu 5–50 milidetik dan bisa gagal sewaktu-waktu akibat packet drop atau congestion.

  1. Fenomena Request Amplification (Fan-Out Explosion): - Satu permintaan sederhana dari browser pengguna (misal: GET /dashboard) masuk ke API Gateway / Backend For Frontend (BFF). - API Gateway melakukan fan-out memanggil 30 microservices internal: Auth, Profile, Cart, Recommendations, Loyalty, Notification, Inventory, Payment, Review, Promo, dsb.

  2. Aritmatika Tail Latency Amplification (p99 Trap): - Misalkan setiap microservice memiliki tingkat keandalan 99% (hanya 1 dari 100 request yang lambat/gagal). - Jika 1 request pengguna harus memanggil N = 30 service secara paralel:

    \text{Peluang Sukses Keseluruhan} = 0.99^{30} \approx 73.97\%
    - Artinya: 26% dari seluruh request pengguna akan mengalami keterlambatan parah atau kegagalan! Semakin banyak service yang dipanggil dalam satu rantai, sistem secara matematis semakin rentan melambat.

3. Solusi Arsitektur

  1. API Gateway & Backend For Frontend (BFF): - Menggabungkan (aggregate) respons dari berbagai service internal dan menyajikannya dalam satu payload ringkas ke klien.
  2. Asynchronous Parallel Fan-Out: - Gunakan Promise.all() / worker threads agar 30 pemanggilan berjalan bersamaan, bukan berurutan secara sekuensial (latensi = \max(\text{service}) bukan \sum \text{service}).
  3. Graceful Degradation (Degradasi Parsial): - Jika service rekomendasi timeout, jangan batalkan seluruh halaman dashboard! Kembalikan dashboard utama dengan section rekomendasi kosong atau fallback statis.

4. Nama Resminya

  • Microservices Architecture: Arsitektur modular di mana tiap layanan memiliki basis data dan proses deployment sendiri.
  • Fan-Out: Pola pemecahan satu request masuk menjadi beberapa request paralel ke downstream services.
  • Tail Latency Amplification: Peningkatan probabilitas keterlambatan pada persentil tinggi akibat akumulasi ketergantungan paralel.
  • BFF (Backend For Frontend): Layer API Gateway khusus yang dirancang sesuai kebutuhan klien tertentu (Mobile App vs Desktop Web).

5. Di Dunia Kita

  • Uber / Grab Booking Screen: Menampilkan peta, harga promo, estimasi driver, dan opsi pembayaran memicu fan-out ke puluhan internal services dalam tempo <500 ms.
  • Netflix Homepage: Setiap baris carousel film dikumpulkan oleh Zuul / API Gateway dari puluhan microservices personalisasi.

6. Lensa Performance Tester

Metrik dan pengujian krusial: 1. Fan-Out Factor Under Load: Berapa total internal sub-requests yang tercipta per 1.000 public ingress QPS? (Contoh: 1.000 QPS eksternal = 30.000 QPS internal). 2. Tail Latency p99/p99.9 Curve: Ukur perbedaan drastis antara p50 (median) dan p99 saat beban jaringan internal meningkat. 3. Partial Failure Resilience: Matikan 3 downstream services non-kritis dan verifikasi apakah API Gateway tetap merespons status 200 OK dengan payload terdegradasi.

7. Pertanyaan untuk Ronde Berikutnya

Tiga puluh panggilan internal per satu request sudah jadi kenyataan sehari-hari. Tapi ada pertanyaan yang lebih dalam daripada "berapa panggilannya": dengan bahasa apa layanan-layanan itu saling bicara?

Lihat satu contoh kecil. Sebuah layanan hanya butuh satu angka — nama pelanggan — tapi yang dikirim balik oleh service di sebelahnya adalah seluruh baris datanya: alamat, riwayat transaksi, 40 kolom yang tidak dia perlukan. Layanan lain mengalami kebalikannya: dia harus memanggil tiga kali hanya untuk mengumpulkan data yang seharusnya bisa diminta sekaligus.

Dua gejala itu punya nama: over-fetching dan under-fetching. Dan pilihan bahasa — REST, gRPC, atau GraphQL — menentukan berapa byte yang berjalan di kabel setiap detik, berapa panggilan yang tercipta, dan seberapa mudah pipeline itu dilacak saat jam tiga pagi.

Bahasa yang salah membuat fan-out yang kita hitung di sesi ini jadi dua kali lebih mahal tanpa ada yang sadar.

Jawabannya ada di Sesi 23: Bahasa yang Dipakai Layanan untuk Bicara — REST, gRPC, & GraphQL.