Wawancara Desain Sistem: Mendesain Multi-Region API Gateway

Masalah dan Kasus Penggunaan

Desain titik masuk publik untuk 300 layanan backend. Sistem ini mencapai puncak 500.000 permintaan per detik di tiga wilayah aktif dan memuat sekitar 20.000 definisi rute. Gateway melakukan terminasi TLS, mengautentikasi pemanggil, menerapkan otorisasi tingkat tinggi (coarse authorization) dan kuota, menormalisasi permintaan, memilih upstream, mendukung weighted canary, serta memancarkan metrik dan trace. Asumsikan target ketersediaan 99,99% dan latensi p99 tambahan dari gateway kurang dari 10 milidetik. Ini adalah parameter wawancara, bukan klaim tentang sebuah produk.

Perubahan rute dan kebijakan harus sampai ke gateway yang sehat dalam waktu 30 detik. Pencabutan kredensial darurat membutuhkan jalur yang lebih cepat. Konfigurasi yang buruk tidak boleh melumpuhkan semua wilayah, dan control plane yang tidak tersedia tidak boleh menghentikan gateway untuk melayani dengan konfigurasi terakhir yang diketahui baik (last known good configuration). Logika bisnis backend, komposisi respons, orkestrasi alur kerja jangka panjang, dan otorisasi spesifik aplikasi tetap berada di luar gateway.

Ini adalah pertanyaan desain sistem tingkat senior karena pekerjaan krusial berada di antara komponen-komponen: mendefinisikan jalur permintaan panas (hot request path), memisahkan konfigurasi dari lalu lintas, membatasi perilaku kegagalan, dan membuktikan bahwa pintu masuk yang digunakan bersama secara global bukanlah titik kegagalan tunggal (single point of failure).

Apa yang Dievaluasi oleh Pewawancara

Jawaban yang kuat pertama-tama memisahkan data plane dari control plane. Proses gateway regional melayani permintaan dari snapshot lokal yang tidak dapat diubah (immutable). Control plane memvalidasi, membuat versi, menyimpan, dan mendistribusikan perubahan rute serta kebijakan. Jika seorang kandidat menempatkan pencarian database atau konfigurasi jarak jauh pada setiap permintaan, baik target latensi maupun isolasi kegagalan control plane tidak akan tercapai.

Pewawancara juga mengharapkan batasan yang jelas untuk tanggung jawab gateway. Terminasi TLS, verifikasi identitas, pencocokan rute, kebijakan umum, rate limiting, header, batas waktu (timeout), dan telemetri bersifat lintas fungsi (cross-cutting). Pemeriksaan inventaris, keputusan pembayaran, dan izin tingkat objek adalah milik layanan. Gateway universal yang mengeksekusi plugin bisnis arbitrer menjadi sulit untuk diuji dan berbahaya untuk dirilis.

Kapasitas harus dapat dihitung ulang. Pada 500.000 permintaan per detik, rata-rata permintaan masuk sebesar 2 KiB adalah sekitar 500,000 × 2 KiB ≈ 0.95 GiB/s sebelum overhead protokol. Jika satu instans gateway yang telah di-benchmark dapat secara aman mempertahankan Q permintaan per detik pada p99 yang disyaratkan, armada tersebut membutuhkan setidaknya ceil(500,000 / Q) instans, ditambah kapasitas tambahan untuk mengantisipasi hilangnya satu wilayah. Kehilangan satu dari tiga wilayah yang setara meningkatkan beban setiap wilayah yang bertahan dari sekitar 167.000 menjadi 250.000 permintaan per detik, sebuah peningkatan sebesar 50%. Perencanaan kapasitas harus mencakup kondisi tersebut.

Terakhir, jawaban yang lengkap mencakup keamanan konfigurasi, perutean regional, penyebaran beban berlebih, percobaan ulang (retries), observabilitas, dan degradasi eksplisit. Sekadar mengatakan "terapkan di beberapa wilayah" tidak menjelaskan bagaimana lalu lintas berpindah, bagaimana status berubah, atau apa yang tetap tersedia selama partisi jaringan.

Pertanyaan Klarifikasi Sebelum Menjawab

