Pertanyaan dan Kapan Ini Berlaku
API control-plane melayani health check, penulisan controller, kueri tenant, dan watch yang berjalan lama. Lonjakan lalu lintas atau satu tenant yang bising (noisy tenant) dapat memperlambat setiap permintaan. Desain kontrol prioritas dan keadilan, serta jelaskan bagaimana klasifikasi, batas konkurensi, antrean, batas waktu, dan degradasi bekerja bersama.
Hal yang Dievaluasi Pewawancara
- Mengubah konsep "penting" menjadi kelas permintaan yang dapat diaudit, bukan hak istimewa tim yang permanen.
- Melindungi control plane dengan seat, antrean, dan kuota, bukan hanya pembatas laju (rate limiter) ingress.
- Menjelaskan granularitas keadilan, okupansi permintaan berdurasi panjang, isolasi tenant, dan degradasi saat terjadi kegagalan.
- Memvalidasi desain dengan latensi, tingkat penolakan, usia antrean, dan waktu pemulihan controller.
Pertanyaan Klarifikasi Sebelum Anda Menjawab
- Permintaan mana yang merupakan operasi penulisan kritis terhadap keselamatan, dan operasi pembacaan atau watch mana yang dapat ditunda?
- Apakah keadilan dihitung berdasarkan tenant, identitas, beban kerja, atau jenis sumber daya? Apakah jalur admin darurat diizinkan?
- Apakah Anda melindungi server API, penyimpanan downstream, atau keduanya?
- Apakah permintaan berdurasi panjang mengonsumsi banyak seat, dan bagaimana seat dilepaskan saat terputus?
- Bisakah kondisi kelebihan beban (overload) mengembalikan 429, atau haruskah sistem mempertahankan tingkat keberhasilan minimum dan sinyal percobaan ulang (retry)?
Kerangka Jawaban 30 Detik
Saya akan memetakan permintaan berdasarkan identitas, metode, dan sumber daya ke dalam alur prioritas yang terikat, kemudian memberikan seat konkurensi dan antrean yang adil untuk setiap alur. Prioritas tinggi mendapatkan kapasitas dasar yang terikat; prioritas rendah mengantre atau ditolak saat berada di bawah tekanan. Permintaan berdurasi panjang diklasifikasikan secara terpisah dan dikenakan biaya untuk okupansi berkelanjutan. Setiap penolakan membawa sinyal percobaan ulang yang dapat ditindaklanjuti. Saya akan menentukan gerbang peluncuran (rollout gate) berdasarkan latensi p99, usia antrean, tingkat 429, saturasi downstream, dan waktu pemulihan untuk controller kritis.
Pembahasan Mendalam Langkah Demi Langkah
Langkah 1: Bangun kelas permintaan yang dapat dijelaskan
Klasifikasikan dari identitas yang dapat diverifikasi, metode HTTP, sumber daya target, dan status berjalan lama. Jangan biarkan klien mengirimkan bidang "prioritas tinggi" secara sembarangan. Pisahkan penulisan controller, heartbeat node, kueri admin, dan daftar massal ke dalam alur yang berbeda, lalu catat aturan yang cocok dalam log.
Langkah 2: Modelkan kapasitas sebagai seat
Seat merepresentasikan kapasitas layanan simultan, bukan hanya jumlah permintaan. Pembacaan cepat dapat mengonsumsi satu seat; kueri lambat atau watch mungkin membutuhkan lebih banyak. Lepaskan seat setelah selesai atau dibatalkan. Berikan batas nominal untuk setiap prioritas sambil mempertahankan batas atas seat global agar kapasitas dasar tidak melebihi kapasitas aman.
Langkah 3: Terapkan antrean yang adil di dalam setiap prioritas
Di dalam sebuah prioritas, gunakan antrean adil berbobot (weighted fair queue) yang dikunci berdasarkan identitas tenant atau alur sehingga satu tenant tidak dapat memenuhi seluruh kelas tersebut. Kirim alur tidak kosong yang berada di bawah batas saat ini. Penuaan (aging) dapat meningkatkan bobot permintaan yang berulang kali tertunda, tetapi tidak boleh melewati batas atas seat global.
Langkah 4: Tangani permintaan berdurasi panjang dan dependensi
Berikan anggaran terpisah, durasi maksimum, dan pembatalan berbasis heartbeat untuk watch dan tailing log. Tempatkan bulkhead konkurensi independen di sekitar penyimpanan, cache, dan layanan eksternal; antrean ingress tidak boleh mentransfer tekanan tanpa batas ke downstream. Coba ulang hanya kegagalan yang dapat dicoba ulang, dengan backoff eksponensial dan jitter.
Langkah 5: Tentukan tindakan saat kelebihan beban
Saat tekanan meningkat, jeda pekerjaan prioritas rendah yang baru, lalu batasi daftar massal dan filter yang mahal, dan akhirnya kembalikan 429 ketika permintaan tidak dapat mengantre. Sertakan petunjuk waktu tunggu yang jelas dalam respons; klien tetap memerlukan batasan percobaan ulang, jitter, dan tenggat waktu (deadline). Jika penulisan kritis tidak boleh dibuang, masukkan ke dalam antrean tahan lama (durable queue) dan kembalikan ID operasi yang dapat ditanyakan.
Langkah 6: Amati keadilan, bukan hanya latensi rata-rata
Pantau p50, p99, usia antrean, okupansi seat, 429, pembatalan, dan kesalahan downstream berdasarkan prioritas, tenant, dan jenis permintaan. Buat peringatan untuk waktu tunggu maksimum, keberhasilan penulisan kritis, waktu pemulihan, dan disparitas layanan antar tenant. Uji beban harus mencakup lonjakan satu tenant, kehabisan seat oleh permintaan berdurasi panjang, kesalahan klasifikasi, dan pemulihan controller.
Langkah 7: Kembangkan dan lakukan rollback dengan aman
Catat kecocokan klasifikasi baru dalam mode hanya-observasi sebelum menerapkan batas. Buat versi dan audit konfigurasi, serta pertahankan jalur operasional yang dibatasi. Saat seat atau prioritas berubah, bandingkan kapasitas downstream dan distribusi antrean historis; jangan hanya mengandalkan metrik lapisan API.
Contoh Jawaban Berkualitas Tinggi
Saya akan memodelkan kapasitas control-plane sebagai kumpulan seat global. Permintaan dipetakan ke alur prioritas menggunakan atribut identitas, metode, sumber daya, dan durasi berjalan. Penulisan controller dan heartbeat node mendapatkan seat dasar, tetapi jumlah total kapasitas dasar tetap berada di bawah kapasitas aman. Pembacaan tenant biasa berbagi antrean adil berbobot. Watch dikenakan biaya terpisah dan memiliki durasi maksimum; pembatalan segera melepaskan seat. Selama kelebihan beban, jeda pembacaan massal, batasi filter mahal, dan kembalikan 429 dengan petunjuk tunggu ketika pekerjaan tidak dapat mengantre. Penulisan yang harus selesai diarahkan ke antrean yang tahan lama. Sebelum penerapan, saya akan mengukur kecocokan klasifikasi dan usia antrean tenant; setelah peluncuran, keberhasilan penulisan kritis, p99, 429, saturasi downstream, dan waktu pemulihan menjadi gerbang rollback.
Kesalahan Umum
- Hanya menetapkan batas QPS global, sehingga memungkinkan permintaan berdurasi panjang menghabiskan konkurensi.
- Memberikan prioritas tak terbatas kepada admin atau tenant dan menciptakan kelaparan sumber daya (starvation) yang tidak dapat diaudit.
- Hanya membebankan biaya berdasarkan jumlah permintaan tanpa memodelkan pembacaan, daftar, dan watch secara berbeda.
- Membuat setiap klien mencoba ulang 429 secara bersamaan dan menciptakan badai percobaan ulang (retry storm) yang tersinkronisasi.
- Hanya melihat latensi rata-rata dan melewatkan waktu tunggu maksimum pada antrean prioritas rendah.
- Mengubah batas tanpa pengujian canary, pembuatan versi, atau jalur rollback.
Pertanyaan Lanjutan dan Tanggapan
Lanjutan 1: Mengapa tidak hanya menggunakan token bucket?
Token bucket membatasi laju kedatangan tetapi tidak mengekspresikan biaya konkurensi yang berbeda, okupansi permintaan berdurasi panjang, atau keadilan tenant. Ini dapat menjadi satu lapisan ingress, tetapi seat dan antrean tetap diperlukan.
Lanjutan 2: Bisakah prioritas tinggi membuat prioritas rendah kelaparan (starve)?
Ya, kecuali prioritas tinggi juga memiliki batas dan sistem memberlakukan pembagian kuota cadangan, batas layanan berturut-turut maksimum, atau penuaan (aging). Jalur darurat harus tetap diaudit dan dibatasi kapasitasnya.
Lanjutan 3: Berapa banyak seat yang harus dikonsumsi oleh sebuah watch?
Tidak ada konstanta universal. Ukur koneksi, laju peristiwa, biaya serialisasi, dan tekanan kueri downstream, pilih baseline yang konservatif, dan kalibrasi dengan uji beban. Batas waktu dan pemutusan koneksi harus melepaskan seat.
Lanjutan 4: Siapa yang menentukan waktu coba ulang untuk 429?
Server memberikan petunjuk tunggu minimum berdasarkan perkiraan pemulihan; klien menambahkan backoff eksponensial, jitter, dan tenggat waktu. Petunjuk tersebut bukan jaminan kapasitas, sehingga klien tetap harus membatasi jumlah upaya.
Lanjutan 5: Bagaimana Anda membuktikan keadilan?
Tentukan tujuan tingkat tenant seperti pangsa seat, usia antrean maksimum, dan tingkat penyelesaian dalam suatu prioritas. Bandingkan distribusi selama lonjakan beban satu tenant dan beban campuran, alih-alih hanya melaporkan rata-rata global.
Lanjutan 6: Bagaimana jika sebuah aturan salah mengklasifikasikan penulisan kritis sebagai prioritas rendah?
Simpan log pencocokan aturan dan tinjauan manusia, serta rilis konfigurasi sebagai artefak berversi. Jika tingkat keberhasilan penulisan kritis turun, segera lakukan rollback versi klasifikasi dan gunakan jalur keselamatan terbatas untuk pekerjaan yang sedang mengantre.