Bagaimana Anda Mendesain Sistem Feature Flag?

Pertanyaan dan kapan menggunakannya

Desain sistem feature flag multi-tenant yang digunakan oleh 20.000 instans server di 3 wilayah. Sistem ini menyimpan 50.000 flag di seluruh proyek, menangani 5 juta evaluasi in-process per detik dengan tambahan latensi p99 kurang dari 1 milidetik, menyebarkan perubahan yang dipublikasikan dalam waktu 5 detik pada p99, dan terus melakukan evaluasi selama 15 menit pemadaman control plane. Sistem harus mendukung variasi bertipe, penargetan, rollout persentase deterministik, log audit, persetujuan, dan emergency off switch.

Angka-angka ini adalah asumsi wawancara, bukan tolok ukur produk. Asumsikan setiap runtime berlangganan paling banyak 500 flag yang relevan, rata-rata definisi flag yang diserialisasi adalah 2 KB, penulisan control plane mencapai puncaknya pada 100 per detik, dan aturan evaluasi sisi server mungkin berisi atribut sensitif. Pengiriman klien dan seluler, statistik eksperimen, serta layanan konfigurasi tujuan umum adalah tindak lanjut dan bukan persyaratan dasar.

Pertanyaan ini cocok untuk wawancara senior backend, platform, infrastruktur, release-engineering, dan desain sistem. Pelajaran yang dapat digunakan kembali adalah bahwa suatu sistem dapat membuat jalur manajemen diatur dengan ketat sambil menjaga jalur permintaan tetap lokal dan selalu tersedia. Pemisahan tersebut menentukan hampir setiap pilihan berikutnya.

Apa yang sedang dievaluasi oleh pewawancara

Sinyal pertama adalah apakah kandidat memisahkan deployment dari rilis dan control plane dari data plane. Dasbor dan basis data mengelola definisi flag. SDK aplikasi mengevaluasi rangkaian aturan berversi di dalam proses (in-process). RPC jarak jauh untuk setiap pemeriksaan flag akan membawa pemadaman manajemen dan latensi jaringan ke dalam setiap permintaan produk.

Sinyal kedua adalah presisi semantik. Evaluasi flag memerlukan flag key, environment, fallback bertipe, dan konteks evaluasi. Aturan berurutan, target eksplisit, alokasi persentase, dan aturan default harus memiliki prioritas deterministik. "Secara acak memberikan fitur kepada 10% permintaan" adalah salah ketika pengguna harus menerima pengalaman yang stabil di seluruh permintaan dan wilayah.

Sinyal ketiga adalah desain kegagalan (failure design). Keadaan last-known-good mempertahankan evaluasi selama pemadaman control plane, tetapi ini juga menjadikan konfigurasi usang (stale) sebagai risiko eksplisit. Jawaban yang kuat mendefinisikan perilaku startup, batas keusangan maksimum yang dapat diterima, pemulihan celah (gap recovery), penolakan pembaruan tidak valid, perilaku penonaktifan darurat, dan default yang berbeda untuk perubahan kosmetik versus jalur penulisan berbahaya.

Sinyal keempat adalah kepemilikan operasional. Pengeditan flag adalah perubahan produksi. Otentikasi, otorisasi, pemisahan environment, konkurensi optimistik, validasi, kebijakan persetujuan, catatan audit yang tidak dapat diubah (immutable), publikasi bertahap, rollback, kepemilikan, dan penghentian (retirement) semuanya termasuk dalam desain.

Pertanyaan untuk diklarifikasi sebelum menjawab

• Di mana evaluasi dilakukan? SDK sisi server dapat menerima rangkaian aturan lengkap dan mengevaluasinya secara lokal. Klien browser dan seluler tidak dapat menerima aturan penargetan sensitif dengan aman, sehingga mereka memerlukan model yang difilter atau dievaluasi dari jarak jauh.
• Apa yang diukur oleh target 5 detik? Definisikan dari publikasi yang berhasil hingga 99% instans server berlangganan yang sehat menerapkan versi tersebut. Instans offline dan klien di luar jendela kesegaran yang didukung memerlukan semantik terpisah.
• Apa kontrak fallback-nya? Jika SDK belum pernah memuat snapshot yang valid, SDK akan mengembalikan default bertipe yang disediakan oleh kode aplikasi. Setelah inisialisasi, SDK dapat menggunakan versi last-known-good selama jendela keusangan yang disepakati.
• Haruskah subjek yang sama tetap berada di kohort yang sama? Rollout persentase memerlukan targeting key yang stabil dan input hash deterministik. Sesi anonim memerlukan pengidentifikasi tahan lama jika stabilitas penting.
• Bisakah aturan memuat data sensitif? Lebih prioritaskan ID segmen dan atribut non-sensitif. Pengiriman sisi server dapat membawa aturan yang dilindungi; pengiriman browser tidak boleh mengekspos rahasia, allowlist internal, atau logika otorisasi.
• Seberapa penting tombol darurat pematian (emergency off switch)? SLO propagasi lima detik berguna tetapi tidak instan. Operasi yang benar-benar destruktif tetap memerlukan otorisasi sisi server dan kontrol keamanan independen.