• Siapa klien-kliennya? Asumsikan klien web publik, seluler, dan mitra yang menggunakan HTTP API. Lalu lintas internal antar-layanan (service-to-service) dapat menggunakan ingress terpisah atau kebijakan service mesh.
• Apa unit ketersediaannya? Sebuah wilayah mencakup instans gateway di setidaknya tiga zona kegagalan (failure zones). Ketiga wilayah tersebut bersifat active-active, dan perutean global akan menghapus wilayah yang tidak sehat.
• Apakah rute independen berdasarkan hostname, path, dan method? Ya. Urutan pencocokan harus deterministik, dan definisi rute yang ambigu ditolak sebelum dipublikasikan.
• Kebijakan mana yang berjalan secara sinkron? Verifikasi tanda tangan, pencocokan rute, pemeriksaan otorisasi umum, kuota, batas permintaan, dan transformasi header. Data bisnis tidak pernah diambil oleh gateway untuk membuat keputusan.
• Seberapa mutakhir konfigurasi yang dibutuhkan? Perubahan normal mengalami konvergensi dalam 30 detik. Gateway melaporkan versi yang mereka terapkan. Pencabutan keamanan menggunakan masa pakai token yang singkat atau daftar tolak (deny list) kecil yang didistribusikan secara terpisah daripada memaksa pembangunan ulang snapshot secara menyeluruh.
• Seberapa tepat kuota di seluruh wilayah? Desain default menggunakan kuota regional yang dialokasikan dari anggaran global. Penghitung global yang benar-benar ketat akan menambah dependensi lintas wilayah pada setiap permintaan dan harus dijustifikasi secara terpisah.
• Bolehkah gateway mencoba ulang (retry)? Hanya permintaan idempoten, dengan anggaran percobaan ulang (retry budget) yang kecil, setelah membuktikan bahwa upaya pertama tidak diterima. Penulisan non-idempoten memerlukan kunci idimpotensi aplikasi atau tidak ada percobaan ulang otomatis.
• Apa yang dikecualikan? Pembersihan DDoS sebelum gateway, implementasi layanan, replikasi database, dan transaksi tingkat aplikasi adalah sistem yang terpisah.

Kerangka Jawaban 30 Detik

"Saya akan menempatkan armada gateway stateless di masing-masing dari tiga wilayah aktif di balik perutean global yang memantau kesehatan (health-aware). Setiap permintaan tetap berada di satu wilayah: gateway mengakhiri TLS, memverifikasi identitas dari cache kunci lokal, mencocokkan snapshot rute yang immutable, menerapkan kebijakan umum dan kuota regional, kemudian memilih upstream yang sehat di wilayah yang sama. Control plane terpisah memvalidasi setiap konfigurasi, menetapkan versi, mengujinya secara canary ke sekelompok kecil gateway, dan mengaktifkannya secara atomik; gateway tetap melayani snapshot terakhir yang diketahui baik jika plane tersebut gagal. Saya akan menentukan ukuran setiap wilayah untuk peningkatan beban 50% setelah salah satu dari tiga wilayah setara gagal, membatasi percobaan ulang dan antrean untuk menghindari amplifikasi beban berlebih, serta memantau latensi tambahan, hasil rute, kesehatan upstream, versi konfigurasi, dan failover regional."

Pembahasan Mendalam Langkah demi Langkah

Sistem ini memiliki empat lapisan. Manajemen lalu lintas global mengirimkan klien ke wilayah terdekat yang sehat. Load balancer regional menyebarkan lalu lintas ke seluruh instans gateway stateless di berbagai zona. Data plane memproksikan permintaan ke endpoint layanan di wilayah yang sama. Control plane menyimpan konfigurasi yang diinginkan, mengompilasinya menjadi snapshot berversi, dan mendistribusikan snapshot tersebut secara independen dari jalur permintaan. Microsoft mendokumentasikan gateway sebagai titik masuk terpusat untuk routing dan cross-cutting concerns, dan model gateway terkelola serta self-hosted-nya juga memisahkan konfigurasi yang dikelola secara terpusat dari lalu lintas runtime yang terdistribusi.

Alur permintaan normal adalah:

1. DNS global atau anycast memilih wilayah yang sehat. Load balancer regional memilih instans gateway.
2. Gateway mengakhiri TLS, menerapkan batas ukuran permintaan dan koneksi, serta menyematkan ID permintaan.
3. Gateway memverifikasi token yang ditandatangani menggunakan metadata penerbit dan kunci publik yang di-cache. Gateway tidak pernah memanggil penyedia identitas (identity provider) untuk setiap permintaan.
4. Pencocok yang telah dikompilasi menggunakan host, method, dan path yang dinormalisasi untuk memilih rute dari snapshot aktif.
5. Rantai kebijakan menerapkan cakupan umum, kuota regional, header, batas waktu, dan pemilihan canary opsional.
6. Gateway memilih endpoint yang sehat dari penemuan layanan (service discovery) yang di-cache secara lokal dan meneruskan permintaan dengan batas waktu yang ditentukan.
7. Gateway mencatat hasil, latensi, ID rute, kluster upstream, versi konfigurasi, dan konteks trace, lalu mengalirkan telemetri di luar jalur utama (hot path).

Definisi rute dapat tetap deklaratif:

Route {
  id: string
  host: string
  methods: string[]
  path_template: string
  upstream_cluster: string
  auth_policy_id: string
  quota_policy_id: string
  timeout_ms: uint32
  retry_policy: { max_attempts, retryable_statuses }
  traffic_split: [{ revision, weight }]
}

API kontrol menerima revisi yang diinginkan dengan kunci idimpotensi dan mengembalikan ID revisi. Validasi memeriksa skema, pencocokan yang bertentangan, kluster yang direferensikan, kepemilikan sertifikat, batas kebijakan, dan kombinasi percobaan ulang yang tidak aman. Kompiler menghasilkan snapshot immutable dengan struktur pencocokan yang telah dibuat sebelumnya. Publikasi berlangsung melalui validasi, perbandingan shadow, kohort canary kecil, satu zona, satu wilayah, dan kemudian semua wilayah. Setiap gateway mengunduh snapshot, memverifikasi checksum dan tanda tangan, membangunnya di luar thread permintaan, dan mengalihkan satu pointer atomik. Permintaan yang sedang berjalan diselesaikan pada snapshot lama. Pemeriksaan kesehatan yang gagal akan mengembalikan kohort ke versi sebelumnya.

Hambatan (bottleneck) paling kritis adalah keamanan konfigurasi pada skala armada. Mengirim pembaruan yang dapat diubah (mutable) satu per satu dapat menyebabkan versi rute, kebijakan, dan sertifikat menjadi tidak konsisten. Snapshot berversi membuat unit aktivasi menjadi eksplisit. Gateway menyimpan snapshot terverifikasi terbaru di disk lokal atau penyimpanan node yang tahan lama, mempertahankan setidaknya satu versi sebelumnya, dan mengekspos desired_version, downloaded_version, dan active_version. Pemadaman control plane membekukan perubahan tetapi tidak menghentikan lalu lintas. Snapshot yang rusak atau tidak lengkap akan ditolak. Pencabutan darurat tidak perlu menunggu seluruh 20.000 rute dikompilasi ulang: kredensial berumur pendek membatasi paparan, sementara daftar tolak kecil yang ditandatangani memiliki saluran distribusi cepat dan kedaluwarsa tersendiri.

Untuk kapasitas, lakukan benchmark pada seluruh rantai kebijakan, bukan pada reverse proxy kosong. Jika instans yang diuji mempertahankan 8.000 permintaan per detik pada p99 target, lalu lintas puncak membutuhkan ceil(500,000 / 8,000) = 63 instans sebelum kelonggaran kapasitas (headroom). Dengan tiga wilayah yang setara, kegagalan satu wilayah menyisakan 250.000 permintaan per detik per wilayah yang bertahan, atau 32 instans pada benchmark tersebut; menerapkan 40–45 instans per wilayah memberikan ruang operasional yang aman. Angka ini bersifat ilustratif dan harus diganti dengan pengukuran menggunakan TLS nyata, verifikasi token, ukuran payload, pencatatan log, dan latensi upstream.

Gateway harus membuang beban (load shedding) alih-alih menumpuknya. Berikan batasan pada permintaan konkuren, koneksi, body permintaan, antrean per rute, dan buffer telemetri. Sebarkan batas waktu (deadlines) ke upstream. Circuit breaking mencegah layanan yang gagal menghabiskan setiap koneksi gateway. Coba ulang hanya pada serangkaian kegagalan idempoten yang sempit, gunakan jitter, dan bebankan setiap upaya ke anggaran percobaan ulang. Ketika upstream jenuh, mengembalikan respons 503 secara cepat lebih aman daripada membangun antrean tak terbatas yang menghabiskan sumber daya gateway bersama.

