Petunjuk dan konteks
Platform ini melayani feature flag boolean, string, dan terstruktur untuk layanan multi-tenant. Aturan dapat bergantung pada tenant, pengguna, wilayah, dan versi aplikasi. Setelah rilis, beberapa instance langsung diperbarui sementara yang lain tertinggal selama beberapa menit, dan konteks sensitif tidak boleh masuk ke dalam log. Rancang control plane, data plane, konteks evaluasi, cache, rilis, kegagalan, dan loop audit.
Apa yang sedang diuji oleh pewawancara
- Memisahkan penerbitan control-plane dari evaluasi data-plane serta menentukan target versi dan konsistensi.
- Menggabungkan, menimpa (override), mempropagasi, dan melindungi konteks evaluasi dengan benar.
- Merancang pembatalan cache (invalidation), snapshot offline, default, dan rollback tanpa memerlukan RPC langsung per permintaan.
- Membuat telemetri paparan (exposure), kesalahan, perubahan, dan kecocokan aturan dapat diaudit tanpa membocorkan data pribadi.
Pertanyaan untuk diklarifikasi terlebih dahulu
- Apakah evaluasi harus konsisten secara kuat (strongly consistent), atau data usang (stale data) dapat diterima? Berapa batas keusangan maksimum?
- Bagaimana urutan prioritas aturan untuk tenant, pengguna, perangkat, wilayah, dan versi?
- Berapa lama layanan harus tetap berjalan saat control plane tidak tersedia, dan siapa yang menyetujui nilai default?
- Kolom konteks mana saja yang merupakan data pribadi, dan mana yang boleh masuk ke dalam log paparan?
- Apakah SDK multi-bahasa dan evaluasi offline lokal diperlukan, atau evaluator jarak jauh (remote) dapat diterima?
Kerangka jawaban 30 detik
Control plane akan memvalidasi aturan, menerbitkan versi yang tidak dapat diubah (immutable), menyetujui, dan melakukan rollback. SDK data-plane akan mengevaluasi snapshot lokal berversi untuk latensi rendah dan operasi offline. Konteks akan menggabungkan cakupan global, transaksi, dan pemanggilan dengan urutan penimpaan eksplisit serta kolom minimal. Instance akan menerima pembaruan melalui streaming ditambah polling, dengan TTL dan pemeriksaan monotonisitas versi. Kegagalan akan menggunakan default bertipe atau nilai baik terakhir yang diketahui (last-known-good value) serta mengekspos keusangannya; flag kritis dapat menggunakan pendekatan fail-closed. Peristiwa audit akan memuat versi dan kunci anonim, bukan atribut mentah.
Jawaban mendalam langkah demi langkah
Langkah 1: Tentukan objek dan mesin status rilis
Sebuah flag memuat tipe, default, aturan, varian, lingkungan, versi, dan waktu aktivasi. Penerbitan bergerak melalui draf, validasi, persetujuan, canary, selesai, atau rollback; setiap perubahan membuat versi yang tidak dapat diubah. Kesalahan kompilasi, ketidakcocokan tipe, atau default yang hilang akan memblokir penerbitan alih-alih menjadi kegagalan runtime bagi setiap layanan.
Langkah 2: Rancang konteks evaluasi
Representasikan atribut aplikasi, host, wilayah, tenant, dan pengguna sebagai konteks terstruktur. Gabungkan konteks global, transaksi, dan pemanggilan sesuai dengan spesifikasi menggunakan urutan kunci duplikat yang eksplisit. SDK tidak boleh membaca status thread secara implisit. Terapkan daftar izin (allowlist) kolom dan redaksi sebelum konteks masuk ke SDK, transportasi, atau log.
Langkah 3: Pilih evaluasi lokal atau jarak jauh
Latensi rendah dan ketahanan terhadap pemadaman singkat control plane mendukung evaluasi lokal dari snapshot aturan terdistribusi. Evaluasi jarak jauh memusatkan logika kompleks tetapi menambahkan dependensi jaringan dan ketersediaan ke setiap panggilan. Pendekatan hibrida dapat mempertahankan evaluasi sederhana di SDK dan menggunakan provider untuk aturan kompleks, sambil mengembalikan nilai bertipe, alasan, versi, dan metadata.
Langkah 4: Tetapkan sasaran cache dan konsistensi
Beri kunci cache snapshot berdasarkan lingkungan, rangkaian flag, dan versi serta lindungi dengan checksum dan masa kedaluwarsa. Polling mengompensasi notifikasi pembaruan yang hilang. Sebuah instance memulai dari snapshot tepercaya terakhirnya dan mengejar pembaruan secara asinkron. Tentukan aturan “tidak pernah mundur”, batas detik keusangan maksimum, dan waktu propagasi rollback sebagai SLO.
Langkah 5: Tangani kegagalan dan default yang aman
Pada kesalahan evaluasi, kembalikan default yang kompatibel dengan tipe atau nilai baik terakhir yang diketahui beserta alasan, kode kesalahan, dan sumbernya. Flag pembayaran, otorisasi, dan penghapusan tidak boleh secara diam-diam mengambil nilai default yang berbahaya; flag tersebut dapat memblokir operasi atau menggunakan kebijakan fail-closed yang disetujui. Lindungi sistem dari flag yang tidak dikenal, konversi tipe yang tidak aman, dan batas waktu aturan yang merembet ke pemanggil.
Langkah 6: Rancang telemetri audit dan paparan
Control plane mencatat siapa yang menerbitkan, menyetujui, menjalankan canary, atau melakukan rollback beserta waktunya. Data plane mencatat kunci flag, versi, hasil, cabang aturan, versi SDK, dan hash subjek anonim, bukan email mentah, IP, atau konteks lengkap. Isolasi pengambilan sampel, retensi, dan akses berdasarkan tenant serta gabungkan hasil dengan metrik untuk mendeteksi dampak canary.
Langkah 7: Verifikasi rollback dan migrasi
Putar ulang (replay) konteks tetap terhadap setiap versi aturan dan bandingkan hasilnya di berbagai SDK bahasa. Ujicobakan skenario notifikasi yang hilang, cache yang rusak, pemadaman control plane, kemiringan waktu (clock skew), rollback parsial, dan peningkatan provider. Rollback membuat versi baru alih-alih menulis ulang riwayat; bandingkan distribusi versi instance dan metrik bisnis setelah selesai.
Contoh jawaban berkualitas tinggi
Control plane menangani pemeriksaan tipe, kompilasi, persetujuan, versi, dan canary; SDK mengevaluasi snapshot lokal dengan checksum untuk latensi rendah dan operasi offline. Konteks menggabungkan cakupan global, transaksi, dan pemanggilan dengan urutan penimpaan tetap serta daftar izin untuk kolom sensitif. Instance menggunakan notifikasi ditambah polling, dengan aturan batas keusangan maksimum dan versi monotonik. Kesalahan mengembalikan default bertipe atau nilai baik terakhir yang diketahui, dengan opsi fail-closed untuk flag kritis. Audit mempertahankan jejak penerbitan dan rollback, log paparan hanya berisi versi, hasil, dan kunci anonim, serta rollback berupa versi baru yang diverifikasi melalui replay SDK dan latihan kegagalan.
Kesalahan umum
- Memanggil control plane secara sinkron untuk setiap evaluasi dan mengaitkan ketersediaan bisnis dengannya.
- Menyimpan nilai dalam cache tanpa versi, sehingga rollback dan keusangan tidak dapat dijelaskan.
- Membiarkan urutan penggabungan konteks bergantung pada perilaku SDK bahasa sehingga menghasilkan nilai berbeda antar layanan.
- Mencatat atribut pengguna lengkap atau email ke dalam log.
- Menimpa konfigurasi lama selama rollback dan kehilangan riwayat audit serta replay.
Pertanyaan lanjutan dan tanggapan
Pertanyaan lanjutan 1: Bisakah evaluasi berlanjut jika layanan konfigurasi tidak aktif?
Gunakan snapshot tepercaya terakhir dan ekspos versi, usia, serta sumbernya. Jika melebihi ambang batas keusangan maksimum, pilih default berbasis risiko, blokir, atau minta tindakan manusia daripada berjalan secara diam-diam selamanya.
Pertanyaan lanjutan 2: Bagaimana Anda menjaga konsistensi SDK lintas bahasa?
Tentukan standarisasi, tipe data, penggabungan konteks, dan alasan kesalahan secara rinci, serta sediakan vektor input/output lintas bahasa yang berversi. Provider dapat mengeksekusi aturan kompleks secara terpusat sementara SDK berbagi protokol dan siklus hidup yang sama.
Pertanyaan lanjutan 3: Bagaimana Anda menjaga persentase canary tetap stabil?
Kelompokkan (bucket) kunci subjek anonim yang stabil menggunakan algoritma hash eksplisit. Versi aturan yang tetap memberikan varian yang sama untuk subjek yang sama di setiap instance. Mengubah algoritma atau salt akan membuat versi baru dengan dampak migrasi yang terdokumentasi.
Pertanyaan lanjutan 4: Mengapa menggunakan hooks?
Hooks dapat menambahkan konteks sebelum evaluasi, memvalidasi nilai setelah evaluasi, atau memancarkan telemetri, tetapi memerlukan pengurutan eksplisit, batas waktu (timeouts), dan penanganan kesalahan. Hooks tidak boleh mengubah tipe flag secara diam-diam atau melewati audit.
Pertanyaan lanjutan 5: Bagaimana cara menghapus flag dengan aman?
Temukan referensi kode, lalu lintas evaluasi, dan percabangan default, terbitkan versi dengan nilai tetap, amati, lalu hapus aturan dan metadata SDK. Pertahankan versi historis dan catatan migrasi agar instance lama tidak menerima tipe yang tidak dikenal.