Tempatkan komponen perutean trafik

Pertanyaan

Komponen mana yang berdiri di antara klien dan aplikasi, dan tugas apa yang masuk ke masing-masing?

Setelah baca ini, kamu bisa menggambar jalur trafik dengan komponen yang tepat, menyebut tugas tiap komponen, dan menolak komponen yang belum punya alasan.

Prasyarat dan contoh

Kamu sudah bisa menelusuri request (M02.01), memilih protokol (M02.02), dan tahu bahwa instance aplikasi punya batas konkurensi (M02.03).

Sebuah toko online punya tiga service: katalog, keranjang, pembayaran, masing-masing 2 instance. Klien hanya tahu api.toko.example. Seseorang harus memutuskan request /katalog/... pergi ke instance katalog yang mana, siapa yang mengakhiri TLS, dan siapa yang menolak token yang kedaluwarsa. Pertanyaannya: itu satu komponen atau empat?

Mekanisme

Reverse proxy. Menerima koneksi klien dan meneruskan ke server di belakangnya. Tugas umum: mengakhiri TLS, kompresi, caching respons statis, menambah header, membatasi ukuran body. Klien tidak tahu server asli. Contoh: Nginx, Envoy, HAProxy. Satu reverse proxy di depan satu aplikasi sudah umum dan sah.

Load balancer. Membagi request atau koneksi ke beberapa instance. Dua tingkat:

• L4 (transport): melihat IP dan port, meneruskan koneksi TCP/UDP tanpa membaca isi. Cepat, murah, protokol apa pun. Tidak bisa merutekan berdasarkan path atau header.
• L7 (aplikasi): membaca HTTP. Bisa merutekan /katalog ke satu grup dan /bayar ke grup lain, membagi per request (bukan per koneksi), menambah retry, dan mengamati status kode. Biayanya: harus mengakhiri TLS dan memproses tiap request.

API gateway. Reverse proxy L7 plus kebijakan di tingkat API: autentikasi, otorisasi dasar, rate limit, transformasi request, versioning rute, dan metrik per konsumen. Gateway menjawab "siapa boleh memanggil API apa dan seberapa sering", bukan sekadar "ke mana diteruskan".

Service discovery. Menjawab "instance katalog yang hidup sekarang ada di alamat mana". Dua gaya:

• Sisi server: klien memanggil satu alamat tetap (load balancer), dan load balancer mengetahui anggota.
• Sisi klien: klien bertanya ke registri (DNS, Consul, Kubernetes service) lalu memilih sendiri instance.

Di lingkungan dengan instance yang sering berganti, daftar alamat statis di konfigurasi akan basi.

Susunan untuk toko tadi:

klien → LB L4 (TLS pass-through atau terminate) → gateway/proxy L7
        → katalog (2 instance) | keranjang (2) | pembayaran (2)

Beberapa produk menggabungkan peran. Nginx bisa jadi reverse proxy, LB L7, dan gateway sederhana sekaligus. Yang penting adalah peran, bukan merek.

| Pertanyaan | Komponen yang menjawab | | ----------------------------------------- | ----------------------------- | | Siapa mengakhiri TLS? | reverse proxy / LB L7 | | Ke instance mana request ini? | load balancer + discovery | | Token valid? Berapa kuota konsumen ini? | API gateway | | Alamat instance baru dari mana? | service discovery |

Menempatkan kebijakan. Autentikasi di gateway bagus untuk penolakan awal, tapi service tetap harus memeriksa otorisasi untuk datanya sendiri. Gateway yang dilewati (lewat jaringan internal) tidak boleh membuka akses.

Saat rancangan ini gagal

• Gateway sebagai titik gagal tunggal. Satu instance gateway mati, seluruh API mati. Gateway perlu redundan, dan itu sendiri membutuhkan load balancer di depannya.
• Logika bisnis di gateway. Aturan harga atau validasi domain yang menumpuk di gateway membuatnya jadi monolit kedua yang dirilis tim lain.
• L4 untuk kebutuhan L7. Merutekan per path atau mengamati error 5xx tidak mungkin di L4. Memaksakannya berakhir dengan service pembagi di dalam aplikasi.
• L7 untuk beban yang cukup L4. Memproses jutaan koneksi TCP biasa lewat proxy HTTP penuh menambah CPU dan latensi tanpa manfaat.
• Discovery basi. Instance sudah mati tapi masih di daftar. Request dikirim ke alamat mati sampai TTL atau health check membersihkannya.
• Hop berlapis. Klien → CDN → LB → gateway → sidecar → service: lima hop, tiap hop punya timeout sendiri. Timeout yang tidak selaras menghasilkan kegagalan yang sulit dilacak.

Contoh tandingan: memasang gateway lengkap untuk satu aplikasi dengan dua instance menambah operasi tanpa kebijakan yang perlu ditegakkan. Reverse proxy yang sudah ada cukup.

Latihan

Aplikasi punya satu API publik (3 service, 2 instance tiap service), satu layanan WebSocket untuk notifikasi, dan 50 konsumen API pihak ketiga yang masing-masing diberi kuota. Susun jalur trafik minimal dan sebut tugas tiap komponen. Mana komponen yang kamu tunda?

Lihat pembahasan+

Jalur minimal:

1. Load balancer L4 di depan, untuk menerima koneksi dari internet dan menyebarkan ke beberapa instance proxy. Cocok juga untuk WebSocket karena koneksi panjang diteruskan apa adanya.
2. Gateway/reverse proxy L7 (dua instance atau lebih): mengakhiri TLS, memeriksa token, menegakkan kuota 50 konsumen, dan merutekan per path ke grup service.
3. Service discovery: lewat DNS internal atau mekanisme platform yang sudah ada, supaya gateway tahu instance yang hidup. Tidak perlu registri terpisah kalau platform sudah menyediakannya.

Yang ditunda: service mesh dengan sidecar di tiap service. Dengan 3 service, tidak ada masalah yang dipecahkan dan tiap hop tambahan menambah latensi dan konfigurasi.

Catatan: kuota 50 konsumen adalah alasan konkret untuk gateway. Tanpa kebutuhan itu, reverse proxy L7 biasa sudah cukup. Service tetap memeriksa otorisasi sendiri. Jawaban yang bagus menyebut alasan tiap komponen dan satu komponen yang sengaja ditunda.

Terkait

• M02.02 Pilih transport menjelaskan pola koneksi yang memengaruhi pilihan L4 atau L7.
• M02.05 Alihkan trafik dari server yang tidak sehat membahas bagaimana load balancer memilih dan menarik instance.
• M03 Kontrak API dan retry yang aman membahas keamanan API dan batas kepercayaan.
• Rancangan D02 belum tersedia.

Catatan

• Asumsi: satu region, instance di jaringan privat, platform yang menyediakan DNS internal.
• Batas antara reverse proxy, LB L7, dan gateway kabur di produk nyata. Pelajaran ini membedakan peran, bukan produk.
• Yang tidak dibahas: service mesh, CDN, dan DNS-based global load balancing.
• Terakhir ditinjau: 26 Oktober 2026.