Autentikasi menggunakan verifikasi lokal untuk token yang ditandatangani. Kunci publik diperbarui secara asinkron, saling tumpang tindih selama rotasi, dan menyimpan kumpulan valid terakhir yang diketahui untuk periode tertentu. Jika token bersifat opaque dan introspeksi wajib dilakukan, simpan hasil positif singkat dalam cache dan tentukan fail-open atau fail-closed berdasarkan risiko rute; dependensi tersebut mengubah perhitungan ketersediaan. Kepemilikan objek dan otorisasi bisnis tetap berada di dalam layanan karena gateway tidak memiliki status domain yang otoritatif.

Kuota bersifat regional pada jalur utama (hot path). Alokator global membagi anggaran penyewa (tenant) menjadi sewa singkat untuk wilayah-wilayah, dan penyimpanan data regional membuat keputusan atomik. Hal ini mencegah partisi jaringan melipatgandakan kuota global tanpa batas, namun wilayah yang terisolasi hanya dapat menghabiskan kuota sewanya. Jika wilayah independen terus menerima permintaan dan melakukan rekonsiliasi nanti, ketersediaan meningkat sementara penerimaan berlebih (over-admission) mungkin terjadi. Pemilik produk harus memilih batasan tersebut. Implementasi token-bucket yang mendalam didelegasikan ke subsistem rate-limiter daripada dibangun kembali di dalam setiap gateway.

AWS mendokumentasikan perutean failover active-passive dan perutean berbobot (weighted routing) active-active untuk gateway multi-wilayah. Di sini, active-active mengurangi risiko cold-failover. Kesehatan bersifat hierarkis: kesehatan instans menghapus satu proses, sinyal zonal mengosongkan zona, dan probe end-to-end sintetis ditambah tingkat kesalahan regional menghapus suatu wilayah. Pergeseran lalu lintas dilakukan secara bertahap jika memungkinkan. Backend regional dan penyimpanan datanya juga harus siap; hanya memindahkan gateway tidak dapat membuat layanan yang tidak tersedia menjadi sehat.

Observabilitas memerlukan latensi p50/p95/p99 tambahan dari gateway, tingkat permintaan dan kesalahan per rute, kegagalan TLS dan autentikasi, hasil kuota, koneksi aktif, kedalaman antrean, percobaan ulang, status sirkuit, latensi upstream, kesehatan endpoint, dan lag versi konfigurasi. Log mengambil sampel lalu lintas yang berhasil tetapi tetap menyimpan peristiwa keamanan dan kesalahan di bawah anggaran terbatas. Trace mempertahankan konteks yang masuk dan memulai span gateway. Peringatan membedakan kegagalan gateway dari kegagalan upstream sehingga operator tidak melakukan rollback pada gateway yang sehat karena adanya insiden pada layanan.

Alternatif utamanya adalah satu gateway universal versus gateway atau BFF berdasarkan klien atau domain. Satu armada menyederhanakan titik masuk eksternal dan tata kelola, tetapi memperbesar dampak kerusakan (blast radius) dan mendorong akumulasi kebijakan. Banyak gateway mengisolasi tim dan perilaku spesifik klien, tetapi menduplikasi operasi dan memerlukan kontrol global yang konsisten. Mulailah dengan satu gateway platform yang tipis ditambah layanan milik domain; tambahkan BFF hanya ketika klien benar-benar membutuhkan agregasi atau kontrak yang berbeda. Service mesh melengkapi desain ini untuk lalu lintas east-west dan tidak menggantikan gateway publik north-south.

Verifikasi mencakup pengujian properti tabel rute untuk pencocokan deterministik, pengujian kompatibilitas snapshot, pengujian beban pada kapasitas normal dan kondisi satu wilayah gagal, perbandingan shadow dari revisi lama dan baru, serta fault injection untuk kehilangan konektivitas control plane, kunci usang, upstream lambat, backpressure telemetri, kehilangan zona, dan evakuasi regional. Sebuah desain dianggap lengkap ketika setiap kegagalan memiliki status yang dapat diamati dan respons yang terukur.

Contoh Jawaban Berkualitas Tinggi

