Temu Duga Reka Bentuk Sistem: Mereka Bentuk Perkhidmatan Kelayakan Ciri Multi-Tenant

Gesaan dan konteks

Gesaan reka bentuk sistem ini sesuai untuk peranan platform, bahagian belakang (backend), dan infrastruktur SaaS. Sistem pengebilan mengeluarkan peristiwa pelan dan pembayaran; perkhidmatan produk memerlukan keputusan kebenaran seperti can tenant T use feature F for subject U?. Andaikan terdapat 50,000 penyewa, 10 juta subjek, 100,000 permintaan keputusan sesaat pada waktu puncak, dan sasaran ketersediaan bulanan 99.99%. Kelayakan yang dibatalkan atau digantung tidak boleh kekal boleh digunakan selama-lamanya, manakala gangguan pengebilan tidak boleh melumpuhkan setiap laluan bacaan.

Perkara yang dinilai oleh penemu duga

• Bolehkah anda memisahkan pengebilan sebagai punca kebenaran komersial daripada snapshot kelayakan yang telah dinilai?
• Adakah anda mentakrifkan pengasingan penyewa dan subjek, keutamaan antara pelan, add-on, percubaan, dan peraturan penafian (deny rules)?
• Bolehkah anda mempertimbangkan susunan peristiwa, kelusuhan cache, kependaman pembatalan, dan keputusan fail-open berbanding fail-closed?
• Adakah anda menyediakan API berversi, jejak audit, kebolehcerapan, dan laluan pemulihan yang boleh dimainkan semula (replayable)?

Soalan penjelasan untuk ditanya

Tanya sama ada keputusan adalah mengikut penyewa, pengguna, akaun perkhidmatan, atau tempat duduk; sama ada sesuatu ciri boleh didayakan untuk subset tertentu; berapa cepat pembatalan mesti membatalkan akses; sama ada kuota penggunaan merupakan sebahagian daripada keputusan; dan sama ada setiap keputusan memerlukan sebab yang boleh dijelaskan. Sahkan sama ada peristiwa pengebilan adalah at-least-once dan boleh tiba di luar susunan. Jawapan ini mengubah skema snapshot, pengendalian peristiwa, TTL cache, dan dasar failover.

Rangka kerja jawapan 30 saat

Saya akan mengekalkan pengebilan sebagai punca berwibawa dan membina unjuran kelayakan yang berkuncikan penyewa, skop subjek, ciri, dan versi. Laluan tulis menggunakan peristiwa langganan yang tersusun atau dinyahduplikasi, mengira snapshot baharu, dan menerbitkan pembatalan sah (invalidation). API baca menilai snapshot dengan keutamaan eksplisit dan mengembalikan allow, deny, sebab, dan versi. Cache serantau melayani bacaan panas, tetapi token pembatalan atau version fence mengehadkan akses lapuk. Fail-open hanya dibenarkan untuk ciri berisiko rendah; ciri berbayar atau sensitif keselamatan mengalami fail-closed dan mendedahkan laluan pemulihan. Setiap perubahan dan keputusan boleh diaudit.

Perbincangan mendalam langkah demi langkah

1. Takrifkan kontrak. Evaluate(tenant_id, subject_id, feature, context) mengembalikan keputusan, kod sebab, versi snapshot, dan tamat tempoh. Konteks mungkin merangkumi atribut pelan, rantau, tempat duduk, atau pelancaran; OpenFeature memerlukan kunci penyasaran yang unik dan menyokong medan tersuai, jadi jangan membebankan satu rentetan bentuk bebas dengan status pengebilan.
2. Modelkan pemberian tidak berubah (immutable grants). Simpan produk langganan, add-on, percubaan, tempat duduk, masa berkuat kuasa dan tamat tempoh, serta penafian eksplisit sebagai fakta berversi. Unjuran menyimpan set ciri yang diselesaikan bersama ID fakta sumber. Penafian daripada penggantungan atau pematuhan mengatasi pemberian biasa; percubaan terikat masa tamat tempoh tanpa mengubah sejarah.
3. Bina laluan penyebaran. Pengebilan mengeluarkan peristiwa dengan penyewa, versi langganan, ID peristiwa, dan masa berkuat kuasa. Peti masuk (inbox) menyahduplikasi ID peristiwa, menolak versi yang lebih lama, dan menulis fakta serta unjuran secara transaksi. Peti keluar (outbox) menerbitkan entitlement_version_changed; pengguna membatalkan sah mengikut penyewa dan ciri. Memainkan semula fakta membina semula unjuran selepas berlakunya rasuah data.
4. Layani bacaan. API penilaian tanpa keadaan membaca cache tempatan atau stor serantau. Kunci cache merangkumi penyewa, skop subjek, ciri, dan versi dasar. Entri cache membawa versi unjuran dan tamat tempoh. Jika permintaan mengemukakan version fence yang lebih baharu daripada cache, baca stor serantau yang berwibawa sebelum membuat keputusan.
5. Pilih ketekalan mengikut risiko. Tetapkan SLO pembatalan yang diukur, seperti 60 saat untuk pembatalan biasa dan pemagaran (fencing) hampir serta-merta untuk penipuan atau penggantungan keselamatan. Terbitkan deny fence ke stor yang boleh dicapai dengan kuat; perkhidmatan menolak allow yang dicache yang lebih lama daripada fence tersebut. Jangan menjanjikan sifar bacaan lapuk tanpa menanggung kos semakan segerak.
6. Kendalikan kegagalan dan skala. Bahagikan peristiwa mengikut penyewa untuk mengekalkan susunan bagi setiap penyewa, shard unjuran mengikut hash penyewa, dan pastikan penyewa trafik tinggi diasingkan. Apabila berlaku kelewatan pengebilan, dedahkan versi terakhir yang digunakan dan hantar amaran. Sekiranya berlaku kegagalan cache atau stor serantau, gunakan tetingkap lapuk yang terhad hanya untuk ciri berisiko rendah; kembalikan typed dependency error untuk ciri berisiko tinggi dan bukannya memberikan akses secara senyap.
7. Audit dan sahkan. Rekod siapa yang menukar pelan, versi peristiwa mana yang menghasilkan unjuran, dan sebab keputusan dibuat. Ukur kelewatan peristiwa (event lag), usia unjuran, kadar capaian cache, sekatan stale-allow, kependaman keputusan, dan kegagalan kebenaran rentas penyewa. Uji peristiwa di luar susunan, penghantaran pendua, penyelewengan jam (clock skew), pembatalan semasa permintaan, penghijrahan penyewa, dan main semula daripada unjuran kosong.