Kerangka jawaban 30 detik

"Saya akan membagi platform menjadi control plane yang diatur dan evaluation plane lokal. Control plane memvalidasi, memberi versi, mengaudit, dan memublikasikan snapshot serta patch yang immutable. SDK server menyimpan aturan valid terakhir dan mengevaluasi target, aturan berurutan, rollout, dan default di dalam proses; sebelum inisialisasi atau pada keadaan tidak valid, SDK mengembalikan kode fallback. Rollout deterministik melakukan hash pada subject key yang stabil dengan environment, flag key, dan salt. Stream mendorong pembaruan dan polling memperbaiki celah, sehingga pemadaman control plane tidak pernah masuk ke jalur permintaan. Saya akan menguji propagasi, hasil lintas-SDK, stabilitas kohort, perilaku stale, dan rollback di bawah kondisi gangguan."

Solusi langkah demi langkah

Langkah 1: Ubah prompt menjadi kontrak eksplisit

Persyaratan fungsional meliputi membuat, mengedit, menyetujui, memublikasikan, menonaktifkan, dan menghentikan flag; mendefinisikan variasi boolean, string, angka, atau terstruktur; menargetkan subjek atau segmen; mengalokasikan persentase; dan mengembalikan detail evaluasi untuk debugging. Persyaratan non-fungsional meliputi p99 lokal di bawah 1 milidetik, propagasi p99 5 detik, hasil deterministik di seluruh wilayah, dan evaluasi berkelanjutan selama 15 menit pemadaman manajemen.

Definisikan tiga batasan sebelum menggambar komponen:

1. Versi yang dipublikasikan bersifat immutable. Pengeditan berikutnya akan membuat draf dan versi baru.
2. SLO propagasi berlaku untuk instans server terhubung yang sehat, bukan perangkat yang sedang offline.
3. Aplikasi memiliki nilai fallback akhir. Platform tidak pernah membuat nilai sendiri saat pemeriksaan tipe, inisialisasi, atau evaluasi gagal.

Untuk desain dasar, status last-known-good tetap valid setidaknya selama 15 menit yang diperlukan. Setelah batas stale_after flag yang dipublikasikan, stale_action-nya memilih antara evaluasi last-known-good lanjutan atau kode fallback, dan SDK mengembalikan alasan usang (stale reason). Jalur yang sensitif terhadap keamanan atau destruktif harus memilih fallback daripada menyajikan aturan pengaktifan lama secara diam-diam.

Hal ini menghindari penyembunyian kebijakan produk di dalam infrastruktur. Migrasi pembayaran dapat beralih secara default ke jalur lama, sementara kemampuan yang sensitif terhadap keamanan dapat beralih ke nonaktif secara default. Keduanya menggunakan platform yang sama dengan kontrak aplikasi yang berbeda.

Langkah 2: Pisahkan control plane dan evaluation data plane

Control plane berisi API dan UI manajemen, pemeriksaan identitas dan peran, validator skema dan aturan, alur kerja persetujuan, sumber kebenaran relasional, log audit append-only, pembuat snapshot, dan penerbit (publisher). Penulisan bervolume rendah dibandingkan dengan evaluasi, sehingga kebenaran, kemudahan peninjauan, dan pemulihan lebih penting daripada latensi mikrodetik.

Data plane berisi relay streaming regional, penyimpanan snapshot, endpoint polling, serta penyimpanan dan evaluator lokal SDK. SDK server membuka stream regional, menginstal snapshot immutable, menerapkan patch berversi, dan mengevaluasi tanpa panggilan jaringan. Jika stream terputus, SDK mempertahankan status valid terakhir dan melakukan polling dengan jitter. Jika patch melewatkan suatu versi atau gagal dalam validasi checksum, SDK akan membuang patch tersebut dan meminta snapshot lengkap.

