Edge computing bukan sekadar menjalankan kode di banyak lokasi. Nilai utamanya adalah memindahkan keputusan yang tepat lebih dekat ke pengguna, tanpa ikut memindahkan seluruh kompleksitas aplikasi.

Tulisan ini merangkum pola yang saya gunakan ketika sebuah aplikasi mulai membutuhkan respons lebih cepat, caching yang terkontrol, dan jalur request yang tetap mudah dipahami.

Mengapa edge?

Pada arsitektur tradisional, setiap request berjalan jauh menuju satu origin. Model ini tetap tepat untuk banyak aplikasi. Edge mulai berguna ketika latency jaringan, lonjakan traffic, atau personalisasi ringan di level request sudah menjadi masalah nyata.

Mulai dari bottleneck yang terukur. Jangan memilih edge hanya karena infrastrukturnya terdengar modern.

Tiga tugas yang biasanya cocok dikerjakan di edge:

  • Memvalidasi request dan melakukan redirect sebelum menyentuh origin.
  • Menyajikan response dari cache dengan aturan yang eksplisit.
  • Menggabungkan data ringan untuk menghasilkan response yang spesifik per wilayah.

Arsitektur yang tetap terbaca

Saya menjaga Worker sebagai lapisan tipis. Business rule utama tetap memiliki modul sendiri, sedangkan entry point hanya mengatur alur request.

Browser
   │
   ▼
Cloudflare Worker ── cache hit ──► Response
   │
   ├── authentication / routing
   │
   ▼
Origin API ──► Database

Pemisahan ini membuat setiap bagian punya tanggung jawab jelas. Worker menangani hal yang sensitif terhadap lokasi dan waktu respons; origin menangani transaksi dan data yang membutuhkan konsistensi kuat.

Implementasi Worker sederhana

Contoh berikut memperlihatkan entry point kecil dengan cache key yang eksplisit dan fallback ke origin.

interface Env {
  API_ORIGIN: string;
}

export default {
  async fetch(request: Request, env: Env, ctx: ExecutionContext) {
    const url = new URL(request.url);
    const cacheKey = new Request(url, request);
    const cache = caches.default;

    const cached = await cache.match(cacheKey);
    if (cached) return cached;

    const response = await fetch(`${env.API_ORIGIN}${url.pathname}`);
    const edgeResponse = new Response(response.body, response);
    edgeResponse.headers.set("Cache-Control", "public, max-age=60");

    ctx.waitUntil(cache.put(cacheKey, edgeResponse.clone()));
    return edgeResponse;
  },
};

Dalam aplikasi nyata, cache policy sebaiknya dipisahkan menjadi fungsi yang dapat diuji. Pastikan pula response privat, cookie autentikasi, dan request non-GET tidak masuk ke cache publik.

Checklist sebelum production

  1. Tentukan request mana yang boleh di-cache dan berapa lama usianya.
  2. Pastikan secrets tersimpan sebagai binding, bukan berada di source code.
  3. Tambahkan correlation ID agar request dapat dilacak dari edge hingga origin.
  4. Uji perilaku saat origin lambat, gagal, atau mengembalikan response tidak valid.
  5. Pantau cache hit ratio, error rate, dan latency berdasarkan wilayah.
  6. Siapkan mekanisme purge atau versioned cache key saat data berubah.

Penutup

Arsitektur edge yang baik tidak membuat sistem terasa lebih rumit. Ia mengurangi pekerjaan yang tidak perlu dilakukan origin, mempercepat jalur yang sering dilalui pengguna, dan tetap menyediakan batas yang jelas untuk setiap tanggung jawab.

Mulailah dari satu jalur request yang paling bernilai, ukur hasilnya, lalu perluas hanya ketika data menunjukkan manfaatnya.