Wawancara Desain Sistem: Mendesain Layanan Multi-Tenant Feature Entitlement

Konteks dan pertanyaan

Topik desain sistem ini cocok untuk peran platform, backend, dan infrastruktur SaaS. Sistem penagihan (billing) memancarkan event paket dan pembayaran; layanan produk memerlukan keputusan otorisasi seperti can tenant T use feature F for subject U?. Asumsikan terdapat 50.000 tenant, 10 juta subject, 100.000 permintaan keputusan per detik pada waktu puncak, dan target ketersediaan bulanan 99,99%. Hak akses (entitlement) yang dibatalkan atau ditangguhkan tidak boleh tetap dapat digunakan tanpa batas waktu, sementara gangguan pada sistem billing tidak boleh melumpuhkan seluruh jalur baca (read path).

Hal yang dinilai oleh pewawancara

• Bisakah Anda memisahkan billing sebagai sumber kebenaran komersial dari snapshot entitlement yang telah dievaluasi?
• Apakah Anda mendefinisikan isolasi tenant dan subject, serta prioritas antara paket, add-on, uji coba, dan aturan penolakan (deny rules)?
• Bisakah Anda menganalisis urutan event, keusangan cache (staleness), latensi pencabutan, serta keputusan fail-open versus fail-closed?
• Apakah Anda menyediakan API berversi, jejak audit, observabilitas, dan jalur pemulihan yang dapat diputar ulang (replayable)?

Pertanyaan klarifikasi yang perlu diajukan

Tanyakan apakah keputusan berlaku per tenant, pengguna, akun layanan, atau seat; apakah suatu fitur dapat diaktifkan untuk sebagian kelompok; seberapa cepat pembatalan harus mencabut akses; apakah kuota penggunaan merupakan bagian dari keputusan; dan apakah setiap keputusan memerlukan alasan yang dapat dijelaskan. Konfirmasikan apakah event billing bersifat at-least-once dan dapat tiba di luar urutan. Jawaban-jawaban ini akan mengubah skema snapshot, penanganan event, TTL cache, dan kebijakan failover.

Kerangka jawaban 30 detik

Saya akan mempertahankan billing sebagai sumber otoritatif dan membangun proyeksi entitlement yang menggunakan kunci tenant, cakupan subject, fitur, dan versi. Jalur tulis mengonsumsi event langganan yang berurutan atau telah dideduplikasi, menghitung snapshot baru, dan memublikasikan pembatalan validitas (invalidation). API baca mengevaluasi snapshot dengan prioritas eksplisit dan mengembalikan allow, deny, alasan, dan versi. Cache regional melayani pembacaan traffic tinggi, tetapi token pencabutan atau version fence membatasi akses yang usang. Fail-open hanya diizinkan untuk fitur berisiko rendah; fitur berbayar atau yang sensitif terhadap keamanan mengalami fail-closed dan mengekspos jalur pemulihan. Setiap perubahan dan keputusan dapat diaudit.

Pembahasan mendalam langkah demi langkah

1. Tentukan kontrak. Evaluate(tenant_id, subject_id, feature, context) mengembalikan keputusan, kode alasan, versi snapshot, dan waktu kedaluwarsa. Konteks dapat mencakup atribut paket, wilayah, seat, atau rollout; OpenFeature memerlukan kunci penargetan yang unik dan mendukung bidang kustom, jadi jangan membebani satu string teks bebas dengan status billing.
2. Modelkan pemberian hak (grants) yang tidak dapat diubah (immutable). Simpan produk langganan, add-on, uji coba, seat, waktu efektif dan kedaluwarsa, serta penolakan eksplisit sebagai fakta berversi. Proyeksi menyimpan rangkaian fitur yang telah ditentukan beserta ID fakta sumber. Penolakan akibat penangguhan atau kepatuhan mengesampingkan pemberian hak normal; uji coba dengan batas waktu kedaluwarsa tanpa mengubah riwayat.
3. Bangun jalur propagasi. Billing memancarkan event dengan tenant, versi langganan, ID event, dan waktu efektif. Kotak masuk (inbox) mendeduplikasi ID event, menolak versi yang lebih lama, dan menulis fakta serta proyeksi secara transaksional. Kotak keluar (outbox) memublikasikan entitlement_version_changed; konsumen melakukan invalidasi berdasarkan tenant dan fitur. Memutar ulang fakta akan merekonstruksi proyeksi setelah terjadi kerusakan data.
4. Layani pembacaan. API evaluasi stateless membaca cache lokal atau penyimpanan regional. Kunci cache mencakup tenant, cakupan subject, fitur, dan versi kebijakan. Entri cache membawa versi proyeksi dan waktu kedaluwarsa. Jika suatu permintaan menyajikan version fence yang lebih baru daripada cache, baca penyimpanan regional otoritatif sebelum mengambil keputusan.
5. Pilih konsistensi berdasarkan risiko. Tetapkan SLO pencabutan yang terukur, seperti 60 detik untuk pembatalan biasa dan fencing hampir seketika untuk penipuan atau penangguhan keamanan. Publikasikan deny fence ke penyimpanan yang sangat mudah dijangkau; layanan akan menolak izin (allow) dalam cache yang lebih lama dari fence tersebut. Jangan menjanjikan nol pembacaan usang tanpa menanggung biaya pemeriksaan sinkron.
6. Tangani kegagalan dan skala. Partisi event berdasarkan tenant untuk menjaga urutan per-tenant, shard proyeksi berdasarkan hash tenant, dan jaga agar tenant dengan traffic tinggi tetap terisolasi. Jika terjadi keterlambatan billing, tampilkan versi yang terakhir diterapkan dan kirimkan peringatan. Jika terjadi kegagalan cache atau penyimpanan regional, gunakan jendela usang terbatas hanya untuk fitur berisiko rendah; kembalikan typed dependency error untuk fitur berisiko tinggi alih-alih memberikan akses secara diam-diam.
7. Audit dan verifikasi. Catat siapa yang mengubah paket, versi event mana yang menghasilkan proyeksi, dan mengapa keputusan diambil. Ukur kelambatan event (event lag), usia proyeksi, rasio hit cache, pemblokiran stale-allow, latensi keputusan, dan kegagalan otorisasi lintas-tenant. Uji event yang datang di luar urutan, pengiriman duplikat, pergeseran waktu (clock skew), pembatalan di tengah permintaan, migrasi tenant, dan pemutaran ulang dari proyeksi kosong.