Jaga agar pengiriman data plane independen dari basis data kontrol utama. Penerbit menulis artefak berversi yang tahan lama sebelum memberi tahu relay. Dengan demikian, pemadaman basis data atau dasbor dapat menghentikan pengeditan baru tanpa menghentikan evaluasi yang sudah ada.

Langkah 3: Definisikan model data dan API

Definisi flag memerlukan setidaknya:

FlagDefinition {
  tenant_id, project_id, environment, flag_key
  version, value_type, variations[], off_variation
  ordered_rules[], default_rule, salt
  stale_after, stale_action
  state, owner, expires_at
}

Rule {
  rule_id, conditions[], outcome
}

Outcome = fixed_variation | weighted_variations[]

Segmen diberi versi secara terpisah karena banyak flag dapat merujuk ke satu kohort. Entri audit mencatat pelaku (actor), waktu, alasan, versi sebelumnya yang diharapkan, referensi sebelum-dan-sesudah, persetujuan, dan hasil publikasi. Pisahkan draf dari artefak yang dipublikasikan sehingga pengeditan yang belum disetujui tidak dapat bocor ke dalam evaluasi.

API representatifnya adalah:

PUT  /v1/projects/{project}/environments/{env}/flags/{key}
     body: draft definition, expectedVersion

POST /v1/projects/{project}/environments/{env}/flags/{key}:publish
     body: draftVersion, reason, approvalToken

GET  /v1/sdk/bootstrap?project={project}&env={env}&after={version}
GET  /v1/sdk/stream?project={project}&env={env}

Versi yang diharapkan mencegah dua editor menimpa pekerjaan satu sama lain secara diam-diam. Kredensial manajemen tidak pernah berfungsi ganda sebagai kredensial SDK. Tenant, proyek, environment, dan mode pengiriman yang diizinkan adalah bagian dari setiap keputusan otorisasi.

Langkah 4: Jadikan evaluasi dan rollout persentase deterministik

Gunakan satu urutan terdokumentasi di seluruh SDK:

1. Periksa keberadaan flag, environment, tipe, dan apakah penargetan diaktifkan.
2. Terapkan target subjek atau segmen eksplisit.
3. Evaluasi aturan berurutan; aturan pertama yang cocok menang.
4. Tentukan variasi tetap atau rollout berbobot.
5. Gunakan aturan default jika tidak ada yang cocok.
6. Kembalikan fallback aplikasi dengan alasan kesalahan ketika evaluasi tidak dapat menghasilkan hasil bertipe yang valid.

Untuk rollout berbobot, dapatkan bucket dari input yang stabil:

bucket = H(tenant_id || environment || flag_key || salt || targeting_key) mod 100000

Petakan bucket ke dalam rentang variasi kumulatif. Input yang sama menghasilkan hasil yang sama di setiap instans dan wilayah. Menyimpan versi algoritma dan salt dalam definisi yang dipublikasikan membuat perilaku dapat direproduksi. Memperluas rentang berdekatan yang ada dapat mempertahankan subjek yang sudah ada di dalamnya, tetapi pembobotan ulang yang sewenang-wenang atau mengubah input hash dapat memindahkan pengguna; paparkan konsekuensi tersebut selama peninjauan.

Dua flag independen dengan persentase yang sama tidak harus memilih subjek yang sama karena flag key berpartisipasi dalam hashing. Jika beberapa flag harus bergerak sebagai satu kohort, targetkan segmen berversi bersama atau gunakan kunci eksperimen eksplisit. Jangan pernah melakukan hash pada bidang yang dapat berubah seperti email jika ID subjek yang stabil tersedia.

Langkah 5: Kirimkan snapshot dan perubahan bertahap dengan aman

Pembuat snapshot menyelesaikan cakupan proyek dan environment, memvalidasi segmen yang dirujuk dan prasyarat, mengurutkan aturan secara deterministik, membuat serialisasi artefak kanonikal, dan melampirkan versi serta checksum. Sebuah transaksi mengomit metadata yang dipublikasikan dan catatan outbox; penerbit asinkron menyimpan artefak dan mengumumkannya ke relay regional. Ini menghindari pengomitan flag tanpa menjadwalkan pengirimannya.

Urutan boot SDK adalah:

1. Muat snapshot last-known-good persisten yang valid jika dikonfigurasi.
2. Ambil artefak penuh atau delta terbaru dari relay terdekat.
3. Ganti snapshot dalam memori secara atomik hanya setelah pemeriksaan tipe, versi, dan checksum.
4. Tandai provider sebagai siap, lalu layani evaluasi lokal.
5. Pertahankan stream tetap terbuka untuk pembaruan dan polling sebagai jalur perbaikan.

Jangan pernah memutasi rangkaian aturan aktif secara langsung di tempat (in place). Bangun snapshot immutable baru dan tukar satu referensi sehingga permintaan konkuren melihat versi lama yang lengkap atau versi baru yang lengkap. Catat versi yang diterapkan dan alasan evaluasi dalam detail diagnostik.

Langkah 6: Desain semantik kegagalan sebelum happy path

Emergency off switch menggunakan jalur publikasi tahan lama yang sama dengan jalur prioritas (priority lane), bukan saluran sampingan yang dapat dimutasi dan tidak diaudit. Tombol ini dapat melewati penantian persetujuan biasa hanya berdasarkan kebijakan break-glass yang telah diotorisasi sebelumnya, tetapi tetap mencatat pelaku, alasan, versi sebelumnya, dan hasil. Target propagasi lima detik tidak dapat menjamin bahwa setiap instans yang terputus telah beralih; tindakan destruktif memerlukan penegakan independen.

Langkah 7: Lindungi platform agar konfigurasi tidak menjadi otoritas

Pisahkan peran manajemen berdasarkan tenant, proyek, dan environment. Pengeditan produksi mungkin memerlukan pemberi persetujuan kedua, sedangkan pengeditan pengembangan dapat langsung dipublikasikan. Enkripsi kredensial, rotasi SDK key, batasi laju (rate-limit) panggilan manajemen, dan pastikan server key tidak dapat mengedit flag. Log audit append-only dan artefak immutable memungkinkan rekonstruksi insiden.

Perlakukan pengiriman klien secara berbeda dari pengiriman server. Kirimkan ke browser atau perangkat seluler hanya flag yang secara eksplisit disetujui untuk eksposur klien, dan lebih baik kirimkan nilai yang telah dievaluasi untuk konteks mereka. Pengguna dapat memeriksa atau mengubah status klien, sehingga flag dapat mengubah presentasi tetapi tidak dapat memberikan otorisasi, melewati pembayaran, atau menggantikan pemeriksaan hak (entitlement) di sisi server. Minimalkan bidang identitas pribadi (PII) dalam konteks evaluasi dan samarkan (pseudonymize) pengidentifikasi telemetri.

Berikan setiap flag rilis sementara seorang pemilik dan kondisi penghentian. Setelah peluncuran selesai, pertama-tama buat jalur pemenang permanen, lalu hentikan evaluasi flag, lalu hapus definisi setelah referensi kode hilang. Jika tidak, cabang lama dan flag yang saling berinteraksi akan memperluas matriks pengujian tanpa batas.

Langkah 8: Periksa ulang kapasitas dan buktikan desainnya

Pada 500 flag yang dilanggan dengan rata-rata 2 KB, satu snapshot runtime berukuran sekitar 1 MB. Mem-bootstrap 20.000 instans sekaligus mentransfer sekitar 20 GB sebelum overhead protokol dan replikasi. Tempatkan artefak kanonikal di belakang relay regional atau pengiriman objek, gunakan versi kondisional, gunakan jitter pada penyambungan ulang, dan batasi konkurensi bootstrap. Satu perubahan 2 KB yang disebarkan ke 20.000 instans adalah sekitar 40 MB muatan logis, sehingga pengiriman inkremental jauh lebih hemat daripada penyegaran penuh.

Lima juta evaluasi per detik tidak boleh memancarkan lima juta peristiwa jaringan secara sinkron. Bahkan peristiwa 200-byte akan menghasilkan sekitar 1 GB per detik, atau 86,4 TB per hari sebelum replikasi. Bufer, kelompokkan (batch), sampel, atau agregasikan diagnostik biasa. Pertahankan peristiwa penetapan lengkap hanya jika kontrak eksperimen memerlukannya, dan tempatkan telemetri pada antrean berbatas yang dapat membuang peristiwa non-kritis tanpa menunda evaluasi.

Validasi mencakup lebih dari sekadar throughput:

• Jalankan aturan emas (golden rules) dan konteks yang sama pada setiap implementasi SDK dan bandingkan nilai, varian, alasan, serta perilaku kesalahan.
• Uji properti (property-test) determinisme bucket, perkiraan distribusi, dan stabilitas ketika rentang rollout yang ada diperluas.
• Ukur p50 dan p99 lokal berdasarkan jumlah aturan dan ukuran segmen; ukur jeda publish-to-apply secara terpisah.
• Putuskan stream, hentikan basis data kontrol, rusak sebuah patch, lewati sebuah versi, kedaluwarsa kredensial, dan mulai ulang semua instans secara bersamaan.
• Publikasikan aturan buruk ke kohort kenari (canary) kecil, picu alarm kesehatan, dan verifikasi bahwa rollback membuat dan menyebarkan versi baru yang diaudit.
• Verifikasi isolasi tenant, persetujuan produksi, pemfilteran eksposur klien, kelengkapan audit, dan penghentian flag.

Contoh jawaban yang kuat

"Saya akan membatasi sistem dasar pada evaluasi sisi server. Ada 20.000 instans di tiga wilayah, tetapi hanya 100 penulisan kontrol per detik, sehingga kedua jalur lalu lintas tidak boleh berbagi ketergantungan ketersediaan. Layanan manajemen menyimpan draf dan versi publikasi yang immutable dalam basis data relasional. Setiap publikasi memvalidasi tipe, referensi aturan, dan izin, memeriksa versi sebelumnya yang diharapkan, menulis catatan audit dan entri outbox, lalu membangun artefak kanonikal proyek-dan-environment.

Relay regional mendistribusikan artefak tersebut. Setiap SDK memuat snapshot last-known-good, menerima pembaruan melalui stream, dan melakukan polling untuk memperbaiki celah. SDK menginstal snapshot immutable baru secara atomik dan mengevaluasi secara lokal, menjaga latensi permintaan di bawah target p99 1-milidetik bahkan ketika control plane mati. Last-known-good valid setidaknya selama 15 menit; setelah batas usang yang dipublikasikan, flag akan mempertahankan nilai tersebut atau menggunakan kode fallback bertipe sesuai dengan kebijakan risikonya. Versi lokal, kesegaran (freshness), dan alasan evaluasi dapat diamati (observable).

Urutan evaluasi adalah status mati (off state), target eksplisit, aturan berurutan, hasil berbobot, lalu default. Rollout persentase melakukan hash pada tenant, environment, flag, salt, dan targeting key yang stabil ke dalam 100.000 bucket, sehingga setiap instans membuat pilihan yang sama. Mengubah input hash adalah proses migrasi; beberapa flag yang memerlukan satu kohort menggunakan segmen bersama alih-alih persentase yang kebetulan sama.

Lonjakan terbesar adalah bootstrap armada: snapshot cakupan 1 MB dikalikan 20.000 instans adalah sekitar 20 GB. Saya akan melayani snapshot secara regional, mengirimkan delta, menambahkan jitter pada penyambungan ulang, dan membatasi percobaan ulang. Telemetri evaluasi dikelompokkan dan disampel karena mencatat 5 juta peristiwa sinkron per detik akan mengancam jalur produk. Terakhir, saya akan menguji kesesuaian lintas-SDK, p99 propagasi, badai mulai ulang, operasi usang, versi yang rusak dan hilang, rollback canary, audit break-glass, isolasi tenant, dan eksposur klien. Sistem berhasil ketika evaluasi permintaan tetap lokal dan deterministik sementara setiap perubahan konfigurasi tetap diatur dan dapat dipulihkan."

Kesalahan umum

• Memanggil layanan pusat untuk setiap evaluasi → latensi dan ketersediaan produk sekarang bergantung pada layanan flag → kirim aturan berversi ke SDK server dan evaluasi di dalam proses (in-process).
• Memilih pengguna secara acak pada setiap permintaan → satu pengguna berpindah-pindah antar varian dan data eksperimen terkontaminasi → lakukan hash pada targeting key yang stabil dengan input khusus flag yang terdokumentasi.
• Memperlakukan last-known-good sebagai benar secara permanen → instans yang terputus dapat melayani aturan usang yang tidak aman tanpa batas → definisikan observabilitas keusangan, perilaku sambung ulang dan perbaikan, serta fallback keamanan aplikasi.
• Mengirimkan aturan server ke browser → pengguna dapat memeriksa segmen sensitif dan kredensial → filter flag yang aman untuk klien atau evaluasi dari jarak jauh, dan tegakkan otorisasi di server.
• Memperbarui objek aturan bersama secara langsung di tempat (in place) → permintaan konkuren dapat mengamati konfigurasi yang diterapkan sebagian → validasi snapshot immutable yang lengkap dan tukar referensi secara atomik.
• Mencatat setiap evaluasi secara sinkron → telemetri menjadi ketergantungan bervolume tertinggi di jalur permintaan → kelompokkan (batch), sampel, agregasikan, dan pangkas peristiwa non-kritis.
• Membuat perubahan darurat tanpa diaudit → jalur pemulihan tercepat menjadi pintu belakang produksi yang tidak dapat dilacak → gunakan jalur publikasi prioritas dengan kebijakan break-glass yang telah diotorisasi sebelumnya dan audit immutable.
• Tidak pernah menghentikan flag → cabang usang dan interaksi antar-flag melipatgandakan biaya pengujian → tetapkan pemilik dan hapus definisi setelah jalur kode pemenang menjadi permanen.

