Permintaan dan use case
Ini adalah masalah perancangan ketersediaan multi-region. Jawaban yang baik menjelaskan keputusan lalu lintas, propagasi sinyal kesehatan, batasan kapasitas dan data selama kegagalan, serta bagaimana failover dan failback dilatih.
Hal yang dievaluasi pewawancara
- Apakah DNS, edge proxy, dan perutean aplikasi memiliki tanggung jawab dan skala waktu yang berbeda.
- Apakah kesehatan menggunakan sinyal berlapis dari banyak pengamat, bukan hanya satu endpoint.
- Apakah kapasitas failover, koneksi, dan rate limit dihitung.
- Apakah data stateful memiliki kepemilikan tulis yang eksplisit, replikasi lag, dan batasan regional.
- Apakah split brain, flapping, dan kaskade failback terkendali.
- Apakah bukti RTO, RPO, SLO, dan simulasi ditentukan.
Klarifikasi sebelum menjawab
- Region mana, puncak lalu lintas, dan model kegagalan single-region apa yang berlaku?
- Apa saja batasan RTO, RPO, residensi, dan kepatuhan?
- Apakah permintaan sebagian besar berupa pembacaan stateless, atau mencakup penulisan dan koneksi jangka panjang?
- Apakah pengalihan dilakukan oleh DNS, Anycast, edge proxy, atau service mesh?
- Alur perjalanan pengguna dan dependensi mana yang harus dicakup oleh health check?
- Apa yang diwajibkan oleh TTL DNS klien, migrasi koneksi, dan jendela failback?
Kerangka jawaban 30 detik
“Saya akan mendefinisikan kegagalan regional, beban puncak, dan RTO/RPO terlebih dahulu. DNS atau titik masuk edge dapat memilih kandidat berbasis latensi, tetapi hanya region yang lolos pemeriksaan kesehatan berlapis dengan kapasitas cadangan yang menerima lalu lintas. Selama kelebihan beban, kami membatasi laju (rate-limit) dan mendegradasi layanan berdasarkan prioritas agar region cadangan tetap bertahan. Operasi tulis mengikuti batas kepemilikan data dengan jeda replikasi dan semantik percobaan ulang yang eksplisit. Pengontrol yang teredam menggeser bobot secara bertahap, dan kami melatih, melakukan pemanasan (warm-up), serta memverifikasi metrik sebelum failback.”
Pembahasan mendalam langkah demi langkah
Langkah 1: Tentukan kegagalan dan sasaran. Nyatakan cakupan kegagalan region, dependensi, jaringan, dan control-plane, lalu kuantifikasi RTO, RPO, beban puncak, dan tingkat degradasi.
Langkah 2: Pisahkan lapisan keputusan. DNS atau titik masuk global menangani pemilihan region secara garis besar; lapisan edge atau layanan menangani bobot langsung, koneksi, dan batas lokal. Jangan biarkan satu control-plane menanggung setiap tindakan kegagalan.
Langkah 3: Bangun sinyal kesehatan. Gabungkan probe dari berbagai lokasi, perjalanan pengguna penting, status dependensi, tingkat kesalahan, dan kapasitas. Jendela berturut-turut, jendela pemulihan, dan keputusan berbasis kuorum mengurangi terjadinya flapping.
Langkah 4: Lindungi kapasitas. Cadangkan ruang aman (headroom) failover dan tetapkan batas konkurensi, antrean, serta laju per region. Selama kegagalan, pangkas pekerjaan berprioritas rendah sebelum lalu lintas penting menyebabkan kegagalan beruntun.
Langkah 5: Tentukan batasan data. Jelaskan jeda replika, kepemilikan tulis, penanganan konflik, idempotency key, dan percobaan ulang lintas region. Perutean tidak dapat membuat operasi tulis yang tidak tersedia menjadi konsisten.
Langkah 6: Eksekusi failover. Pengontrol mencatat alasan, versi, dan persetujuan, menurunkan bobot region yang gagal, dan menggeser sebagian kecil kohort sebelum memperluasnya. Koneksi jangka panjang memerlukan backoff dan pemulihan sesi.
Langkah 7: Latih failback. Lakukan pemanasan pada region yang pulih, verifikasi metrik yang stabil serta pemeriksaan data, lalu lakukan failback. Injeksikan kegagalan regional, dependensi, dan control-plane secara teratur serta simpan bukti pengukuran RTO/RPO.
Contoh jawaban berkualitas tinggi
“Saya akan membagi setiap region menjadi lapisan masuk, layanan stateless, dan unit data. Titik masuk global memilih kandidat latensi, tetapi suatu region hanya menerima lalu lintas ketika pemeriksaan perjalanan dari berbagai lokasi, ambang batas kesalahan, dan ruang kapasitas terpenuhi. Pengontrol menerapkan waktu tunggu minimum (dwell time) dan cooldown, pertama-tama mengirimkan 5% ke cadangan. Jika konkurensi cadangan mencapai batasnya, sistem akan melindungi proses masuk (login) dan penulisan sambil menjeda laporan berprioritas rendah. Kepemilikan tenant menentukan lokasi penulisan; percobaan ulang lintas region membawa idempotency key dan memperlihatkan jeda replikasi. Latihan berkala memvalidasi RTO, RPO, keberhasilan koneksi ulang, dan pemeriksaan data baik untuk failover maupun failback.”
Kesalahan umum
- Hanya menggambar DNS dan dua region → kapasitas dan data terabaikan → tambahkan batasan pengontrol dan kepemilikan tulis.
- Menghapus region setelah satu kali probe gagal → lalu lintas mengalami flapping → gunakan jendela pengamatan, cooldown, dan beberapa sinyal.
- Mengasumsikan cadangan dapat menerima semua lalu lintas → failover membuatnya kelebihan beban → hitung ruang cadangan dan degradasi bertahap.
- Menganggap TTL sebagai waktu penyelesaian → klien masih menyimpan jawaban lama di cache → sertakan penundaan resolver, koneksi, dan edge.
- Menyebut active-active tanpa aturan konflik → penulisan tidak terdefinisi → nyatakan kepemilikan, replikasi, dan idempotensi.
Pertanyaan lanjutan dan tanggapan
Pertanyaan lanjutan 1: Bagaimana jika TTL DNS panjang?
Gunakan edge untuk perubahan bobot yang lebih cepat dan sertakan TTL, cache rekursif, serta masa pakai koneksi dalam anggaran RTO; jangan menjanjikan peralihan instan.
Pertanyaan lanjutan 2: Bagaimana jika health checking gagal?
Gunakan jalur kontrol independen dan probe dari berbagai lokasi, pantau kebaruan data, dan pertahankan status aman terakhir atau masuk ke mode manual yang terlindungi saat pemeriksaan kedaluwarsa.
Pertanyaan lanjutan 3: Bagaimana jika kapasitas cadangan tidak mencukupi?
Cadangkan dan hangatkan kapasitas, lalu terapkan rate-limit, degradasi, atau antrean berdasarkan prioritas. Buktikan batas maksimal single-region dengan uji beban.
Pertanyaan lanjutan 4: Bagaimana cara mencegah flapping?
Gunakan ambang batas kegagalan dan pemulihan yang berbeda, waktu tunggu minimum, cooldown, dan persetujuan, dengan alasan yang dicatat untuk setiap perubahan bobot.
Pertanyaan lanjutan 5: Bagaimana cara menangani konflik penulisan lintas region?
Tetapkan kepemilikan berdasarkan tenant atau key dan gunakan kondisi versi atau idempotensi. Jika multi-writer diperlukan, tentukan aturan konflik dan data yang tidak dapat digabungkan.
Pertanyaan lanjutan 6: Bagaimana Anda membuktikan bahwa sistem ini berfungsi?
Latih kegagalan regional, dependensi, jaringan, dan control-plane serta ukur RTO, RPO, tingkat kesalahan, kapasitas yang dipulihkan, koneksi ulang, dan pemeriksaan data.
Pertanyaan lanjutan 7: Kapan sebaiknya Anda menghindari multi-region?
Jika residensi, semantik replikasi, kemampuan operasional, atau biaya tidak dapat memenuhi target, gunakan desain single-region yang teruji dengan disaster recovery terlebih dahulu. Multi-region bukanlah pilihan otomatis.