Lesson 0007 · System Design · Modul Skalabilitas · ±20 menit

Reverse proxy, API gateway singkat, dan CDN

Apa yang bisa dikerjakan di depan server Anda, dan kapan konten sebaiknya dilayani dari edge yang dekat dengan user

Sebelumnya, lesson 0006 membahas load balancer yang membagi request ke beberapa instance. Load balancer sebenarnya satu jenis reverse proxy. Lesson ini melengkapi gambarnya: reverse proxy secara umum, API gateway sekilas, dan CDN yang memindahkan konten statis sedekat mungkin ke user. Ini lesson terakhir modul Skalabilitas.

Target lesson ini: Anda bisa menjawab "Apa beda reverse proxy, API gateway, dan CDN, dan kapan Anda memakai CDN?" tanpa catatan, dalam 60 detik: peran masing-masing, alur cache hit dan miss di edge, push vs pull CDN, cara memperbarui konten, dan angka yang membenarkan CDN.

1. Reverse proxy: server di depan server

RFC 9110 mendefinisikannya: "A "gateway" (a.k.a. "reverse proxy") is an intermediary that acts as an origin server for the outbound connection but translates received requests and forwards them inbound to another server or servers." Bagi client, reverse proxy terlihat seperti server aslinya. RFC yang sama menyebut kegunaannya: "accelerator" caching dan "partitioning or load balancing of HTTP services across multiple machines". ^[1]

Client→ Reverse proxy (TLS, cache, kompresi)→ App server 1..N→ Database

Pekerjaan yang biasa dipindah ke reverse proxy supaya app server tidak mengerjakannya:

TLS termination: sertifikat cukup dipasang di satu tempat (lesson 0006).
Cache respons: nginx punya proxy_cache yang menyimpan respons dari server di belakangnya, sehingga request yang sama tidak sampai ke app. ^[2]
Load balancing: proxy_pass ke sebuah server group, persis seperti lesson 0006. ^[2]
Menyembunyikan server: hanya proxy yang punya alamat publik; app server dan database ada di jaringan privat.

2. API gateway, singkat

API gateway adalah reverse proxy yang menjadi pintu masuk tunggal ke banyak service. Azure Architecture Center: ia "acts as a reverse proxy and routes clients requests to the appropriate services" dan bisa mengerjakan urusan lintas service (cross-cutting) seperti autentikasi, SSL/TLS termination, dan rate limiting (membatasi jumlah request per client, lesson 0021). Routing-nya memakai layer 7. ^[3]

Biayanya disebut terang-terangan di pola Gateway Offloading: gateway menambah satu hop jaringan di setiap request, bisa menjadi bottleneck kalau kapasitasnya kurang, dan harus dijalankan dalam beberapa instance supaya tidak menjadi single point of failure. Pola ini juga "might not be suitable" kalau urusan yang dipindah ringan dan workload-nya sensitif terhadap latency. ^[4]

Komponen	Pertanyaan yang dijawab
Load balancer	Instance mana yang melayani request ini?
Reverse proxy	Apa yang dikerjakan sebelum request sampai ke server (TLS, cache, kompresi)?
API gateway	Service mana yang dituju, dan apakah client ini boleh masuk?
CDN	Bisakah respons ini dilayani dari lokasi dekat user tanpa menyentuh origin?

Satu produk bisa memainkan beberapa peran sekaligus: nginx bisa menjadi reverse proxy, load balancer, dan cache. Di interview, sebut perannya, bukan merek produknya.

Latihan 1 — Reverse proxy dan API gateway

Jawab tanpa scroll ke atas. Soal yang sama akan muncul lagi, diacak, di review 0012.

Kuis di lesson ini adalah feedback cepat, bukan bukti penguasaan; yang dicatat hanya hasil review 0012.

3. CDN: cache di edge

CDN (content delivery network) adalah jaringan server yang tersebar dan menyimpan salinan konten di edge, server yang dekat dengan user, untuk memperkecil latency. Biasanya dipakai untuk konten statis (gambar, CSS, JavaScript, dokumen), dan sekaligus mengurangi beban aplikasi karena request itu tidak lagi sampai ke server Anda. ^[5] Dalam istilah RFC 9111, CDN adalah shared cache: cache yang menyimpan respons untuk dipakai ulang oleh lebih dari satu user. ^[6]

Edge Jakarta sudah punya salinan (cache hit) dan tidak menghubungi origin. Edge Tokyo belum punya (cache miss): ia meminta ke origin sekali, meneruskan ke user, dan menyimpannya untuk request berikutnya.

Alur di CloudFront (CDN milik AWS): DNS mengarahkan request ke edge location (POP) yang biasanya paling dekat dari sisi latency. Kalau objek ada di cache, edge langsung mengembalikannya. Kalau tidak, edge meneruskan request ke origin, mulai mengirim ke user begitu byte pertama tiba, dan menyimpan objek itu "for the next time someone requests it". ^[7]

Push vs pull

	Pull CDN	Push CDN
Cara konten masuk	Edge mengambil dari origin saat request pertama (cache miss)	Anda mengunggah file ke storage CDN lebih dulu
Contoh	CloudFront dengan origin server atau bucket (alur di atas) ^[7]	KeyCDN Push Zone: unggah ke storage cluster mereka ^[8]
Cocok untuk	Default: situs dan aset yang sering berubah, tanpa langkah deploy tambahan	File besar yang jarang berubah; KeyCDN menyarankan push untuk file > 10 MB dan mewajibkannya di atas 100 MB ^[8]
Kelemahan	Request pertama per edge lambat (miss); origin harus hidup	Anda yang mengatur upload dan pembaruan; lupa unggah = konten lama

