Petunjuk dan use case
Desain layanan feature flag yang memungkinkan tim mengaktifkan/menonaktifkan fitur tanpa melakukan deploy ulang, mendukung penargetan lingkungan, segmen pengguna, dan persentase, serta tetap aman saat layanan konfigurasi tidak tersedia. Pertanyaan lanjutan mungkin mencakup evaluasi latensi rendah, auditabilitas, persetujuan, rollback, dan ketersediaan multi-region.
Ini cocok untuk peran platform engineering, backend, dan desain sistem. Pustaka wawancara publik menggambarkan petunjuk serupa dengan skala jutaan evaluasi per detik dan latensi yang sangat rendah; sebuah laporan wawancara platform engineering yang dipublikasikan menekankan control plane, data plane, dan batas peluncuran yang aman. Fokuslah pada keputusan-keputusan tersebut daripada menyebutkan komponen secara acak.
Yang dievaluasi oleh pewawancara
- Apakah Anda memisahkan sistem konfigurasi yang jarang ditulis dan sering dibaca menjadi control plane dan data plane.
- Apakah peluncuran persentase stabil, sehingga pengguna tidak berpindah versi antar-permintaan.
- Apakah nilai default, masa kedaluwarsa, kill switch, dan rollback membatasi blast radius dari konfigurasi yang buruk.
- Apakah Anda menjelaskan pertukaran (trade-off) antara konsistensi, latensi, auditabilitas, dan isolasi tenant.
Klarifikasi sebelum menjawab
Tanyakan apakah evaluasi berjalan di SDK, edge node, atau layanan pusat; apakah targetnya adalah satu juta evaluasi per detik; apakah penargetan menggunakan pengguna, organisasi, wilayah, atau sesi; seberapa cepat perubahan harus berlaku; dan apa nilai default aman yang dimiliki setiap flag. Klarifikasi juga apakah eksperimen, penonaktifan darurat, dan persetujuan diperlukan.
Jawaban 30 detik
Saya akan menentukan control plane untuk pembuatan flag, aturan, versi, persetujuan, dan log audit, lalu data plane tempat SDK atau cache edge mengambil snapshot yang dipublikasikan dan mengevaluasinya secara lokal. Aturan mencocokkan lingkungan dan segmen target; peluncuran persentase menggunakan hash subjek yang stabil. Rilis secara bertahap, pantau alarm, dan lakukan rollback secara otomatis. Jika control plane tidak aktif, gunakan snapshot kedaluwarsa terbatas (bounded-stale) atau nilai default aman yang sesuai dengan risiko.
Solusi langkah demi langkah
Model data inti
Sebuah flag membutuhkan key, lingkungan, nilai default, aturan yang berurutan, versi, waktu publikasi, masa kedaluwarsa, dan metadata audit. Aturan dapat menargetkan organisasi, wilayah, atribut pengguna, atau bucket persentase. Urutan aturan harus eksplisit: kecocokan pertama yang menang. Validasi sintaksis, tipe data, dan konflik semantik sebelum publikasi.
Control plane dan data plane
Control plane menangani penulisan, persetujuan, pembuatan versi, audit, dan publikasi. Data plane hanya membaca snapshot yang dipublikasikan dan mengevaluasinya. SDK memprioritaskan cache dalam memori dan menyegarkannya melalui polling, stream, atau notifikasi. Dengan demikian, pemadaman singkat pada control plane tidak akan membebani setiap permintaan bisnis dengan panggilan jaringan.
Peluncuran stabil dan rilis aman
Hash flagKey + stableSubjectId + salt dan petakan ke bucket 0 hingga 9999. Seiring peningkatan eksposur dari 1% ke 5%, 25%, 50%, dan 100%, pengguna yang telah diizinkan tetap menggunakan versi yang sama. Validasi aturan dan dependensi sebelum rilis; pantau kesalahan, tail latency, dan metrik bisnis selama rilis. Lakukan rollback ke versi terverifikasi terakhir saat alarm berbunyi.
~~~text evaluate(flag, context, snapshot): rules = snapshot[flag].rules[context.environment] for rule in rules: if matches(rule.targeting, context): if rule.percentage is absent: return rule.value bucket = hash(flag.key + context.stableSubject + rule.salt) % 10000 if bucket < rule.percentage * 100: return rule.value return snapshot[flag].safeDefault ~~~
Trade-off utama
| Pilihan | Manfaat | Biaya | Kapan digunakan |
|---|---|---|---|
| Evaluasi terpusat | Satu sumber aturan dan pembaruan cepat | Ketergantungan jaringan per permintaan | Throughput rendah atau konsistensi ketat |
| Evaluasi SDK lokal | Latensi rendah dan isolasi control plane | Distribusi lebih kompleks dan penyimpanan aman | QPS tinggi dengan keusangan terbatas (bounded staleness) |
| Evaluasi edge | Respons lokal dan ketahanan regional | Distribusi dan pembatalan lebih sulit | Lalu lintas global dan isolasi regional |
AWS AppConfig mendokumentasikan versi, lingkungan, strategi deployment, validator, penargetan bertahap, dan rollback berbasis alarm. Hal tersebut mendukung penanganan alur kerja rilis sebagai bagian dari sistem; ini tidak mengharuskan menyalin setiap komponen AWS ke dalam produk lain.
Contoh jawaban
Saya akan membagi layanan menjadi control plane dan data plane. Control plane menyimpan definisi flag, aturan, versi, dan catatan audit. Setelah validasi dan persetujuan, ia menghasilkan snapshot terpublikasi yang tidak dapat diubah (immutable). SDK atau edge node menyimpan snapshot tersebut dalam cache dan mengevaluasinya secara lokal, menghindari panggilan ke layanan pusat pada setiap permintaan.
Peluncuran persentase menggunakan pengidentifikasi subjek yang stabil, sehingga pengguna tetap menggunakan satu versi saat eksposur meningkat dari 1% menjadi 25%. Setiap flag memiliki nilai default yang aman dan kebijakan kedaluwarsa. Jika aplikasi tidak dapat melakukan penyegaran, aplikasi akan menggunakan snapshot terakhir yang belum kedaluwarsa atau menonaktifkan perilaku berisiko sesuai kebijakan flag. Perluas secara bertahap sambil memantau tingkat kesalahan, latensi P99, dan metrik bisnis, lalu lakukan rollback secara otomatis saat ada alarm. Kill switch jalur pendek dapat menyediakan penonaktifan darurat, dengan biaya eksplisit untuk pembatalan cache, otorisasi, dan auditabilitas.
Kesalahan umum
- Memanggil layanan konfigurasi pusat pada setiap permintaan dan menjadikannya titik kegagalan tunggal (single point of failure) untuk latensi.
- Menggunakan angka acak untuk penargetan persentase, menyebabkan satu pengguna berpindah versi antar-permintaan.
- Mengabaikan data versi, kedaluwarsa, dan audit, sehingga mustahil menjelaskan siapa yang memublikasikan apa dan kapan.
- Hanya mendesain API on/off tanpa validasi, rollback, atau nilai default yang aman.
- Mencampuradukkan konsistensi eventual, jendela keusangan cache, dan penonaktifan darurat tanpa kebijakan risiko yang terpisah.
Pertanyaan lanjutan dan tanggapan
Bagaimana Anda menjaga pengalaman pengguna tetap konsisten di seluruh instance?
Semua instance menggunakan pengidentifikasi subjek stabil, kunci flag, dan salt yang sama, serta mengekspos versi snapshot. Jangan pernah mengelompokkan ke dalam bucket berdasarkan ID permintaan acak. Untuk lalu lintas anonim, gunakan pengidentifikasi sesi persisten dan tentukan masa berlakunya.
Apa yang terjadi saat layanan konfigurasi mati?
Data plane terus melayani snapshot terakhir yang belum kedaluwarsa. Setelah TTL-nya habis, ia mengikuti kebijakan risiko flag dan mengembalikan nilai default yang aman. SDK harus mengekspos usia snapshot, kegagalan penyegaran, dan sumber evaluasi sehingga perilaku data usang dapat terlihat.
Bagaimana cara menonaktifkan fitur berbahaya?
Sediakan kill switch yang dilindungi izin dengan jalur yang lebih pendek daripada peluncuran biasa untuk flag berisiko tinggi. Catat operator, alasan, versi, dan cakupan yang terpengaruh bahkan dalam keadaan darurat.
Bagaimana Anda mencegah aturan penargetan yang buruk?
Jalankan pemeriksaan skema, tipe data, konflik, dan cakupan sebelum publikasi. Evaluasi aturan terhadap data uji (fixtures) offline sehingga setiap target mencapai cabang yang diharapkan. Uji perubahan berisiko tinggi di lingkungan shadow atau lingkungan yang sangat kecil terlebih dahulu.
Bagaimana Anda menangani multi-region?
Replikasi snapshot yang dipublikasikan berdasarkan wilayah sambil mempertahankan pembacaan data plane lokal. Sertakan versi dan waktu publikasi di setiap snapshot, pantau ketimpangan versi regional, dan beri peringatan saat suatu wilayah tidak dapat memperbarui. Lanjutkan penggunaan snapshot aman sebelumnya selama jeda tersebut.
Kapan Anda harus menghindari feature flag?
Konfigurasi statis murni, migrasi satu kali, atau keputusan otorisasi yang memerlukan konsistensi transaksional mungkin tidak cocok berada dalam sistem flag. Jika jumlah flag, kompleksitas aturan, dan utang kedaluwarsa meningkat, tetapkan pemilik, tanggal kedaluwarsa, dan metrik pembersihan sehingga aturan runtime tidak menggantikan disiplin rilis yang normal.