Belajar 9router - Distributed & Multi-region Routing

#Pendahuluan

Episode 16 membuat gateway cerdas dengan kode — hook, plugin, aksi, dan modul rute. Tapi kecerdasan itu masih hidup di satu wilayah geografis. Saat user di Jakarta, Berlin, dan São Paulo memakai layanan yang sama, gateway di satu region akan membuat salah satu dari mereka menempuh perjalanan yang sangat jauh — dan latensi episode 15 itu kembali lagi, kali ini dalam bentuk jarak fisik.

Episode 17 membawa 9router ke skala dunia: edge routing yang menjawab dari lokasi terdekat, pemilihan model regional yang memanfaatkan provider terdekat, strategi pengurangan latensi untuk user global, serta failover multi-region dan redundansi provider supaya gateway tetap hidup meski satu region atau satu provider tumbang.

#Edge Routing: Menjawab dari Lokasi Terdekat

Prinsip pertama: dekatlah dengan pengguna. Satu gateway di satu region memaksa semua request melewati jaringan lintas benua. Dengan menempatkan instance 9router di beberapa region — atau di edge — request masuk ditangani instance terdekat berdasarkan lokasi client, sehingga jarak tempuh minimal.

regions:
  - name: ap-southeast
    endpoints: [gw-id, gw-sg]
    primary: true
  - name: eu-central
    endpoints: [gw-fra]
  - name: us-east
    endpoints: [gw-nyc]

Pemilihan endpoint bisa berbasis DNS dengan geo-routing atau latency-aware: instance memantau jarak RTT antar endpoint dan mengarahkan request ke yang tercepat saat itu. Setiap instance berbagi konfigurasi yang sama, sehingga keputusan rute konsisten di mana pun request masuk.

9router edge whoami
9router edge routes --from ap-southeast

#Pemilihan Model Regional

Kedekatan dengan pengguna hanya setengah jalan; provider LLM pun punya lokasi. Request dari Eropa tidak harus bolak-balik ke data center Amerika jika ada region model yang lebih dekat. 9router memetakan model ke region provider dan memilih kandidat terbaik berdasarkan lokasi request.

model_regions:
  - model: gpt-4o-mini
    regions:
      - provider: azure-asia
        region: southeast-asia
      - provider: azure-eu
        region: france-central
  - model: claude-sonnet
    regions:
      - provider: anthropic-eu
        region: eu-central

Saat request datang dari Jakarta, 9router menempatkan azure-asia di urutan teratas karena jaraknya dekat; request dari Berlin memilih azure-eu. Urutan ini disebut preference list — masih bisa digeser oleh kebijakan cost, SLA, atau data residency dari episode 14.

model_regions:
  - model: gpt-4o-mini
    regions:
      - provider: azure-eu
        region: france-central
    only_if:
      residency: eu

#Mengurangi Latensi untuk User Global

Edge routing dan regional provider menangani jarak, tapi ada lapisan lain: bagian request yang tidak perlu menempuh perjalanan jauh. Cache — dari episode 15 — jika ditaruh di edge, jawaban untuk pertanyaan populer bisa disajikan langsung dari lokasi terdekat tanpa menyentuh origin maupun provider.

edge_cache:
  enabled: true
  response_ttl: 300s
  semantic_cache:
    store: redis-cluster
    topology: geo-distributed
  warm_on: [popular_intents]

Warming cache adalah teknik memintanya: intent yang sudah diketahui populer dipanggil lebih dulu dari origin ke cache region lain, sehingga user pertama di region baru tidak menunggu penuh. Kombinasi geo-distributed Redis dan warming membuat latensi p95 tetap rendah meski pengguna tersebar di banyak benua.

#Failover Multi-region

Ketika satu region mengalami gangguan, user tidak boleh sekadar "tunggu sampai pulih". Failover multi-region mengarahkan request ke region lain yang sehat — transparan bagi client yang tidak tahu persis di mana request dilayani.