Contoh jawapan berkualiti tinggi

Saya akan memisahkan kebenaran komersial daripada unjuran kelayakan berversi. Peristiwa pengebilan membawa ID peristiwa, penyewa, versi langganan, masa berkuat kuasa, dan produk yang diubah. Peti masuk menyahduplikasi dan menolak versi yang lebih lama, kemudian secara transaksi menulis fakta, snapshot ciri yang diselesaikan, dan pemberitahuan outbox. API penilaian mengembalikan allow atau deny, sebab, versi unjuran, dan tamat tempoh. Kunci cache merangkumi penyewa dan skop subjek supaya seorang pelanggan tidak dapat membaca keputusan pelanggan lain.

Pertukaran utama adalah pembatalan. Saya akan menetapkan SLO pembatalan biasa selama 60 saat dan menerbitkan deny fence untuk penggantungan penipuan atau keselamatan. Setiap allow yang dicache membawa versi unjuran; fence yang lebih baharu memaksa bacaan stor serantau. Ciri UI berisiko rendah boleh menggunakan tetingkap lapuk terhad semasa gangguan stor, manakala eksport data berbayar atau kawalan keselamatan mengalami fail-closed dengan typed dependency error. Rekod audit memautkan setiap keputusan kepada versi peristiwa dan dasar, dan tugas main semula membina semula unjuran daripada fakta yang tidak berubah.

Kesilapan lazim

• Membaca jadual pengebilan secara segerak untuk setiap permintaan → kependaman pembayaran dan gangguan menjadi gangguan kebenaran → unjurkan fakta tidak berubah ke dalam snapshot yang dioptimumkan untuk bacaan.
• Mencache mengikut ciri sahaja → satu penyewa atau subjek boleh menerima keputusan skop lain → sertakan penyewa, skop subjek, dan versi dasar dalam kunci.
• Menggunakan peristiwa mengikut susunan ketibaan → pembatalan atau pembaharuan lama boleh menulis ganti keadaan yang lebih baharu → nyahduplikasi ID dan tolak versi yang lebih lama daripada versi yang digunakan.
• Menjanjikan pembatalan serta-merta di mana-mana sahaja → reka bentuk menyembunyikan kos rangkaian dan cache → nyatakan SLO pembatalan yang boleh diukur dan kuatkuasakan deny fence.
• Melakukan fail-open untuk ciri berbayar atau keselamatan → akses lapuk menjadi insiden hasil atau keselamatan → kelaskan ciri mengikut risiko dan lakukan fail-closed jika diperlukan.

Soalan susulan dan jawapan

Bagaimanakah anda menyokong sesuatu ciri untuk hanya 10 peratus pengguna penyewa?

Pastikan kelayakan komersial dan penyasaran pelancaran dipisahkan. Snapshot kelayakan menyatakan bahawa penyewa memiliki ciri tersebut; konteks penilaian dengan kunci penyasaran subjek yang stabil menggunakan peraturan pelancaran. Rekod kedua-dua keputusan supaya jurutera sokongan dapat membezakan antara "tidak dibeli" dan "tidak dipilih oleh pelancaran."

Apakah yang berlaku apabila peristiwa pembatalan tertangguh?

Dedahkan usia unjuran dan event lag, beri amaran sebelum SLO pembatalan dilanggar, dan gunakan versi pengebilan atau deny fence apabila tersedia. Jangan simpulkan pembatalan daripada kehilangan degupan jantung (heartbeat). Sebaik sahaja peristiwa tiba, gunakannya secara idempoten dan batalkan kesahan semua skop yang terjejas.

Bagaimanakah anda memindahkan penyewa antara shard?

Tulis epok penghijrahan ke dalam metadata penyewa, lakukan bacaan dwi (dual-read) semasa pertukaran terhad, dan terbitkan fence yang menghalang shard lama daripada melayani allow. Sahkan kiraan, versi, dan sampel keputusan sebelum memadamkan salinan lama; kekalkan fakta yang boleh dimainkan semula untuk pengembalian (rollback).