Petunjuk dan ruang lingkup
Layanan kuota menjawab apakah sejumlah sumber daya dapat diklaim saat ini; layanan ini tidak memindahkan file atau mengeksekusi operasi bisnis. Rancangan harus memisahkan kapasitas otoritatif, reservasi sementara, dan penggunaan akhir sambil menjaga infrastruktur bersama tetap adil.
Hal yang diuji oleh pewawancara
- Membedakan rate limit, kuota kapasitas, reservasi, dan commit.
- Mencegah oversell dengan pembaruan bersamaan (concurrent updates) dan API yang idempoten.
- Memulihkan reservasi yang kedaluwarsa setelah pemanggil (caller) mengalami crash dan melakukan percobaan ulang (retry).
- Menalar tentang keadilan tenant, hot key, konsistensi regional, dan degradasi.
Pertanyaan klarifikasi yang perlu diajukan
Klarifikasi dimensi sumber daya (request, byte, atau tugas bersamaan), cakupan (tenant, proyek, pengguna, atau endpoint), aturan burst dan hierarki, masa berlaku reservasi, konsistensi penagihan, dan apakah request lintas wilayah dapat menggunakan satu otoritas.
Jawaban 30 detik
Saya akan mempertahankan state machine otoritatif per resource key dengan limit, committed, dan reserved, serta mengekspos API reserve, commit, release, dan query. Reserve melakukan pemeriksaan kondisional atomik dan membawa reservation_id yang idempoten serta waktu kedaluwarsa. Commit mengubah reservasi menjadi penggunaan; release atau kedaluwarsa mengembalikannya. Ledger peristiwa yang tidak dapat diubah (immutable event ledger) dan rekonsiliasi memperbaiki pergeseran (drift), sementara aturan perutean dan keadilan mencegah satu tenant yang padat membuat tenant lain kelaparan sumber daya (starving).
Pembahasan mendalam langkah demi langkah
1. Menentukan batas status dan API
Setiap rekaman kuota memiliki resource key, batas (limit), jumlah yang di-commit, jumlah yang direservasi, versi, dan waktu pembaruan. reserve mengembalikan reservation_id, jumlah yang tersedia, dan waktu kedaluwarsa; commit hanya dapat mengonsumsi reservasinya sendiri; release dapat diulang; query mengembalikan kapasitas yang tersisa dan kebaruan data. Pemanggil mereservasi sebelum menulis sumber daya, melakukan commit setelah berhasil, dan melepaskan (release) jika gagal atau dibatalkan.
2. Mencegah oversell di bawah konkurensi
Pembaruan resource-key harus berupa satu transaksi atomik atau operasi penyimpanan yang dapat dilinearisasi: reservasi hanya jika committed + reserved + amount <= limit. Mengulangi kunci idempotensi mengembalikan hasil asli; mengubah parameternya akan ditolak. Hot key dapat di-shard berdasarkan tenant atau sumber daya, tetapi rancangan harus menyatakan apakah kelebihan kapasitas sementara (overage) diizinkan dan bagaimana shard direkonsiliasi.
3. Mengklaim kembali reservasi yang bocor
Pemanggil dapat mengalami crash setelah melakukan reservasi, jadi simpan waktu kedaluwarsa dan klaim kembali melalui pemindai (scanner) atau antrean tertunda (delayed queue). Tangani perebutan kondisi (race condition) antara pemulihan dan commit dengan status kondisional: reservasi yang telah di-commit tidak dapat di-release, dan reservasi yang telah di-release tidak dapat di-commit. Lacak keterlambatan klaim kembali (reclaim lag) agar pembersihan yang tertunda tidak disalahartikan sebagai kapasitas yang tersedia.
4. Menangani kumpulan bersama (shared pools) dan keadilan
Kumpulan bersama dapat memiliki batasan global, tenant, dan proyek. Periksa batasan tersebut dalam urutan tetap dan di dalam satu transaksi. Alokasikan lonjakan (burst) berdasarkan kuota tenant, prioritas, atau keadilan berbobot (weighted fairness) sehingga satu tenant tidak dapat menghabiskan seluruh kumpulan. Kembalikan sisa kapasitas, waktu percobaan ulang, atau status antrean untuk mengurangi percobaan ulang yang membabi buta.
5. Merancang kegagalan, wilayah, dan rekonsiliasi
Jika otoritas tidak tersedia, tolak reservasi berisiko tinggi secara konservatif daripada menghabiskan kapasitas yang dapat ditagih dari status yang tidak diketahui; pembacaan berisiko rendah dapat mengembalikan perkiraan yang diberi stempel waktu. Tetapkan tenant ke home region, atau tentukan batas kelebihan lokal eksplisit dan lakukan rekonsiliasi secara asinkron. Tulis setiap reserve, commit, dan release ke ledger yang tidak dapat diubah, bandingkan dengan penggunaan sumber daya aktual, dan perbaiki pergeseran dengan tugas kompensasi yang idempoten.
Contoh jawaban yang kuat
Saya akan mengklarifikasi sumber daya, hierarki tenant, masa berlaku reservasi, dan persyaratan konsistensi. Layanan menyimpan limit, committed, reserved, dan version per resource key serta mengekspos operasi reserve, commit, release, dan query berbasis reservation_id. Reserve memeriksa jumlah secara atomik; percobaan ulang mengembalikan hasil yang sama. Pemanggil melakukan commit setelah penulisan berhasil, melepaskan jika gagal, dan proses reclaimer menangani kedaluwarsa. Kumpulan bersama memeriksa batas global dan tenant secara bersamaan serta menggunakan perutean tetap, prioritas, atau keadilan berbobot. Jika terjadi kegagalan otoritas, penulisan berisiko tinggi akan gagal tertutup (fail closed). Penempatan lintas wilayah menggunakan home region tenant atau kelebihan batas yang terikat secara eksplisit. Ledger yang tidak dapat diubah dan rekonsiliasi berkala menjaga kuota yang terlacak tetap selaras dengan penggunaan aktual.
Kesalahan umum
- Memperlakukan kuota sebagai rate limiter yang hanya mengembalikan status 429.
- Membaca kapasitas yang tersisa dan menulisnya nanti tanpa kondisi atomik.
- Menghilangkan identitas reservasi, masa kedaluwarsa, dan semantik idempotensi.
- Membiarkan pemanggil yang mengalami crash menahan kapasitas selamanya.
- Mengabaikan kumpulan bersama, hierarki, dan keadilan terhadap noisy-neighbor.
- Menerapkan fail open selama pemadaman penyimpanan dan memperbaiki penghitung secara manual setelahnya.
Pertanyaan lanjutan dan tanggapan
Pemanggil mengalami timeout sebelum commit. Coba lagi atau reservasi ulang?
Lakukan query atau coba lagi commit dengan reservation_id yang sama terlebih dahulu. Buat reservasi baru hanya setelah memastikan reservasi lama telah di-release atau kedaluwarsa.
Bagaimana jika beberapa produk berbagi satu kuota tenant?
Perlakukan tenant sebagai induk bersama dan produk sebagai batasan turunan, lalu periksa keduanya dalam satu transaksi. Laporkan lapisan mana yang habis sehingga klien dapat mengantre atau menurunkan fungsionalitas (degrade).
Bisakah beberapa wilayah melakukan reservasi secara bersamaan?
Untuk kapasitas penagihan yang tidak boleh di-oversell, gunakan satu otoritas atau koordinasi yang kuat. Jika kelebihan terbatas dapat diterima, berikan batas pinjaman ke setiap wilayah dan rekonsiliasi selisihnya secara eksplisit.
Bagaimana cara mendeteksi pergeseran (drift) kuota?
Bandingkan log peristiwa ledger dan pemindaian sumber daya dengan penggunaan yang di-commit, direservasi, dan aktual berdasarkan tenant dan jenis sumber daya. Berikan peringatan jika ada perbedaan dan jalankan tugas kompensasi yang dapat diaudit dan idempoten.