Contoh jawaban berkualitas tinggi

Saya akan memisahkan kebenaran komersial dari proyeksi entitlement berversi. Event billing membawa ID event, tenant, versi langganan, waktu efektif, dan produk yang diubah. Kotak masuk mendeduplikasi dan menolak versi yang lebih lama, lalu secara transaksional menulis fakta, snapshot fitur yang telah ditentukan, dan notifikasi outbox. API evaluasi mengembalikan allow atau deny, alasan, versi proyeksi, dan waktu kedaluwarsa. Kunci cache mencakup tenant dan cakupan subject sehingga satu pelanggan tidak dapat membaca keputusan pelanggan lain.

Trade-off utamanya adalah pencabutan. Saya akan menetapkan SLO pembatalan biasa selama 60 detik dan memublikasikan deny fence untuk penangguhan akibat penipuan atau keamanan. Setiap allow yang di-cache membawa versi proyeksi; fence yang lebih baru memaksa pembacaan dari penyimpanan regional. Fitur UI berisiko rendah dapat menggunakan jendela usang terbatas selama gangguan penyimpanan, sementara ekspor data berbayar atau kontrol keamanan mengalami fail-closed dengan typed dependency error. Catatan audit menghubungkan setiap keputusan dengan versi event dan kebijakan, dan tugas pemutaran ulang (replay job) membangun kembali proyeksi dari fakta yang tidak dapat diubah.

Kesalahan umum

• Membaca tabel billing secara sinkron untuk setiap permintaan → latensi dan gangguan pembayaran menjadi gangguan otorisasi → proyeksikan fakta yang tidak dapat diubah ke dalam snapshot yang dioptimalkan untuk pembacaan.
• Melakukan caching hanya berdasarkan fitur → satu tenant atau subject dapat menerima keputusan cakupan lain → sertakan tenant, cakupan subject, dan versi kebijakan di dalam kunci.
• Menerapkan event berdasarkan urutan kedatangan → pembatalan atau perpanjangan lama dapat menimpa status yang lebih baru → deduplikasi ID dan tolak versi yang lebih lama dari versi yang diterapkan.
• Menjanjikan pencabutan instan di mana saja → desain ini mengabaikan biaya jaringan dan cache → nyatakan SLO pencabutan yang terukur dan terapkan deny fence.
• Menggunakan fail-open untuk fitur berbayar atau keamanan → akses usang menjadi insiden pendapatan atau keselamatan → klasifikasikan fitur berdasarkan risiko dan gunakan fail-closed jika diperlukan.

Pertanyaan lanjutan dan jawaban

Bagaimana Anda mendukung suatu fitur hanya untuk 10 persen pengguna dalam suatu tenant?

Pisahkan hak komersial dan penargetan rollout. Snapshot entitlement menyatakan bahwa tenant memiliki fitur tersebut; konteks evaluasi dengan kunci penargetan subject yang stabil menerapkan aturan rollout. Catat kedua keputusan tersebut agar teknisi dukungan dapat membedakan antara "tidak dibeli" dan "tidak dipilih oleh rollout".

Apa yang terjadi jika event pembatalan tertunda?

Tampilkan usia proyeksi dan event lag, berikan peringatan sebelum SLO pencabutan dilanggar, dan gunakan versi billing atau deny fence jika tersedia. Jangan menyimpulkan pembatalan dari heartbeat yang hilang. Setelah event tiba, terapkan secara idempoten dan batalkan validitas semua cakupan yang terpengaruh.

Bagaimana cara memigrasikan tenant antar-shard?

Tulis epoch migrasi ke dalam metadata tenant, lakukan pembacaan ganda (dual-read) selama cutover terbatas, dan publikasikan fence yang mencegah shard yang lebih lama melayani allow. Verifikasi jumlah, versi, dan sampel keputusan sebelum menghapus salinan lama; pertahankan fakta yang dapat diputar ulang untuk rollback.