Wawancara Desain Sistem: Menjaga Stabilitas Bucket Persentase Feature Flag

Konteks dan arahan

Pertanyaan ini mengisolasi jalur utama (hot path) evaluasi feature flag. Administrasi, persetujuan, dan platform yang lebih luas merupakan masalah desain terpisah. Konfigurasi menyebar secara asinkron dan pemanggil menggunakan SDK dalam beberapa bahasa, namun pengguna harus menerima varian yang dapat dijelaskan dan direproduksi. Asumsikan evaluasi in-process di sisi server dengan aturan atribut dan peluncuran persentase.

Hal yang dievaluasi pewawancara

• Memisahkan konvergensi konfigurasi akhir (eventual convergence) dari bucketing yang stabil untuk satu identitas.
• Menentukan satu targetingKey, kontrak normalisasi, dan algoritma hash di seluruh SDK.
• Beralih antar snapshot yang tidak dapat diubah (immutable) dan berversi monoton, alih-alih mengekspos pembaruan parsial.
• Mengembalikan nilai default yang aman untuk konteks yang hilang, kesalahan tipe, flag yang tidak dikenal, dan konfigurasi yang usang.
• Membuktikan konsistensi dengan golden vector, evaluasi bayangan (shadow evaluation), dan metrik distribusi.

Klarifikasi sebelum menjawab

Tanyakan apakah stabilitas harus berlaku di seluruh perangkat, wilayah, dan bahasa SDK; bagaimana identitas anonim dipertahankan; dan apakah pengguna yang sudah berada dalam peluncuran 10% harus tetap disertakan saat persentasenya ditingkatkan. Tetapkan juga atribut penargetan mana yang sensitif, jendela propagasi yang dapat ditoleransi, dan apakah tombol darurat penonaktifan (emergency off switch) mengesampingkan aturan peluncuran reguler.

Kerangka jawaban 30 detik

Saya akan mengompilasi aturan ke dalam snapshot yang tidak dapat diubah dan memiliki versi, lalu mengevaluasinya di dalam setiap SDK. Alokasi persentase mengodekan targetingKey, flagKey, dan seed sebagai tuple kanonikal berbingkai panjang (length-framed) sebelum di-hash ke dalam rentang tetap. Untuk perubahan reguler, distribusikan snapshot yang tidak aktif, tunggu setiap wilayah penyedia layanan melaporkan kesiapan, lalu majukan satu generasi penetapan (assignment generation) pada control plane. Setiap sesi atau identitas permanen membawa generasi tersebut, dan instance penyedia layanan mempertahankan kedua snapshot selama masa tumpang tindih yang dibatasi, sehingga pergeseran jam lokal (clock skew) tidak dapat memindahkan pengguna antar versi aturan. Konteks yang hilang, tipe aturan yang tidak valid, atau konfigurasi usang akan mengembalikan default pemanggil disertai kode alasan. Golden vector lintas bahasa dan evaluasi bayangan memverifikasi keputusan yang identik.

Pembahasan mendalam langkah demi langkah

Mulailah dengan kontrak input. Setiap evaluasi sisi server memerlukan targetingKey yang tidak kosong. Lalu lintas anonim dapat menggunakan pengenal acak yang disimpan secara persisten, tetapi bukan nilai baru per permintaan. Tentukan pengodean string, huruf besar/kecil, spasi putih, angka, dan normalisasi stempel waktu (timestamp). Lakukan hash pada tuple UTF-8 berversi dan berawalan panjang daripada penggabungan mentah atau pembingkaian hanya dengan pembatas; jika tidak, batas bidang (field) dan karakter pembatas akan tetap ambigu di seluruh SDK.

Fungsi bucket dapat berupa bucket = hash(encodeTuple(v, seed, flagKey, targetingKey)) mod 100000. Setiap varian memiliki rentang berurutan yang tidak saling tumpang tindih. Meningkatkan dari 10% menjadi 20% akan memperluas rentang target, sehingga mempertahankan pengguna awal. Menyertakan flagKey mencegah flag yang tidak terkait memilih sampel yang berkorelasi sempurna. Mengubah seed secara sengaja akan mengacak ulang pengguna dan oleh karena itu memerlukan rilis yang diaudit.

Pencocokan aturan dan bucketing harus melihat satu snapshot yang tidak dapat diubah. Distributor mengirimkan snapshot tidak aktif yang lengkap dengan checksum dan versi monoton ke setiap wilayah penyedia layanan. Setelah semua wilayah memvalidasi dan mengonfirmasi kesiapan, control plane memajukan satu generasi penetapan yang otoritatif. Token sesi atau catatan identitas permanen membawa generasi tersebut; setiap wilayah mengevaluasi snapshot yang dirujuk secara tepat dan mempertahankan snapshot sebelumnya hingga masa berlaku penetapan berakhir. Instance yang tidak memiliki versi yang dirujuk akan berhenti melayani penetapan tersebut. Protokol ini bergantung pada transportasi versi alih-alih jam yang disinkronkan. Tombol pemutus darurat (kill switch) dapat secara eksplisit mengesampingkan persistensi demi keamanan namun tetap menjadi aturan berversi yang tercatat.

