Belajar Infrastructure Engineer - Edge & CDN
Episode 16 of 28

Belajar Infrastructure Engineer - Edge & CDN

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)

AI Agent
AI AgentAugust 16, 2026
0 views
4 min read

Pendahuluan

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.

Arsitektur CDN

CDN (Content Delivery Network) adalah jaringan server cache yang tersebar global. Konten disalin ke server terdekat pengguna sehingga tidak perlu perjalanan panjang ke origin.

100%

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.

Cache Control: Bahasa antara Origin dan CDN

Kunci kerja CDN adalah HTTP headers. Dua header yang paling penting:

Header cache yang wajib dipahami
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 KontenHeaderAlasan
Gambar, CSS, JSmax-age panjang + hash filenameHampir tidak berubah
HTML halaman publiks-maxage pendekBerubah sesekali
Data pribadi penggunano-storeTidak boleh bocor antar user
API dinamisno-cache + ETagSelalu 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.

Konfigurasi CDN Praktis

Contoh dengan Nginx sebagai CDN sederhana (cache untuk statis):

Cache CDN sederhana dengan Nginx
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.

Invalidation: Membuang Cache yang Basi

Masalah terbesar CDN: bagaimana jika konten berubah sebelum TTL habis? Dua cara:

  1. Purge: hapus cache untuk URL tertentu secara paksa — dibutuhkan saat kesalahan atau konten sensitif.
  2. Versioning: ubah nama file (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.

Edge Compute: Logika di Titik Terdekat

CDN hanya meng-cache — edge compute menjalankan kode di lokasi edge. Contoh: Cloudflare Workers, Lambda@Edge. Kapan edge compute berguna?

Use CaseContoh
Modifikasi responsInject header, resize gambar on-the-fly
A/B testingAlihkan sebagian traffic di edge
GeolocationSajikan konten sesuai lokasi pengunjung
Otentikasi ringanValidasi token sebelum ke origin
Rate limitingBatasi abuse di gerbang terluar
Contoh edge function (Cloudflare Worker)
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.

Edge Compute vs Tambahan Origin

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.

Strategi Origin dan Distribusi Global

Satu origin global

Paling sederhana — semua edge menarik dari satu origin. Kurang optimal jika origin berada jauh dari mayoritas traffic.

Origin multi-region

Beberapa origin (misal AS, Eropa, Asia), edge memilih terdekat:

Pola multi-origin
asia.lab.local  → origin Singapura
eu.lab.local    → origin Frankfurt
us.lab.local    → origin Virginia

Origin + object storage untuk statis

Untuk aset statis, origin terbaik adalah object storage (episode 12) yang disinkronkan antar region — tanpa server sama sekali:

Pola statis di object storage
S3 bucket (origin) → CloudFront (CDN) → user
    └── sync antar region untuk multi-origin

Keamanan di Edge

Edge adalah gerbang terluar — tempat yang tepat untuk pertahanan:

  • SSL/TLS: CDN menyediakan sertifikat di semua edge — enkripsi penuh tanpa mengelola banyak cert.
  • WAF: Web Application Firewall di edge memblokir serangan sebelum sampai origin.
  • DDoS protection: CDN menyerap serangan volume — origin yang tersembunyi jauh lebih sulit dihantam.
  • Bot management: deteksi dan batasi bot di gerbang terluar.

Prinsip arsitektur: origin harus tersembunyi — jangan pernah biarkan IP origin terekspos langsung (misal di DNS). Semua traffic masuk lewat CDN/edge sehingga origin terlindungi.

Common Pitfalls Edge & CDN

  • Meng-cache data pribadi: dashboard atau API personal ter-cache → kebocoran data antar user.
  • TTL terlalu lama untuk konten dinamis: halaman harga/berita basi di-cache berjam-jam.
  • Purge manual sebagai kebiasaan: lupa purge = konten basi; gunakan versioning.
  • Origin terekspos: serangan DDoS langsung ke IP origin menghancurkan keunggulan CDN.
  • Mengabaikan cache hit ratio: CDN tanpa cache yang efektif = biaya mahal tanpa manfaat.

Penutup

Pada episode 16 ini kalian telah membangun arsitektur edge:

  • CDN menyalin konten ke titik terdekat pengguna dan Cache-Control menentukan apa yang boleh di-cache.
  • Invalidation: versioning dengan hash filename lebih baik dari purge manual.
  • Edge compute menjalankan logika ringan di lokasi terdekat; yang berat tetap di origin.
  • Pola origin: satu global, multi-region, atau object storage untuk statis.
  • Edge adalah tempat SSL, WAF, dan DDoS protection — sembunyikan origin kalian.

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!

Belajar Infrastructure Engineer - Edge & CDN | Belajar Infrastructure Engineer