API Gateway: Resepsionis untuk Microservice

Resepsionis hotel dengan banyak restoran

Hotel besar punya satu resepsionis di lobi, bukan pintu terpisah untuk tiap restoran, spa, dan gym. Tamu datang ke satu tempat, resepsionis mengarahkan ke layanan yang tepat. API gateway adalah "resepsionis" untuk microservice: satu pintu masuk untuk semua klien, yang me-routing request ke service yang tepat di belakangnya.

Kenapa gateway dibutuhkan

Tanpa gateway, setiap klien harus tahu alamat puluhan microservice, menangani auth berulang, dan mengatur rate limit sendiri. Gateway memusatkan semua itu: autentikasi sekali di pintu masuk, routing berdasarkan path, rate limiting global, logging terpusat, bahkan transformasi response. Klien hanya tahu satu URL.

Contoh 1: routing berdasarkan path

# Konfigurasi gateway (konsep)
routes:
  - path: /api/produk/*
    service: katalog-service:8081
  - path: /api/bayar/*
    service: pembayaran-service:8082
  - path: /api/user/*
    service: user-service:8083

Klien memanggil gateway.contoh.id/api/produk/1, gateway meneruskan ke katalog-service. Klien tidak pernah tahu ada tiga service berbeda di belakang.

Contoh 2: kebijakan lintas service

kebijakan-global:
  autentikasi: wajib JWT di semua route
  rate-limit: 1000 request/menit per API key
  cors: izinkan https://app.contoh.id
  log: catat semua request ke sistem pusat

Tanpa gateway, empat kebijakan ini harus diimplementasikan di SETIAP service (dan pasti ada yang lupa). Dengan gateway, cukup sekali. Tools populer: Kong, Nginx, AWS API Gateway, dan Traefik.

Kesalahan umum

Salah: memakai gateway untuk satu monolit. Menambah hop jaringan tanpa manfaat. Yang benar: gateway masuk akal mulai 3+ service.

Salah: menaruh logika bisnis di gateway. Gateway untuk cross-cutting concerns (auth, routing, limit), bukan aturan diskon. Yang benar: logika bisnis tetap di service.

Salah: gateway menjadi single point of failure. Satu gateway down, semua down. Yang benar: jalankan gateway dengan replica dan health check, seperti service lainnya.

Salah: tidak memikirkan latensi tambahan. Setiap request melewati satu hop ekstra. Yang benar: ukur; biasanya 1-5ms, sepadan dengan manfaatnya.

Contoh gateway nyata: Kong dan Nginx

Dua pilihan populer dengan filosofi beda:

• Kong: gateway khusus dengan plugin siap pakai (auth, rate limit, transformasi). Cocok untuk tim yang ingin fitur lengkap tanpa coding banyak.
• Nginx: reverse proxy serbaguna yang bisa berperan sebagai gateway ringan. Cocok kalau kebutuhanmu sederhana: routing + TLS + rate limit dasar.

Untuk memulai, Nginx cukup: satu file konfigurasi untuk me-routing tiga service. Saat butuh plugin auth JWT, analitik, dan dashboard, migrasi ke Kong. Prinsipnya sama: mulai sederhana, tambah kompleksitas saat dibutuhkan.

Catatan teknis: Backend-for-Frontend (BFF) adalah varian gateway: satu gateway per jenis klien (mobile, web) yang mengagregasi beberapa service menjadi response yang pas untuk klien itu. Pola ini populer di perusahaan besar dengan banyak aplikasi.