Berapa lama disimpan, dan cara memperbaruinya

Lama penyimpanan diatur header Cache-Control: max-age=<detik> dari origin, atau pengaturan TTL di CDN. Di CloudFront tanpa cache policy, default TTL adalah 24 jam. ^[9] Untuk mengganti file sebelum TTL habis ada dua cara: invalidation (minta edge membuang file itu) atau nama file berversi (mis. app.3f9a.js), sehingga file baru adalah URL baru. ^[10] Nama berversi biasanya lebih disukai untuk aset statis: TTL bisa dibuat panjang tanpa takut user melihat versi lama.

Latihan 2 — CDN

Jawab tanpa scroll ke atas. Soal yang sama akan muncul lagi, diacak, di review 0012.

4. Kapan tidak perlu

Reverse proxy. Sinyal: lebih dari satu instance, atau TLS dan kompresi ingin diurus di satu tempat. Hosting managed dan load balancer L7 sering sudah menjadi reverse proxy Anda, jadi jangan menambah lapisan kedua tanpa alasan.

API gateway. Sinyal: beberapa service terpisah yang dipanggil client dan urusan bersama (auth, rate limiting) yang diulang di setiap service. Untuk satu monolith, aplikasinya sendiri sudah menjadi pintu masuk tunggal; gateway hanya menambah hop, bottleneck potensial, dan komponen yang harus redundan. ^[4]

CDN. Sinyal: user tersebar jauh dari origin (RTT lintas benua puluhan sampai ratusan milidetik, lesson 0003), atau estimasi bandwidth konten statis besar (lesson 0004), atau origin sibuk melayani file yang sama berulang kali. Biaya dan risiko: konten basi selama TTL, invalidation yang harus diingat setiap deploy, debugging lebih sulit ("di edge mana yang salah?"), dan respons per user yang tidak bisa di-cache di shared cache sehingga manfaatnya kecil untuk API yang personal. Alternatif lebih murah: header Cache-Control yang benar supaya browser (private cache) menyimpan aset, kompresi, dan nama file berversi. Untuk aplikasi internal dengan user di satu kota, CDN hampir tidak memberi apa-apa.

Latihan lisan — Ucapkan dengan suara keras

Pasang timer dan jawab dengan suara keras, seolah sedang interview. Jangan buka jawaban contoh sebelum selesai. Soal ini juga ada di bank soal dan bisa ditarik review 0012.

"Situs e-commerce Anda punya banyak gambar produk dan user di seluruh Asia. Apakah Anda memakai CDN? Jelaskan cara kerjanya dan cara memperbarui gambar." (60 detik)

Bandingkan dengan jawaban contoh dan checklist-nya

"Ya, dan ini alasannya dengan angka: user tersebar di Asia sementara origin di satu region, jadi RTT ke origin bisa ratusan milidetik, dan gambar produk adalah bagian terbesar bandwidth. CDN menyimpan salinan di edge dekat user. Saya pakai pull CDN: request pertama di setiap edge adalah cache miss, edge mengambil dari origin dan menyimpannya; request berikutnya cache hit dan tidak menyentuh origin, jadi beban origin juga turun. Push CDN saya pakai hanya untuk file besar yang jarang berubah, misalnya video. TTL saya atur dengan Cache-Control max-age yang panjang, dan untuk memperbarui gambar saya pakai nama file berversi, bukan invalidation setiap deploy. Data per user seperti keranjang tidak lewat cache CDN. Kalau user-nya hanya di satu kota, saya cukup pakai Cache-Control di browser dulu."

Checklist: apakah Anda menyebut…

CDN menyimpan salinan konten statis di edge dekat user?
alur cache hit dilayani edge dan cache miss diambil dari origin lalu disimpan?
pull sebagai default dan push untuk file besar yang jarang berubah?
TTL lewat Cache-Control dan pembaruan lewat nama berversi atau invalidation?
konten per user atau dinamis tidak di-cache di CDN?
membenarkan CDN dengan angka (jarak/RTT user, bandwidth gambar, beban origin)?

Lulus jika minimal 4 dari 6.

Bacaan lanjutan (opsional, tidak dihitung dalam durasi) Amazon CloudFront, "How CloudFront delivers content", ±5 menit. Alur edge, origin, dan regional edge cache dengan bahasa yang sederhana.

Berikutnya, lesson 0008: modul Data dimulai. Setelah app server bisa di-scale out, bottleneck berikutnya biasanya database: relasional atau NoSQL, dan kapan memilih yang mana.

Istilah: GLOSSARY.md (bagian "Skalabilitas") · Indeks: semua lesson System Design

Ada yang belum jelas? Tanyakan ke saya (agent) di terminal, misalnya: "Apa bedanya reverse proxy dan forward proxy?", "Kenapa nama file berversi lebih baik daripada invalidation?"

Sumber: [1] RFC 9110: HTTP Semantics, 3.7 Intermediaries · [2] nginx: Module ngx_http_proxy_module · [3] Azure Architecture Center: API gateways · [4] Azure Architecture Center: Gateway Offloading pattern · [5] Azure Architecture Center: CDN guidance · [6] RFC 9111: HTTP Caching, shared and private caches · [7] Amazon CloudFront: How CloudFront delivers content · [8] KeyCDN Support: Push Zone · [9] Amazon CloudFront: Manage how long content stays in the cache (expiration) · [10] Amazon CloudFront: Invalidate files to remove content