Wawancara system design: Merancang layanan kuota dan pengukuran penggunaan multi-tenant

1. Pertanyaan dan konteks

Sebuah platform SaaS melayani permintaan API, pekerjaan konkuren, dan penyimpanan untuk banyak tenant. Seorang tenant mungkin memiliki kuota tingkat proyek, organisasi, dan sumber daya; beberapa diatur ulang per menit sementara yang lain berakumulasi selama periode penagihan. Bisnis menginginkan keputusan admisi yang cepat dan penggunaan yang tepercaya untuk peringatan, audit, dan penagihan. Rancang layanan pemeriksaan kuota dan pengukuran penggunaan, termasuk batas tegas (hard limits), ambang batas fleksibel (soft thresholds), kebijakan kelebihan penggunaan (overage policy), dan perilaku kegagalan multi-wilayah.

2. Hal yang dievaluasi pewawancara

• Apakah Anda membedakan batas alokasi, laju (rate), dan konkurensi serta mendefinisikan cakupan dan semantik resetnya.
• Apakah Anda memisahkan admisi sinkron dari event penggunaan asinkron, agregasi penagihan, dan rekonsiliasi.
• Apakah Anda menangani reservasi atomik, kunci idempotensi, event duplikat atau yang tidak berurutan, hot tenant, dan versi konfigurasi.
• Apakah Anda menjelaskan konsistensi lintas wilayah, degradasi, jejak audit, peringatan, dan perubahan manual yang aman.

3. Klarifikasi yang perlu diajukan sebelum menjawab

1. Apakah kita membatasi laju permintaan, pekerjaan simultan, kapasitas penyimpanan, atau penggunaan kumulatif dalam satu periode penagihan?
2. Apakah cakupannya adalah organisasi, tenant, proyek, pengguna, atau instans sumber daya, dan apakah batas diturunkan ke bawah hierarki?
3. Saat kuota habis, apakah sistem harus menolak, mengantrekan, mendegradasi, atau mengizinkan overage untuk penagihan?
4. Apakah konsistensi multi-wilayah yang kuat diperlukan, dan berapa banyak penundaan event yang dapat diterima sebelum rekonsiliasi?

4. Kerangka jawaban 30 detik

Saya akan membagi sistem menjadi katalog kuota, mesin admisi sinkron, buku besar (ledger) reservasi, pipeline event penggunaan asinkron, kueri agregat, dan peringatan audit. Sebuah permintaan membawa tenant, proyek, jenis sumber daya, dan ID permintaan yang idempoten. Mesin admisi memeriksa kuota laju, konkurensi, dan kumulatif di bawah suatu versi konfigurasi serta melakukan reservasi secara atomik jika diperlukan; penyelesaian atau pembatalan melepaskan reservasi dan menghasilkan event penggunaan. Event membawa ID unik, waktu event, dan dimensi; konsumen mengagregasi secara idempoten, kemudian merekonsiliasi periode tersebut dengan buku besar dan input penagihan. Untuk setiap sumber daya, pilih penulisan otoritatif atau penjualan berlebih terbatas (bounded oversell) di seluruh wilayah; lindungi batas tegas selama kegagalan dan kembalikan sinyal yang dapat dicoba kembali (retryable) jika sesuai.

5. Jawaban mendalam langkah demi langkah

Langkah 1: Tentukan model dan cakupan kuota

Katalog kuota menyimpan jenis sumber daya, cakupan, satuan, jendela waktu, batas, penyesuaian, dan versi konfigurasi. Kuota laju membatasi konsumsi dalam jendela waktu, kuota konkurensi membatasi operasi yang berjalan bersamaan, dan kuota alokasi membatasi sumber daya yang telah dialokasikan. Batas organisasi dapat menjadi batas tertinggi; reservasi tenant dan proyek harus muat dalam sisa kapasitas induk sehingga pemeriksaan independen tidak dapat menjual melebihi total kapasitas (oversell).

Langkah 2: Rancang pemeriksaan sinkron dan reservasi atomik

Jalur sinkron memegang fakta yang memengaruhi admisi: penghitung jendela waktu saat ini, reservasi aktif, dan versi konfigurasi. Gunakan sharded hot keys atau penyimpanan berkonsistensi kuat yang dipartisi berdasarkan tenant untuk hot tenant. Sebuah reservasi harus memeriksa sisa kapasitas dan meningkatkan jumlah yang direservasi secara atomik, mencegah dua permintaan konkuren menggunakan saldo yang sama. Pekerjaan berdurasi panjang menerima ID reservasi; penyelesaian, pembatalan, dan masa kedaluwarsa bersifat idempoten.

checkAndReserve(tenant, dimensions, amount, requestId, configVersion)
  verify configVersion is active
  if requestId already committed: return previous decision
  atomically check remaining quota and add reservation
  persist reservation with expiry and requestId
  return reservationId and retryAfter

Langkah 3: Pisahkan event penggunaan dari agregasi pengukuran

Keberhasilan, kegagalan, pembatalan, dan kedaluwarsa harus memancarkan event. Setiap event membawa tenant, proyek, sumber daya, kuantitas, satuan, waktu event, dan ID event unik. Dengan pengiriman setidaknya sekali (at-least-once delivery), konsumen melakukan deduplikasi berdasarkan ID event; event yang tidak berurutan menggunakan jendela waktu event atau buku besar yang dapat diputar ulang (replayable). Agregat melayani kueri, peringatan ambang batas, dan input penagihan, tetapi tidak boleh menimpa buku besar reservasi sinkron.

