Mendekatkan infrastruktur ke pengguna: memahami arsitektur CDN, cache control yang benar, edge compute untuk logika di lokasi terdekat, serta strategi distribusi global dan asal (origin)

Setelah di episode 15 kita membangun platform data, kini kita mendekatkan semuanya ke pengguna: edge & CDN. Di 2026, pengguna tersebar di seluruh dunia — dan infrastruktur yang hanya berlokasi di satu region berarti latensi buruk bagi sebagian besar dari mereka. Edge computing menjawabnya: jalankan sebanyak mungkin di titik terdekat pengguna.
Mengapa topik ini penting? Karena latensi adalah pengalaman. Riset menunjukkan setiap 100ms tambahan latensi menurunkan konversi secara signifikan. CDN dan edge adalah cara infrastruktur memperbaiki pengalaman itu tanpa menambah server aplikasi — dengan biaya yang sangat kecil dibanding menambah data center.
CDN (Content Delivery Network) adalah jaringan server cache yang tersebar global. Konten disalin ke server terdekat pengguna sehingga tidak perlu perjalanan panjang ke origin.
Perjalanan tanpa CDN: user Jakarta menunggu round-trip Jakarta → Frankfurt. Dengan CDN: konten yang sudah di-cache di edge Singapore langsung dilayani dalam milidetik. Origin hanya dikunjungi saat cache miss.
Kunci kerja CDN adalah HTTP headers. Dua header yang paling penting:
Cache-Control: max-age=3600 # cache di browser 1 jam
Cache-Control: s-maxage=3600 # cache di CDN 1 jam (public)
Cache-Control: no-store # jangan pernah cache (data pribadi)
ETag / Last-Modified # validasi cache (revalidate)Aturan praktis yang benar:
| Jenis Konten | Header | Alasan |
|---|---|---|
| Gambar, CSS, JS | max-age panjang + hash filename | Hampir tidak berubah |
| HTML halaman publik | s-maxage pendek | Berubah sesekali |
| Data pribadi pengguna | no-store | Tidak boleh bocor antar user |
| API dinamis | no-cache + ETag | Selalu divalidasi |
Kesalahan klasik: meng-cache halaman yang berisi data pengguna tertentu (misal dashboard) → user A melihat data user B. Jangan pernah cache respons yang personal kecuali key-nya menyertakan identitas user.
Contoh dengan Nginx sebagai CDN sederhana (cache untuk statis):
proxy_cache_path /var/cache/nginx levels=1:2 keys_zone=static:10m;
server {
location ~* \.(css|js|png|jpg|svg)$ {
proxy_cache static;
proxy_cache_valid 200 1h;
proxy_pass http://origin;
}
}Provider CDN komersial (Cloudflare, AWS CloudFront, Fastly) menyediakan hal yang sama sebagai layanan terkelola dengan fitur lebih (WAF, SSL, DNS, edge compute). Prinsipnya tetap: asalnya sama — cache di titik terdekat, validasi via headers.
Masalah terbesar CDN: bagaimana jika konten berubah sebelum TTL habis? Dua cara:
app.abc123.js) — browser dan CDN otomatis mengambil versi baru.Note
Strategi modern: gunakan hash dalam filename untuk aset statis (deploy selalu menghasilkan nama baru → cache lama tidak pernah kedaluwarsa), dan purge hanya untuk kasus darurat. Pola ini meminimalkan invalidasi manual yang rawan dilupakan.
CDN hanya meng-cache — edge compute menjalankan kode di lokasi edge. Contoh: Cloudflare Workers, Lambda@Edge. Kapan edge compute berguna?
| Use Case | Contoh |
|---|---|
| Modifikasi respons | Inject header, resize gambar on-the-fly |
| A/B testing | Alihkan sebagian traffic di edge |
| Geolocation | Sajikan konten sesuai lokasi pengunjung |
| Otentikasi ringan | Validasi token sebelum ke origin |
| Rate limiting | Batasi abuse di gerbang terluar |
export default {
async fetch(request, env) {
const country = request.cf.country
if (request.cf.continent === "EU") {
return fetch(new URL("https://eu.lab.local", request.url))
}
return fetch(request)
}
}Edge function ini mengarahkan pengguna Eropa ke origin Eropa — pola geo-routing yang menurunkan latensi tanpa aplikasi tahu.
Aturan keputusan: jalankan di edge jika logika-nya murah, stateless, dan butuh kecepatan (rewrite, auth ringan, cache). Jangan jalankan di edge: logika yang butuh state database besar atau compute berat — itu tetap kerja origin.
Paling sederhana — semua edge menarik dari satu origin. Kurang optimal jika origin berada jauh dari mayoritas traffic.
Beberapa origin (misal AS, Eropa, Asia), edge memilih terdekat:
asia.lab.local → origin Singapura
eu.lab.local → origin Frankfurt
us.lab.local → origin VirginiaUntuk aset statis, origin terbaik adalah object storage (episode 12) yang disinkronkan antar region — tanpa server sama sekali:
S3 bucket (origin) → CloudFront (CDN) → user
└── sync antar region untuk multi-originEdge adalah gerbang terluar — tempat yang tepat untuk pertahanan:
Prinsip arsitektur: origin harus tersembunyi — jangan pernah biarkan IP origin terekspos langsung (misal di DNS). Semua traffic masuk lewat CDN/edge sehingga origin terlindungi.
Pada episode 16 ini kalian telah membangun arsitektur edge:
Di episode 17 selanjutnya kita mengamankan akses manusia dan mesin: identity & access infrastructure — LDAP/AD, SSO, service accounts, dan PKI. Sampai jumpa di episode 17!