"Saya akan menjalankan armada gateway stateless di tiga wilayah aktif dan beberapa zona. Perutean global mengarahkan klien ke wilayah terdekat yang sehat; load balancer regional menyebarkan lalu lintas ke seluruh instans gateway. Jalur utama mengakhiri TLS, memverifikasi identitas yang ditandatangani dari cache kunci lokal, mencocokkan rute yang dikompilasi, menerapkan otorisasi umum dan kuota regional, memilih endpoint sehat di wilayah yang sama, dan meneruskan dengan batas waktu tertentu. Otorisasi domain tetap berada di dalam layanan.

Jalur permintaan tidak pernah membaca database konfigurasi. Control plane terpisah memvalidasi perubahan rute dan kebijakan yang diinginkan, menolak pencocokan ambigu dan percobaan ulang yang tidak aman, mengompilasi snapshot immutable yang ditandatangani, dan meluncurkannya melalui tahapan shadow, kohort, zona, dan wilayah. Setiap instans membangun snapshot baru di luar thread dan menukarnya secara atomik. Instans menyimpan versi terakhir yang diketahui baik, sehingga pemadaman control plane menghentikan perubahan tanpa menghentikan lalu lintas. Lag versi dan rollback otomatis membuat peluncuran parsial dapat terlihat dan dapat dibatalkan.

Pada 500.000 permintaan per detik, data masuk 2 KiB adalah sekitar 0,95 GiB/s sebelum overhead. Saya akan melakukan benchmark pada seluruh rantai kebijakan untuk mendapatkan throughput per instans yang aman Q dan menerapkan ceil(500,000 / Q) ditambah kelonggaran kapasitas untuk kegagalan. Karena hilangnya satu dari tiga wilayah yang setara meningkatkan beban setiap wilayah yang bertahan sebesar 50%, kapasitas regional dan pengujian beban akan mencakup kondisi tersebut.

Saya akan membatasi koneksi, konkurensi, body permintaan, antrean, dan upaya percobaan ulang. Percobaan ulang idempoten menggunakan anggaran kecil; penulisan non-idempoten memerlukan kunci idimpotensi atau tidak ada percobaan ulang otomatis. Kuota global dialokasikan sebagai sewa regional jangka pendek, memperjelas trade-off saat partisi terjadi. Terakhir, saya akan memantau latensi tambahan dari gateway, hasil rute, kesehatan upstream, perilaku percobaan ulang dan sirkuit, versi konfigurasi aktif, serta probe regional sintetis, kemudian menguji kehilangan control plane, konfigurasi buruk, kehilangan zona, dan failover regional sebelum peluncuran."

Kesalahan Umum

• Membaca rute atau kebijakan dari database pada setiap permintaan → latensi dan ketersediaan menjadi bergantung pada control plane → layani dari snapshot lokal yang tervalidasi dan pertahankan status terakhir yang diketahui baik.
• Menempatkan logika bisnis di plugin gateway → rilis memiliki blast radius global dan kepemilikan domain menjadi tidak jelas → jaga gateway tetap deklaratif dan pindahkan keputusan bisnis ke layanan atau BFF yang beralasan.
• Mempublikasikan perubahan yang dapat diubah secara individual → rute, kebijakan, dan sertifikat dapat aktif dalam kombinasi yang tidak kompatibel → kompilasi satu snapshot berversi dan alihkan secara atomik.
• Menganggap beberapa instans sebagai ketahanan yang cukup → satu revisi yang buruk dapat merusak setiap instans sekaligus → lakukan canary berdasarkan kohort, zona, dan wilayah, dengan gerbang kesehatan otomatis dan rollback.
• Menentukan ukuran hanya untuk puncak normal → wilayah yang bertahan akan kelebihan beban selama evakuasi → hitung dan uji peningkatan 50% per wilayah setelah satu dari tiga wilayah setara gagal.
• Mencoba ulang semua kegagalan → percobaan ulang melipatgandakan beban berlebih dan dapat menduplikasi penulisan data → coba ulang hanya kasus idempoten terbatas dan wajibkan idimpotensi aplikasi untuk operasi penulisan.
• Menggunakan panggilan penyedia identitas pada setiap permintaan → autentikasi mewarisi dependensi jarak jauh yang sinkron → verifikasi token yang ditandatangani secara lokal dan segarkan kunci secara asinkron dengan batas keusangan yang ditentukan.
• Memberikan kuota global penuh ke setiap wilayah → penyewa dapat melipatgandakan jatahnya dengan jumlah wilayah → alokasikan sewa regional atau tentukan batasan kelebihan penerimaan (over-admission) yang dapat diterima.
• Memindahkan lalu lintas gateway tanpa memeriksa backend → wilayah yang dipilih mungkin tidak memiliki layanan atau kapasitas data yang sehat → jadikan probe regional end-to-end dan kesiapan backend sebagai bagian dari failover.
• Mencatat setiap payload yang berhasil ke log → telemetri menghabiskan sumber daya pada jalur utama dan dapat membocorkan data sensitif → pancarkan metadata terstruktur secara asinkron, ambil sampel keberhasilan, dan redaksi sesuai kebijakan.