regions:
  - name: ap-southeast
    endpoints: [gw-id, gw-sg]
    failover:
      - eu-central
      - us-east
    health_check:
      interval: 5s
      timeout: 2s

Instance di ap-southeast memonitor kesehatannya sendiri. Jika dua endpoint mati bersamaan atau health check gagal, traffic dialihkan ke eu-central lalu us-east. Client tetap memakai satu domain; logika failover ada di konfigurasi, bukan di aplikasi.

9router failover trigger --from ap-southeast --to eu-central
9router region status

Failover manual berguna saat migrasi terencana — misalnya pemeliharaan data center — sementara failover otomatis menangani yang tak terduga. Kombinasikan keduanya dan pastikan switchback juga diuji: kembali ke region utama saat sudah pulih, bukan membiarkan traffic tertahan di region cadangan selamanya.

#Redundansi Provider

Satu provider bukanlah jaminan. Jika openai-prod terganggu, request yang bergantung padanya ikut lumpuh. Redundansi provider berarti setiap model punya lebih dari satu penyedia yang setara — dan 9router memilih di antara mereka berdasarkan kesehatan dan preferensi.

routes:
  - name: chat-general
    match:
      intent: general_chat
    model: gpt-4o-mini
    providers:
      - openai-prod
      - azure-openai-prod
      - openrouter-fallback
    preference: latency

Order providers adalah daftar pilihan; preference: latency membuat 9router menimbang latensi saat memilih, bukan hanya urutan. Jika provider pertama menolak, gateway meneruskan ke berikutnya secara otomatis — pola yang sudah kalian lihat sejak episode 3, kini digandakan di seluruh region.

#Sinkronisasi Konfigurasi dan Konsistensi

Distribusi menuntut pertanyaan krusial: bagaimana semua region tahu kebijakan yang sama? Jika config dikirim manual ke tiap region, satu region bisa tertinggal dan membuat keputusan dengan aturan lama. 9router memakai config center sebagai sumber kebenaran tunggal yang disebar otomatis.

config_sync:
  source: git
  registry: control-plane
  targets: [gw-id, gw-sg, gw-fra, gw-nyc]
  versioned: true
  rollback_on_error: true

Config dikelola di git (persis pola episode 10), diregistrasi ke control-plane, lalu disebar ke semua region dengan versi yang sama. rollback_on_error otomatis memutar balik ke versi terakhir yang sehat jika salah satu region gagal menerapkan — sementara audit config_sync mencatat setiap perubahan untuk keperluan episode 14. Status sebaran bisa dipantau dengan 9router config sync status.

#Penutup

Episode 17 membawa gateway ke skala dunia: edge routing menjawab dari lokasi terdekat, pemilihan model regional memanfaatkan provider di benua yang sama, cache edge dan streaming memangkas latensi bagi user global, failover multi-region menjaga layanan saat satu region tumbang, redundansi provider menangkal ketergantungan pada satu penyedia, dan sinkronisasi konfigurasi memastikan semua region berbicara dengan aturan yang sama.

Inti yang harus dibawa pulang:

• Dekatkan gateway dengan pengguna lewat multi-region atau edge, dan pilih endpoint berdasarkan latensi.
• Petakan model ke region provider agar request dilayani dari lokasi terdekat, selaras dengan kebijakan residency.
• Taruh cache di edge dan panaskan untuk intent populer; streaming menjaga TTFT tetap rendah secara global.
• Susun failover berjenjang antar region dan uji switchback secara rutin, bukan hanya jalur menuju cadangan.
• Redundansi provider dan config sync berversi membuat seluruh sistem konsisten dan tahan bencana.

Gateway kalian kini melayani seluruh dunia. Di episode 18 kita menghadapi saat-saat tersulit: Recovery & Operational Resilience — strategi failover untuk pemadaman provider, backup route dan perilaku degraded mode, serta incident response untuk kegagalan routing. Sampai jumpa di sana!