Masalah dan Cakupan
Desain sistem service discovery internal untuk 2.000 layanan logis dan 100.000 instans dinamis di 3 region. Penjadwalan ulang kontainer, autoscaling, dan rolling deployment terus-menerus mengubah alamat. Satu deployment besar dapat mengganti 10.000 endpoint dalam 2 menit. Penelepon (callers) menggunakan beberapa bahasa pemrograman, sehingga setiap tim tidak dapat diharapkan untuk mengelola discovery SDK yang canggih.
Masalah ini memisahkan dua batas waktu (deadlines). Setelah control plane mengamati transisi sengaja suatu instans keluar dari layanan, p99 dari pengamatan tersebut hingga penghentian traffic baru adalah maksimal 3 detik. Jika suatu proses atau node menghilang tanpa pemberitahuan, p99 deteksi hard-failure adalah maksimal 15 detik. Panggilan yang ada harus tetap berlanjut dari endpoint yang terakhir diketahui (last-known endpoints) selama pemadaman discovery control-plane selama 10 menit. Hal tersebut tidak berarti bahwa instans baru menjadi terlihat atau instans yang di-cache tetap hidup selama pemadaman.
Jumlah layanan, jumlah instans, jumlah region, ukuran deployment, dan SLO adalah asumsi wawancara. Cakupannya mencakup registrasi, lease, status kesehatan, query endpoint dan pengiriman bertahap (incremental delivery), caching, draining, perilaku multi-region, serta verifikasi. Penyeimbangan permintaan (request balancing) hanya dibahas jika discovery membutuhkannya; business API, data plane service-mesh yang lengkap, dan DNS publik berada di luar cakupan. Ini adalah system-design karena tugas utamanya mencakup control plane, proxy, sinyal kesehatan, dan perilaku traffic ujung ke ujung (end-to-end).
Apa yang Dievaluasi oleh Pewawancara
Sinyal pertama adalah memisahkan registrasi, discovery, keputusan kesehatan, dan perutean (routing). Registry mencatat siapa yang mengklaim berjalan di mana. Logika kesehatan memutuskan apakah suatu instans boleh menerima traffic saat ini. Discovery mengirimkan kandidat ke sisi pemanggil. Proxy atau klien memilih satu kandidat. Menggambarkan keempatnya sebagai satu database akan mengabaikan latensi propagasi dan batas-batas kegagalan (failure boundaries).
Sinyal kedua adalah pemisahan control-plane dan data-plane. Jika setiap request bisnis menanyakan registry secara sinkron, perlambatan registry akan menjadi pemadaman di seluruh sistem. Desain yang kuat menyimpan snapshot berversi di proxy dan menerima perubahan di latar belakang. Selama kegagalan control-plane, data plane menggunakan kumpulan data yang terakhir diketahui dan menangani endpoint basi (stale) dengan batas waktu koneksi yang singkat (short connection timeouts), percobaan ulang terbatas (bounded retries), dan ejeksi lokal pasif.
Sinyal ketiga adalah mengakui bahwa informasi discovery selalu bisa menjadi basi (stale). DNS TTL, cache proxy, watch delay, deteksi kegagalan, dan rolling shutdown menciptakan celah waktu (windows). Jawaban yang kuat mendefinisikan peristiwa mana yang memulai setiap penghitung waktu (clock), menetapkan SLO terpisah untuk penarikan sengaja dan kegagalan keras, serta mengalokasikan anggaran untuk frekuensi probe (probe cadence), ambang batas, dan propagasi. Pernyataan “Konsistensi yang kuat mencegah panggilan ke instans mati” mengabaikan partisi dan kemungkinan kegagalan instans yang terjadi segera setelah pembacaan.
Terakhir, pewawancara mencari skala dan pertimbangan operasional. Jika 100.000 instans memperbarui lease secara langsung setiap 10 detik, registry menerima 10.000 pembaruan per detik sebelum perubahan rollout dan fanout watch. Desain harus mampu mengendalikan amplifikasi penulisan (write amplification), badai koneksi ulang (reconnect storms), full snapshot, domain kegagalan regional, dan health check yang buruk, alih-alih sekadar menyebutkan Consul, etcd, atau Kubernetes.
Pertanyaan untuk Diklarifikasi Sebelum Menjawab
- Apa sumber kebenaran (source of truth) registrasi? Jika orchestrator memiliki siklus hidup Pod, controller harus menghasilkan registrasi. Agen lokal dengan identitas beban kerja (workload identity) dapat mendaftarkan VM atau proses eksternal. Mengizinkan registrasi mandiri tanpa autentikasi akan mengotori katalog.
- Kapan penghitung waktu 3 detik dimulai? Di sini penghitung waktu dimulai ketika control plane menerima status READY ke DRAINING atau not-ready. Jika aplikasi membeku sebelum melapor, deteksi hard-failure yang akan menanganinya.
- Berapa banyak penghapusan keliru (false removals) yang dapat ditoleransi oleh target 15 detik? Tiga kegagalan berturut-turut mengurangi kesalahan akibat packet-loss sesaat, tetapi interval 5 detik ditambah timeout menghabiskan hampir seluruh anggaran waktu. Tingkat kesalahan pasif, kapasitas cadangan regional, dan jendela konfirmasi (confirmation windows) dapat mengubah pilihan ini.
- Apakah pemanggil membutuhkan alamat instans atau alamat layanan yang stabil? DNS ditambah platform load balancing adalah yang paling sederhana untuk VIP yang stabil. Proxy atau client discovery lebih cocok ketika pemanggil memerlukan metadata versi, region, atau shard.
- Apakah pemadaman control-plane bersifat fail open atau fail closed? Layanan internal biasa dapat melanjutkan dari snapshot yang terakhir diketahui. Pencabutan keamanan (security revocation) dan isolasi ketat tidak boleh bergantung pada cache discovery yang basi; lapisan identitas dan otorisasi independen harus menolaknya.
- Apakah failover lintas-region otomatis diizinkan? Pembacaan stateless dapat melakukan failover berdasarkan kebijakan. Residensi data, status single-writer, atau biaya lintas-region yang tinggi harus secara eksplisit membatasi kumpulan target.
Jawaban 30 Detik
“Saya akan membangun control plane regional dan data plane lokal. Orchestrator atau agen terautentikasi menulis instans ke katalog ter-shard dengan status STARTING, READY, DRAINING, UNHEALTHY, dan EXPIRED. Hanya status READY yang dapat dirutekan. Graceful shutdown memasuki DRAINING sebelum koneksi dikosongkan (drain). Leader regional mengurutkan perubahan dengan revisi monotonik. Lapisan distribusi mendorong delta ke 5.000 proxy node, dan proxy mengambil full snapshot jika mendeteksi adanya celah revisi (revision gap).
Request bisnis menggunakan proxy lokal atau VIP yang stabil dan tidak pernah menanyakan registry secara sinkron. Selama pemadaman, proxy mempertahankan snapshot terakhir dan mengeluarkan sementara endpoint yang buruk menggunakan connection timeout, retry terbatas, dan kesalahan pasif. Kesehatan memisahkan sinyal startup, readiness, liveness, dan pasif. Probe aktif 5 detik dengan 3 kegagalan menargetkan deteksi crash sekitar 15 detik. Saya melengkapinya dengan injeksi kegagalan (fault injection) untuk rollout, partisi, watch yang terputus, badai koneksi ulang, dan probe yang buruk, sembari mengukur latensi penghapusan, request basi, dan konvergensi.”
Pembahasan Mendalam Langkah demi Langkah
Langkah 1: Tentukan model data dan state machine
Kunci katalog mencakup setidaknya namespace, nama layanan, dan nama port sehingga environment dan protokol tidak saling bertabrakan. Sebuah endpoint berisi ID instans yang stabil, alamat, region, zone, versi, weight, label kemampuan (capability labels), status, kedaluwarsa lease, dan revisi. Hanya dimensi label yang telah ditentukan sebelumnya yang diizinkan; data arbitrer dengan kardinalitas tinggi tidak boleh berada di discovery plane.
State machine membawa lebih banyak makna daripada satu nilai boolean healthy. STARTING tidak menerima traffic. READY menerima traffic baru. DRAINING menghentikan request baru sementara koneksi yang ada diselesaikan. UNHEALTHY mencerminkan keputusan kegagalan aktif atau pasif. EXPIRED berarti lease tidak diperbarui. Setiap transisi mencatat alasan, sumber, dan revisi monotoniknya sehingga pembaruan yang tidak berurutan dapat diaudit.
Pembaruan untuk satu endpoint di-deduplikasi berdasarkan ID instans dan start generation. Lease yang tertunda dari proses lama tidak dapat membangkitkan kembali alamat yang telah diganti. Jika orchestrator bersifat otoritatif, controller memantau siklus hidup yang diinginkan dan kesiapan aktual. Dengan registrasi mandiri, penulis mengautentikasi sebagai beban kerja dan hanya dapat memodifikasi catatan layanan dan instans miliknya sendiri.
Langkah 2: Pilih pola discovery tanpa menduplikasi kompleksitas ke setiap bahasa
DNS ditambah VIP yang stabil berfungsi ketika pemanggil hanya membutuhkan nama layanan dan platform telah menangani endpoint serta kesehatan. Mengembalikan alamat instans secara langsung melalui DNS memang sederhana, tetapi TTL menciptakan kompromi antara beban kueri dan waktu data menjadi basi. Klien yang mengabaikan TTL pendek memperbesar risiko tersebut.
Client-side discovery dapat memilih berdasarkan versi, zone, dan beban, tetapi setiap bahasa harus mengimplementasikan penanganan watch, caching, balancing, retry, dan upgrade yang aman. Karena masalah ini melibatkan pemanggil multibahasa (polyglot), prioritaskan server-side discovery melalui proxy node-lokal atau proxy platform yang ada. Aplikasi memanggil alamat lokal yang stabil, dan proxy mengelola kumpulan endpoint serta pemilihan backend. Satu lompatan (hop) lokal tambahan memberikan semantik yang seragam dan upgrade yang cepat.
Jika setiap beban kerja sudah berjalan di Kubernetes, Service, DNS, dan EndpointSlice biasanya mencakup discovery dasar. Membangun registry lain hanya akan menduplikasi platform. Buat control plane terpisah hanya untuk kebutuhan lintas-VM, lintas-kluster, perutean tingkat lanjut, atau kebijakan nyata, dan prioritaskan penggunaan data kebenaran endpoint dari orchestrator.
Langkah 3: Urutkan penulisan sambil mengizinkan pembacaan data basi
Deploy 3 atau 5 replika katalog per region, menggunakan consensus leader untuk registrasi dan transisi status. Lakukan sharding berdasarkan service key atau tenant sehingga satu leader global tidak menangani seluruh 100.000 instans. Jangan mereplikasi setiap penulisan secara sinkron lintas region; partisi jarak jauh tidak boleh memblokir region yang sehat. Lapisan global menyinkronkan kebijakan layanan dan tujuan failover yang diizinkan.
Penulisan yang berhasil berarti katalog regional telah menerima suatu revisi. Hal itu tidak berarti setiap proxy telah melihatnya. Distributor mendorong delta yang berurutan. Proxy menyimpan snapshot lengkap dan revisi terakhirnya secara persisten. Proxy menerapkan revisi yang berurutan, tetapi mengambil full snapshot untuk layanan tersebut jika mendeteksi celah (gap), gagal validasi, atau terhubung kembali setelah masa retensi delta kedaluwarsa. Penggantian snapshot bersifat atomik sehingga data lama dan baru tidak pernah bercampur.
Jalur pembacaan menukar bounded staleness demi ketersediaan (availability). Proxy mencatat usia snapshot, kontak terakhir dengan control-plane, dan watch lag. Proxy memberikan peringatan jika melebihi anggaran usia normal tetapi tetap menggunakan kumpulan data terakhir selama pemadaman 10 menit yang ditentukan. Jika setiap endpoint yang diketahui gagal, proxy mengembalikan hasil no-backend eksplisit daripada secara diam-diam melewati kebijakan ke region mana pun.
Langkah 4: Pisahkan penarikan sengaja dari deteksi hard-failure
Untuk graceful shutdown, aplikasi pertama-tama menarik status kesiapannya (readiness). Katalog memasuki status DRAINING, dan proxy berhenti memilih endpoint tersebut setelah propagasi. Proses menunggu selama periode pengosongan koneksi (connection-drain) maksimum sebelum keluar. Aplikasi juga berhenti menerima pekerjaan baru karena propagasi discovery tidak instan; proxy lama atau koneksi yang berumur panjang mungkin masih memegang alamatnya.
Hard failure tidak mengirimkan sinyal. Dengan probe aktif setiap 5 detik dan penghapusan setelah 3 kegagalan berturut-turut, kegagalan tepat setelah probe yang berhasil dapat menghabiskan hampir 15 detik hanya dalam proses sampling, sebelum probe timeout dan propagasi. Memenuhi p99 15 detik memerlukan penganggaran timeout, jitter scheduler, dan pengiriman secara bersamaan atau memperpendek interval. Proxy dapat mengeluarkan sementara suatu endpoint setelah penolakan koneksi, timeout, atau tingkat kesalahan lokal yang tinggi, tetapi masalah jaringan pada satu pemanggil tidak boleh membatalkan pendaftarannya secara global.
Startup, readiness, dan liveness juga merupakan hal yang berbeda. Startup melindungi inisialisasi yang lambat. Kegagalan readiness menghentikan traffic. Kegagalan liveness memicu restart. Menempatkan database bersama dalam tes liveness setiap instans dapat me-restart seluruh armada layanan selama pemadaman database dan memperparah beban. Dependensi kritis dapat memengaruhi kesiapan, tetapi pemeriksaan memerlukan timeout pendek, jitter, dan perlindungan kapasitas untuk menghindari badai probe.
Langkah 5: Hitung beban penulisan, perubahan, dan fanout
Jika 100.000 instans memperbarui langsung setiap 10 detik, kondisi stabil (steady state) adalah 10.000 pembaruan per detik. Lebih baik gunakan watch dari orchestrator daripada heartbeat per instans, atau kumpulkan pembaruan melalui agen node dengan jitter acak. Kedaluwarsa lease tetap menjadi jaring pengaman untuk catatan yang ditinggalkan, bukan jalur penarikan normal.
Mengganti 10.000 endpoint dalam 2 menit rata-rata menghasilkan sekitar 83 penambahan dan 83 penghapusan per detik, atau sekitar 167 perubahan keanggotaan. Mengirimkan setiap perubahan secara independen ke seluruh 5.000 proxy node dapat menciptakan hingga sekitar 835.000 pengiriman per detik. Langganan nyata memfilter ke layanan yang dibutuhkan setiap proxy, menggabungkan (coalesce) perubahan layanan yang sama dalam jendela waktu singkat, dan menggunakan distribusi hierarkis. Penggabungan ini tidak boleh mengubah SLO penarikan 3 detik menjadi batch satu menit.
Full snapshot juga membutuhkan alokasi anggaran. Dengan ukuran serialisasi ilustratif 256 byte per endpoint, snapshot 100.000 endpoint global berukuran sekitar 24,4 MiB. Proxy normal hanya mengambil layanan yang dilanggan, bukan katalog global. Koneksi ulang menggunakan exponential backoff dengan jitter, dan distributor menyimpan log delta pendek sehingga 5.000 proxy tidak meminta full snapshot secara bersamaan setelah pemulihan.
Langkah 6: Tentukan batas wilayah (region) dan keamanan
Secara default, suatu instans mendaftar di region lokalnya, dan panggilan memprioritaskan endpoint READY di region dan zone yang sama. Jika katalog regional kehilangan kuorum, ia menolak penulisan baru sementara proxy lokal tetap membaca cache mereka. Region lain tidak boleh menandai endpoint tersebut sehat atau menimpa data lokal berdasarkan probe jarak jauh.
Kebijakan layanan menyatakan apakah perutean lintas-region diizinkan, perilaku read-only atau writable, urutan target, batas kapasitas, dan batasan data. Kebijakan eksplisit memicu failover global. Pembacaan stateless dapat beralih dengan cepat; proxy untuk database single-writer harus terlebih dahulu menetapkan transfer kepemilikan. Discovery mengembalikan alamat kandidat dan tidak dapat menggantikan protokol konsistensi bisnis.
Registrasi, deregistrasi, dan watch memerlukan identitas beban kerja dan hak istimewa terendah (least privilege), dengan perubahan katalog tercatat dalam audit log. Proxy mengautentikasi control plane, dan layanan sensitif dapat menggabungkan discovery dengan mutual TLS. Label endpoint bukanlah klaim otorisasi yang tepercaya; pemanggil tetap memvalidasi identitas layanan dan izin pada saat koneksi atau request.
Langkah 7: Verifikasi dengan timeline dan injeksi kegagalan
Pertama, uji rolling replacement. Instans lama menarik kesiapannya. Catat saat katalog menerima revisi, proxy menerapkannya, request baru terakhir tiba, dan proses keluar. Instans baru masuk ke kumpulan hanya setelah startup dan readiness. Pastikan p99 propagasi penarikan aktif di bawah 3 detik, penyelesaian pekerjaan yang sedang berjalan (in-flight), dan nol traffic ke instans yang belum siap (not-ready).
Kemudian matikan proses tanpa deregistrasi dan verifikasi bahwa probe 5 detik, ambang batas kegagalan, dan distribusi secara bersama-sama memenuhi p99 15 detik. Injeksikan satu kegagalan jaringan proxy, kegagalan seluruh node, follower katalog yang tertinggal, pergantian leader, kehilangan kuorum regional, celah delta, snapshot yang rusak, dan pemadaman control-plane selama 10 menit. Pemulihan terhubung kembali dengan jitter dan tidak menyebabkan serbuan full snapshot (stampede).
Metrik produksi mencakup tingkat registrasi dan pembaruan, latensi penulisan katalog, jumlah READY per layanan, flapping kesehatan, latensi probe, watch lag, usia snapshot, celah revisi, fallback full-snapshot, koneksi ulang proxy, request baru ke endpoint yang dihapus, kegagalan koneksi ke endpoint basi, dan hasil no-backend. Timeline traffic membuktikan propagasi; dasbor control-plane yang berwarna hijau saja tidak cukup membuktikannya.
Contoh Jawaban yang Kuat
“Saya memisahkan data kebenaran registrasi, keputusan kesehatan, pengiriman discovery, dan perutean request. Grup konsensus regional menerima perubahan instans yang terautentikasi. Setiap catatan memiliki service key, ID instans, start generation, alamat, region, versi, status, lease, dan revisi. Hanya READY yang masuk ke kumpulan yang dapat dirutekan. Shutdown berpindah ke DRAINING, menghentikan traffic baru, melakukan drain, lalu keluar. Hard failure menggunakan probe dan kedaluwarsa lease. Kesalahan pasif mengeluarkan endpoint secara lokal dan tidak langsung menjadi kebenaran global.
Karena pemanggil menggunakan banyak bahasa, saya tidak akan membuat setiap proses memantau registry. Lima ribu proxy node hanya berlangganan layanan yang dibutuhkan, menyimpan snapshot lengkap dan revisi monotonik secara persisten, menerapkan delta yang berurutan, dan mengambil ulang satu layanan jika terjadi celah (gap). Request menggunakan proxy lokal dan tidak pernah menanyakan control plane secara sinkron. Selama pemadaman 10 menit, proxy menggunakan endpoint yang terakhir diketahui dengan connection timeout yang pendek, retry terbatas, dan pengeluaran lokal. Instans baru tidak terlihat dan alamat lama mungkin basi, sehingga biaya-biaya tersebut menjadi metrik eksplisit.
Seratus ribu instans yang memperbarui setiap 10 detik akan menghasilkan 10.000 penulisan per detik, jadi saya lebih memilih watch orchestrator atau agregasi node. Mengganti 10.000 endpoint dalam 2 menit menghasilkan sekitar 167 perubahan penambahan dan penghapusan per detik. Filter berdasarkan langganan, gabungkan secara singkat, dan distribusikan secara hierarkis tanpa menghabiskan anggaran penarikan 3 detik. Melakukan probe setiap 5 detik dan membutuhkan 3 kegagalan sudah mendekati 15 detik, sehingga timeout dan propagasi merupakan bagian dari anggaran tersebut.
Saya memverifikasi melalui timeline traffic: tidak ada request baru dalam 3 detik setelah penarikan diterima, dan endpoint yang mengalami hard crash meninggalkan kumpulan kandidat dalam 15 detik. Traffic yang ada berlanjut selama pergantian leader, partisi regional, dan penghentian control-plane 10 menit. Terakhir, 5.000 proxy terhubung kembali dengan jitter, mengisi celah revisi, dan melakukan konvergensi tanpa membebani katalog secara berlebihan.”
Kesalahan Umum
- Mengueri registry sebelum setiap request → penundaan atau kegagalan control-plane masuk ke jalur bisnis → cache endpoint berversi secara lokal dan terima perubahan di latar belakang.
- Menggunakan satu nilai boolean
healthy→ semantik startup, penerimaan traffic, draining, dan restart bercampur menjadi satu → gunakan state machine eksplisit dengan sumber transisi. - Me-restart saat terjadi kegagalan readiness → pemadaman di downstream dapat me-restart seluruh armada layanan → readiness menghapus traffic; liveness hanya mencakup kegagalan lokal yang tidak dapat dipulihkan.
- Mengasumsikan DNS TTL yang pendek menghilangkan data basi → cache klien, propagasi, dan deteksi tetap menciptakan celah waktu sementara beban kueri meningkat → ukur kompromi TTL dan pertahankan ketahanan data-plane.
- Mengizinkan registrasi mandiri tanpa autentikasi → endpoint yang salah atau berbahaya dapat menerima traffic internal → gunakan kebenaran orchestrator atau identitas beban kerja yang dibatasi.
- Membuat setiap proxy berlangganan ke katalog global → deployment dan koneksi ulang menciptakan badai fanout dan snapshot → filter berdasarkan layanan, distribusikan secara hierarkis, buat versi untuk delta, dan terapkan jitter pada koneksi ulang.
- Mereplikasi setiap heartbeat secara kuat lintas region → latensi jarak jauh atau partisi memblokir region yang sehat → urutkan penulisan secara regional dan sinkronkan hanya kebijakan serta metadata failover yang diizinkan.
- Menganggap keberhasilan discovery sebagai keberhasilan request → suatu endpoint dapat gagal segera setelah pencarian → protokol panggilan tetap membutuhkan connection timeout, retry terbatas, circuit breaking, dan idempotensi.
- Memeriksa setiap dependensi untuk kesehatan → satu pemadaman bersama menghapus semua instans sekaligus → hanya periksa kondisi penerimaan traffic yang kritis dengan timeout pendek dan jitter.
Pertanyaan Lanjutan dan Jawaban
Lanjutan 1: Mengapa tidak membiarkan seluruh 100.000 instans menggunakan client-side discovery secara langsung?
Client-side discovery menghilangkan satu lompatan (hop) dan memungkinkan perutean yang detail, tetapi menduplikasi watch, cache, perbaikan revisi, balancing, ejeksi, dan upgrade ke dalam setiap bahasa dan proses. Dengan tim multibahasa, proxy node mengurangi 100.000 koneksi klien menjadi sekitar 5.000 instans data-plane. Satu runtime matang tunggal dengan anggaran latensi yang sangat ketat mungkin membenarkan kewajiban penggunaan SDK, tetapi tetap memerlukan uji kesesuaian protokol dan upgrade yang dipaksakan.
Lanjutan 2: Mengapa aman menggunakan endpoint lama selama pemadaman control-plane?
Snapshot terakhir memungkinkan instans yang bertahan untuk tetap beroperasi, dengan konsekuensi kehilangan penambahan baru, penarikan, dan perubahan failover. Proxy mengekspos usia snapshot, menggunakan timeout pendek dan kesalahan pasif untuk mengurangi panggilan ke alamat mati, serta membatasi retry. Pencabutan keamanan tidak boleh menunggu propagasi cache discovery; lapisan identitas dan otorisasi independen harus bersifat fail-closed. Setelah usia snapshot maksimum khusus layanan berakhir, kebijkannya dapat mengalami degradasi atau menolak request daripada menerapkan satu aturan global.
Lanjutan 3: Apakah probe 5 detik dan 3 kegagalan benar-benar memenuhi 15 detik?
Belum tentu. Kegagalan yang terjadi segera setelah pemeriksaan yang berhasil dapat menggunakan hampir 15 detik hanya untuk tiga sampel yang gagal, dan timeout, scheduling jitter, serta propagasi endpoint akan menambah waktu tersebut. Untuk memenuhi p99, perpendek interval, pertahankan timeout di bawah interval tersebut, dan gunakan penolakan koneksi atau sinyal pasif lainnya untuk ejeksi lokal yang lebih cepat. Injeksi kegagalan harus mengukur distribusi dari request terakhir yang berhasil hingga rute baru terakhir; mengalikan nilai konfigurasi bukanlah sebuah bukti.
Lanjutan 4: Mengapa rolling deployment membutuhkan DRAINING alih-alih penghapusan langsung?
Penghapusan langsung hanya menghentikan pemanggil yang telah melihat daftar baru. Tindakan ini tidak menangani cache lama, keep-alive, RPC panjang, atau pekerjaan yang sedang mengantre. DRAINING menghapus endpoint dari kandidat request baru sementara proses tetap berjalan selama periode drain yang dibatasi. Aplikasi juga berhenti menerima pekerjaan baru, dan timeout panggilan disesuaikan dengan toleransi terminasi platform (platform termination grace). Verifikasi melacak request baru terakhir, penyelesaian in-flight, dan terminasi paksa.
Lanjutan 5: Haruskah region lain menerima registrasi ketika satu region kehilangan kuorum?
Region lain tidak boleh secara otomatis mengambil alih kepemilikan data kebenaran instans dari region tersebut. Tampilan lintas-region dapat salah mengira partisi jaringan sebagai kegagalan instans total, dan dua control plane dapat menerima status yang saling bertentangan. Region yang kehilangan kuorum menghentikan penulisan katalog sementara proxy tetap membaca cache. Lapisan global hanya merutekan panggilan baru sesuai dengan kebijakan failover layanan yang telah dideklarasikan. Saat pemulihan, revisi dan start generation merekonsiliasi status sehingga lease yang kedaluwarsa tidak dapat menimpa instans yang lebih baru.