Pertanyaan tindak lanjut dan tanggapan

Tindak Lanjut 1: Bagaimana Anda mendukung SDK browser dan seluler?

Jangan kirimkan seluruh rangkaian aturan server. Tandai flag mana yang dapat diekspos ke klien, autentikasi aplikasi alih-alih mempercayainya dengan kredensial manajemen, dan kembalikan nilai yang difilter atau hasil evaluasi khusus konteks. Simpan nilai dalam cache untuk penggunaan offline dengan status versi dan kesegaran yang terlihat. Flag klien tetap menjadi petunjuk pengalaman pengguna; server secara independen memeriksa izin, pembelian, kuota, dan keputusan keamanan lainnya.

Tindak Lanjut 2: Bagaimana beberapa flag mempertahankan kohort rollout yang persis sama?

Persentase yang identik tidak cukup karena setiap flag key mengubah input hash. Buat segmen berversi bersama atau penetapan eksperimen yang diberi kunci dengan ID eksperimen umum, lalu rujuk dari setiap flag. Publikasikan versi segmen dan flag dependen secara konsisten, dan uji bahwa keanggotaan kohort tetap stabil sebelum meningkatkan eksposur.

Tindak Lanjut 3: Bagaimana jika sebuah segmen memiliki sepuluh juta anggota?

Jangan menyematkan daftar anggota lengkap di setiap snapshot. Representasikan keanggotaan sebagai artefak berversi yang ringkas, bagi (shard) berdasarkan hash subjek, atau hitung sebelumnya atribut yang dapat digunakan oleh evaluator. Bloom filter dapat mengurangi lalu lintas pencarian negatif tetapi tidak dapat menjadi satu-satunya mekanisme otorisasi karena adanya false positive. Ukur memori, latensi pencarian, amplifikasi pembaruan, dan keanggotaan yang usang secara terpisah dari aturan biasa.

Tindak Lanjut 4: Bisakah emergency off switch bekerja secara instan?

Tidak ada publikasi terdistribusi yang mencapai proses yang terputus secara instan. Berikan prioritas pada perubahan darurat, pertahankan stream regional tetap aktif, ukur konfirmasi (acknowledgments), dan beri peringatan pada versi yang tertinggal. Untuk operasi destruktif, kombinasikan flag dengan pengaman yang ditegakkan di server seperti menonaktifkan endpoint penulisan, mencabut kemampuan, atau memblokir pekerjaan di gateway. Flag meningkatkan kecepatan pemulihan tetapi tidak menggantikan batasan keamanan yang mutlak.

Tindak Lanjut 5: Bagaimana Anda memigrasikan algoritma hashing?

Simpan versi algoritma dan salt pada setiap flag yang dipublikasikan. Jalankan evaluator lama dan baru dalam mode bayangan (shadow mode) dan ukur pergerakan penetapan. Jika pergerakan dapat diterima, publikasikan migrasi bertahap; jika tidak, pertahankan penetapan subjek yang ada dalam segmen atau tabel migrasi hingga rollout selesai. Jangan pernah mengubah implementasi hash SDK secara diam-diam karena versi yang berbeda tidak akan cocok.

Tindak Lanjut 6: Bagaimana Anda mencegah siklus ketergantungan flag?

Bangun grafik prasyarat selama publikasi dan tolak versi jika penelusuran depth-first menemukan sebuah siklus. Batasi kedalaman prasyarat maksimum dan total pekerjaan evaluasi sehingga grafik asiklik tetapi patologis tidak dapat melanggar batas latensi. Sertakan versi flag yang dirujuk dalam artefak, uji urutan evaluasi di seluruh SDK, dan tampilkan rantai ketergantungan dalam detail diagnostik.