Pertanyaan Lanjutan dan Tanggapan

Pertanyaan Lanjutan 1: Bagaimana Anda membatalkan (rollback) konfigurasi rute yang buruk tanpa memutus permintaan?

Simpan snapshot immutable dan setidaknya satu versi yang diverifikasi sebelumnya. Gateway membangun kandidat konfigurasi di luar thread permintaan, memvalidasi checksum dan referensinya, lalu menukar pointer aktif secara atomik. Permintaan yang ada mempertahankan snapshot lama mereka hingga selesai. Jika kesehatan kohort menurun, control plane menandai revisi tersebut gagal dan gateway beralih kembali ke pointer sebelumnya. Rollback mengubah status konfigurasi; ini tidak me-restart seluruh armada.

Pertanyaan Lanjutan 2: Apa yang terjadi jika control plane tidak tersedia selama satu jam?

Lalu lintas berlanjut pada snapshot terakhir yang diketahui baik yang tersimpan secara persisten. Gateway mengekspos usia dan versi snapshot tersebut dan berhenti menerima perubahan yang belum diverifikasi. Rotasi sertifikat dan kunci memerlukan masa berlaku tumpang tindih yang cukup panjang untuk kondisi ini. Pencabutan darurat menggunakan masa pakai token yang singkat atau daftar tolak ringkas yang ditandatangani secara terpisah. Operator kehilangan kemampuan untuk melakukan perubahan selama pemadaman, sehingga peringatan akan berbunyi pada penundaan distribusi jauh sebelum materi yang ada kedaluwarsa.

Pertanyaan Lanjutan 3: Bagaimana Anda menghindari duplikasi POST saat gateway melakukan percobaan ulang?

Gateway tidak secara otomatis mencoba ulang permintaan non-idempoten hanya karena koneksi upstream gagal; backend mungkin telah melakukan commit sebelum respons terputus. Untuk operasi yang harus dapat dicoba ulang, klien menyediakan kunci idimpotensi, dan layanan pemilik menyimpan serta mengembalikan hasil pertama. Gateway hanya dapat mencoba ulang dalam batas waktu permintaan dan anggaran percobaan ulang yang kecil. Kesalahan koneksi sebelum byte apa pun diterima dapat ditangani secara terpisah jika lapisan transport dapat membuktikan status tersebut.

Pertanyaan Lanjutan 4: Apakah Anda akan memilih DNS global atau anycast untuk perutean regional?

Keduanya dapat memenuhi arsitektur ini. DNS yang memantau kesehatan lebih sederhana secara operasional tetapi cache membuat evakuasi berlangsung bertahap. Anycast dapat mengarahkan lalu lintas lebih cepat, tetapi membutuhkan operasi jaringan yang lebih andal dan tetap memerlukan sinyal kesehatan aplikasi. Saya akan memilih mekanisme yang sudah dioperasikan oleh platform, mengukur waktu failover, dan menjaga klien tetap toleran terhadap perubahan endpoint. Desain gateway regional tidak bergantung pada anggapan bahwa perubahan DNS bersifat instan.

Pertanyaan Lanjutan 5: Kapan Anda harus memisahkan satu gateway menjadi beberapa gateway?

Pisahkan ketika isolasi atau kontrak benar-benar berbeda: lalu lintas yang diatur oleh regulasi, domain yang dioperasikan secara independen, atau klien seluler dan web yang memerlukan agregasi yang berbeda secara substansial. Jangan memisahkan hanya untuk mencerminkan setiap microservice, karena klien nantinya akan memulihkan topologi internal dan operasional menjadi berlipat ganda. Skema kebijakan bersama, aturan identitas, telemetri, dan keamanan rilis dapat tetap menjadi kemampuan platform meskipun armada runtime diisolasi.