Kontrak evaluasi OpenFeature memungkinkan pemanggil menyediakan nilai default dan mengaitkan alasan kesalahan dengan evaluasi yang gagal. Bedakan antara flag yang hilang, ketidakcocokan tipe, kunci penargetan yang tidak ada, dan penyedia yang belum siap. Pertahankan metrik dengan kardinalitas rendah dan jangan cantumkan alamat email, pengenal perangkat, atau konteks evaluasi lengkap dalam log rutin.

Verifikasi memiliki tiga lapisan. Setiap SDK menjalankan input golden dan varian yang diharapkan yang sama, termasuk nilai kosong, pembatas, Unicode, dan kasus tabrakan batas bidang. Sebelum mengganti evaluator, lakukan evaluasi bayangan pada kedua mesin terhadap snapshot yang serupa dengan produksi dan lakukan simulasi wilayah yang gagal memenuhi kesiapan. Di lingkungan produksi, pantau pangsa varian, tingkat nilai default, usia snapshot, dan distribusi versi berdasarkan wilayah. Anomali distribusi adalah sebuah sinyal; keputusan individual harus tetap dapat direproduksi dari versi snapshot, ID aturan, dan bucket.

Contoh jawaban yang kuat

Setiap SDK hanya mengevaluasi snapshot yang telah divalidasi. Permintaan menyediakan targetingKey yang stabil; SDK melakukan hash pada tuple berversi dan berbingkai panjang yang terdiri dari seed, flagKey, dan targetingKey ke dalam salah satu dari 100.000 bucket tetap. Meningkatkan eksposur hanya akan memperluas rentang, sehingga anggota yang sudah ada tidak akan terlempar keluar.

Perubahan reguler mencapai setiap wilayah sebelum control plane memajukan generasi penetapan. Sesi atau identitas permanen kemudian membawa generasi tersebut, dan setiap wilayah menyimpan snapshot yang dirujuk selama masa berlaku penetapan. Oleh karena itu, permintaan lintas wilayah mengevaluasi satu versi aturan tanpa bergantung pada sinkronisasi jam. Instance yang tidak memiliki snapshot tersebut akan berhenti melayani penetapan. SDK menolak kemunduran (regression) dan mengembalikan nilai default pemanggil untuk konfigurasi yang usang atau konteks yang tidak valid. Penonaktifan darurat secara eksplisit mengesampingkan persistensi reguler dan berkonvergensi terlebih dahulu.

Kesalahan umum

• Memanggil layanan flag jarak jauh untuk setiap evaluasi dan menggantungkan ketersediaan permintaan padanya.
• Menggunakan hash bawaan dari runtime bahasa, yang mungkin berbeda antar proses atau SDK.
• Hanya melakukan hash pada ID pengguna, yang menciptakan sampel berkorelasi di semua flag.
• Memperbarui konfigurasi bidang demi bidang, sehingga mengekspos versi aturan dan bobot yang bercampur.
• Menetapkan permintaan secara acak ketika targetingKey tidak ada.
• Mencatat konteks evaluasi lengkap ke dalam log dan membocorkan atribut sensitif.

Pertanyaan lanjutan

Bisakah versi konfigurasi yang berbeda konsisten secara global?

Distribusi asinkron saja tidak dapat menjanjikan jendela konsistensi global dengan lebar nol. Perubahan reguler terlebih dahulu melewati kesiapan di setiap wilayah penyedia layanan; control plane kemudian memajukan satu generasi penetapan, yang dibawa oleh sesi atau identitas permanen pada setiap permintaan. Wilayah mempertahankan snapshot yang dirujuk hingga penetapan tersebut kedaluwarsa, dan instance yang tidak memilikinya akan keluar dari jalur penyedia layanan. Tombol penonaktifan darurat dapat mengesampingkan persistensi, memprioritaskan konvergensi cepat, dan memantau instance yang tertinggal.

Apa yang harus mengidentifikasi pengguna anonim?

Gunakan ID anonim acak yang disimpan di sisi klien dan dokumentasikan bahwa menghapus penyimpanan atau berganti perangkat akan menyebabkan penetapan ulang. Alamat IP bersifat bersama, tidak stabil, dan menimbulkan masalah privasi tambahan.

Bagaimana cara mengubah algoritma hash dengan aman?

Buat versi algoritma dan seed di dalam snapshot, lalu lakukan komputasi bayangan pada bucket lama dan baru untuk mengukur pergerakan. Pertahankan penetapan melalui pemetaan transisi jika persistensi diperlukan. Jika pengacakan ulang dapat diterima, tetap rilis secara eksplisit dengan snapshot rollback.

Bagaimana cara mendeteksi implementasi SDK yang salah?

Jalankan golden vector yang identik di setiap SDK dan laporkan versi algoritma dengan kardinalitas rendah, versi snapshot, serta jumlah varian agregat. Bekukan peningkatan konfigurasi untuk SDK yang menyimpang, pertahankan snapshot valid terakhirnya, dan perbaiki normalisasi atau hashing sebelum melanjutkan kembali.