Langkah 4: Tangani overage, perubahan kuota, dan keadilan

Tolak atau antrekan saat kuota batas tegas habis; ambang batas fleksibel harus memicu peringatan. Apakah overage diizinkan harus menjadi pengaturan produk yang eksplisit dengan pelaku yang berwenang dan aturan harga. Sebelum menurunkan kuota, periksa reservasi yang ada agar pekerjaan yang telah diterima tidak tiba-tiba kehilangan kapasitas. Hot tenant tidak boleh menghabiskan shard bersama; batas konkurensi tenant, token bucket, dan antrean adil (fair queues) dapat melindungi tenant lain. Permintaan kenaikan harus mengikuti aturan persetujuan atau otomatisasi serta mempertahankan versi lama untuk audit.

Langkah 5: Perilaku multi-wilayah, pemulihan, dan rekonsiliasi

Jika batas tegas harus tepat secara global, rute sumber daya ke satu otoritas atau gunakan penyimpanan yang didukung konsensus. Jika ketersediaan lebih penting, alokasikan anggaran regional dan nyatakan batas maksimal oversell. Selama partisi regional, tolak keputusan batas tegas yang tidak dapat dibuat dengan aman; batas fleksibel dapat diturunkan sementara menjadi sekadar peringatan. Setelah pemulihan, putar ulang event yang tidak dapat diubah (immutable) dan catatan reservasi, bandingkan keputusan admisi, agregat, dan hasil penagihan, serta perbaiki perbedaan dengan event kompensasi daripada mengedit riwayat.

6. Contoh jawaban berkualitas tinggi

Saya akan memisahkan katalog kuota, mesin admisi sinkron, buku besar reservasi, pipeline pengukuran asinkron, dan kueri audit. Katalog mendefinisikan cakupan organisasi, tenant, dan proyek ditambah batas laju, konkurensi, dan alokasi. Admisi menggunakan dimensi tenant dan ID idempotensi untuk pemeriksaan-dan-reservasi atomik; pekerjaan panjang mendapatkan ID reservasi dan membuat penyelesaian, pembatalan, dan kedaluwarsa menjadi idempoten. Event sukses dan gagal masuk ke pipeline at-least-once; konsumen mendeduplikasi berdasarkan ID event dan mengagregasi berdasarkan waktu event untuk peringatan dan penagihan, tanpa menimpa buku besar admisi. Per sumber daya, perilaku multi-wilayah bersifat otoritatif atau penjualan berlebih terbatas. Selama kegagalan, lindungi kuota tegas; setelah pemulihan, putar ulang dan rekonsiliasi, dengan setiap perubahan dan kompensasi yang dapat diaudit.

7. Kesalahan umum

• Menggunakan satu penghitung bersama → hot tenant memperlambat semua pihak → lakukan sharding berdasarkan tenant dan terapkan batasan yang adil.
• Membiarkan agregat asinkron menentukan admisi → keterlambatan event menyebabkan oversell → simpan buku besar reservasi atomik sebagai kebenaran admisi.
• Hanya membahas batas laju → pekerjaan panjang dan penyimpanan mengonsumsi kapasitas tanpa batas → buat model batas laju, konkurensi, dan alokasi.
• Hanya mendeduplikasi ID permintaan → event yang dicoba kembali dihitung dua kali → gunakan kunci idempotensi terpisah untuk reservasi dan event penggunaan.
• Menimpa saldo saat menurunkan kuota → pekerjaan yang telah diterima tiba-tiba ditolak → buat versi konfigurasi dan periksa reservasi yang ada.

8. Pertanyaan lanjutan dan tanggapan

Pertanyaan lanjutan 1: Mengapa tidak hanya mengandalkan penghitung Redis?

Penghitung berguna untuk statistik jendela latensi rendah, tetapi reservasi atomik lintas sumber daya, kedaluwarsa pekerjaan, versi konfigurasi, dan audit memerlukan buku besar yang lebih lengkap. Penghitung hanya dapat menjadi jalur cepat jika ada catatan otoritatif dan proses pembangunan ulang.

Pertanyaan lanjutan 2: Bagaimana Anda mencegah event penggunaan duplikat ditagih dua kali?

Berikan ID unik yang stabil pada setiap event. Konsumen menulis catatan deduplikasi dan agregat dalam satu transaksi, atau menggunakan operasi atomik yang setara. Agregat tetap dapat dihitung ulang; penagihan menggunakan versi agregat yang telah dikonfirmasi dan menyimpan event kompensasi.

Pertanyaan lanjutan 3: Apakah Anda terus menerima pekerjaan selama partisi multi-wilayah?

Jeda atau rute sumber daya ke otoritas untuk kuota batas tegas yang tidak boleh mengalami oversell. Untuk kuota fleksibel dengan anggaran oversell terbatas, terima dari alokasi regional dan catat risiko maksimum. Pilihan ini mengikuti target kerugian bisnis dan konsistensi.

Pertanyaan lanjutan 4: Bagaimana Anda menguji layanan kuota?

Lakukan uji beban pada hot tenant, reservasi konkuren, event duplikat dan tidak berurutan, penurunan konfigurasi, partisi regional, pemutaran ulang konsumen, dan pergantian periode. Pastikan batas tegas tidak pernah dilanggar, operasi idempoten stabil, serta buku besar, agregat, dan penagihan konvergen setelah pemulihan.