Topik wawancara representatif

Wawancara System Design: Merancang Adaptive Admission-Control Gateway

Desain sistemSulit
Tim Redaksi Offer.ccDipublikasikan Diperbarui

Pertanyaan

Rancang gateway yang menentukan permintaan mana yang boleh menggunakan kapasitas layanan dan mana yang fail fast ketika layanan atau dependensi mendekati saturasi, sambil menjaga latensi yang dapat diprediksi untuk tugas-tugas penting.

Masalah dan ruang lingkup

Gateway berada di depan beberapa API. Lalu lintas dapat meningkat 20x lipat dalam satu menit, sementara basis data, pencarian, dan dependensi pihak ketiga memiliki kapasitas yang berbeda-beda. Rancang klasifikasi permintaan, admisi, antrean, load shedding, respons terdegradasi, dan pemulihan. Otorisasi bisnis, WAF lengkap, dan penambahan kapasitas ke dependensi yang rusak berada di luar cakupan.

Hal yang dievaluasi pewawancara

Membedakan rate limiting dari perlindungan kelebihan beban (overload protection). Rate limiting biasanya membatasi lalu lintas identitas selama periode tertentu; admission control memutuskan apakah suatu pekerjaan boleh menggunakan sumber daya nyata dengan mempertimbangkan konkurensi, usia antrean, biaya, dan kesehatan dependensi. Jawaban yang kuat menjelaskan apa yang di-drop, alasannya, bagaimana pekerjaan berprioritas rendah terhindar dari starvation, dan bagaimana pemulihan mencegah lonjakan lalu lintas yang tiba-tiba.

Pertanyaan klarifikasi

  • Permintaan mana yang kritis, dan mana yang dapat ditunda, di-cache, atau diaproksimasi?
  • Apakah Anda melindungi gateway, satu dependensi, satu penyewa (tenant), atau setiap batasan sistem?
  • Berapa lama pekerjaan boleh menunggu, dan apakah klien harus mencoba kembali (retry), melakukan polling, atau menerima hasil kosong?
  • Apakah kapasitas harus adil di seluruh tenant, wilayah, API, atau kelas biaya?
  • Kode status, header, dan metrik keputusan mana yang dapat dilihat oleh pemanggil?

Kerangka jawaban 30 detik

"Saya akan mengklasifikasikan permintaan berdasarkan metadata rute tepercaya, tenant, dan biaya, lalu melakukan pemeriksaan konkurensi ketat dan anggaran sebelum menempatkan pekerjaan yang diterima ke dalam bounded queue yang dipartisi berdasarkan prioritas dan tenant. Sebuah pengontrol menyesuaikan target konkurensi dari pekerjaan yang sedang berjalan (in-flight), usia antrean, tingkat kesalahan, dan sinyal dependensi. Selama kelebihan beban, ia menolak pekerjaan bernilai rendah atau yang dapat dicoba ulang terlebih dahulu dan mencadangkan kapasitas untuk permintaan kritis. Operasi yang dapat di-cache atau diaproksimasi menggunakan jalur terdegradasi, sementara penolakan menyertakan waktu percobaan ulang. Pemulihan menggunakan peningkatan bertahap, sewa (leases), dan probe terkontrol sehingga percobaan ulang tidak memicu kelebihan beban kedua."

Desain mendalam langkah demi langkah

Gateway memvalidasi ukuran permintaan, anggaran batas waktu (timeout budget), dan kuota tenant, lalu memetakan permintaan ke label criticality, cost, retryability, dan dependency. Konfigurasi rute tepercaya menyediakan label; klien tidak dapat mendeklarasikan prioritas sendiri. Lalu lintas kesehatan dan manajemen menggunakan kumpulan khusus (reserved pool) sehingga lalu lintas data tidak dapat menghabiskan control plane.

Pertahankan batas in-flight, batas antrean, dan batas waktu per API serta dependensi. Semaphore atau lease melindungi sumber daya nyata; antrean dibatasi (bounded) alih-alih menyembunyikan kelebihan beban dalam backlog tak terbatas. Konsumsi anggaran hanya setelah admisi, dan lepaskan lease saat terjadi pembatalan atau batas waktu habis. Permintaan streaming memerlukan anggaran koneksi dan byte terpisah agar satu streaming panjang tidak menghabiskan seluruh slot.

Penjadwal (scheduler) memilih pekerjaan berdasarkan prioritas, bobot tenant, dan usia. Pekerjaan kritis menerima reservasi konkurensi minimum; pekerjaan berprioritas rendah dapat di-drop atau ditunda, dengan proses penuaan (aging) untuk mencegah starvation. Lonjakan lalu lintas dari satu tenant tidak boleh meminjam reservasi tenant lain. Di seluruh wilayah, keputusan cepat lokal dapat menerima kesalahan counter yang terbatas daripada menambahkan dependensi koordinasi global yang rapuh.

Pada setiap jendela waktu singkat, sebuah pengontrol menyesuaikan target konkurensi: kurangi saat latensi p95, usia antrean, atau kesalahan hilir (downstream) melintasi ambang batas; tingkatkan secara perlahan saat stabil. Sinyal yang halus dan histeresis mencegah osilasi pada ambang batas. Percobaan ulang klien bukan merupakan sinyal kesehatan sistem. Lacak amplifikasi percobaan ulang dan batasi lalu lintas balik dengan Retry-After, jitter, dan anggaran percobaan ulang.

Pilih shedding berdasarkan semantik permintaan. Rekomendasi, analitik, dan pratinjau dapat mengembalikan hasil cache atau aproksimasi; operasi penulisan, pembayaran, dan perubahan izin biasanya fail fast dan memerlukan percobaan ulang yang aman. Respons terdegradasi memuat versi, tanda waktu (timestamp), dan kesegaran (freshness) alih-alih berpura-pura lengkap. Gateway tidak boleh membuang side effect yang tidak dapat diulang dan tidak dipahaminya.

Ketika dependensi mengalami timeout atau error, isolation pool membatasi koneksi, konkurensi, dan anggaran percobaan ulangnya; circuit breaker hanya mengizinkan probe terkontrol. Respons yang di-cache dan statis menggunakan pool yang terisolasi. Jika berhasil, naikkan lalu lintas secara bertahap. Catat keputusan admisi, versi kebijakan, alasan penolakan, waktu tunggu antrean, dan sinyal dependensi sehingga tumpukan respons 429 tetap dapat didiagnosis.

Pantau tingkat admisi, tingkat penolakan berdasarkan prioritas dan tenant, usia antrean tertua, pekerjaan in-flight, latensi p95/p99, kesalahan hilir, amplifikasi percobaan ulang, kesegaran terdegradasi, dan kurva pemulihan. Rekonsiliasi anggaran sumber daya dengan koneksi aktual, thread, koneksi basis data, dan tugas antrean. Lakukan pengujian gangguan (fault injection) seperti lonjakan lalu lintas, dependensi lambat, kesalahan konfigurasi kebijakan, hilangnya pengontrol, partisi regional, dan replay storm.

Contoh jawaban berkualitas tinggi

"Di gateway, saya akan menyematkan label kekritisan, biaya, kemampuan coba ulang (retryability), dan dependensi tepercaya. Setiap API dan dependensi memiliki konkurensi terbatas, antrean terbatas, dan kapasitas cadangan; penjadwal menggunakan prioritas, bobot tenant, dan aging. Sebuah pengontrol menyesuaikan target konkurensi dari latensi p95, usia antrean, dan kesalahan downstream dengan histeresis. Di bawah kondisi kelebihan beban, ia menolak pekerjaan bernilai rendah atau yang dapat dicoba ulang terlebih dahulu dan mempertahankan kapasitas untuk operasi penulisan kritis; pratinjau dapat mengembalikan data cache beserta status kesegarannya.

Setiap penolakan menyertakan alasan yang stabil, Retry-After, dan ID permintaan. Isolation pool, anggaran percobaan ulang, dan probe terkontrol mencegah kegagalan beruntun (cascading failures); pemulihan ditingkatkan secara bertahap. Metrik mencakup keadilan, amplifikasi percobaan ulang, kesegaran, dan kurva pemulihan, sementara fault injection menguji hilangnya pengontrol, partisi regional, dan replay storm. Kontrak utamanya adalah latensi jalur kritis yang dapat diprediksi saat terjadi kelebihan beban, bukan waktu tunggu tak terbatas untuk setiap permintaan."

Kesalahan umum

  • Hanya menambahkan pembatas QPS tetap → hambatan (bottleneck) bisa berupa koneksi, CPU, atau dependensi → gabungkan sinyal konkurensi, antrean, dan kesehatan.
  • Menggunakan antrean tak terbatas → latensi melonjak tinggi dan kekurangan kapasitas tetap tersembunyi → batasi antrean dan tolak secara eksplisit.
  • Memberikan prioritas yang sama untuk setiap permintaan → pekerjaan bernilai rendah menyingkirkan jalur kritis → cadangkan kapasitas semantik dan terapkan aging pada pekerjaan.
  • Membiarkan klien melaporkan prioritas sendiri → penyerang dapat melewati perlindungan → klasifikasikan dari kebijakan rute tepercaya.
  • Mencoba ulang tanpa anggaran saat kelebihan beban → amplifikasi membuat dependensi lumpuh → gunakan anggaran, jitter, dan Retry-After.
  • Mengembalikan data kedaluwarsa tanpa informasi kesegaran → pengguna mengira itu data terbaru yang valid → sertakan versi, timestamp, dan sumber.
  • Melepaskan semua lalu lintas secara instan → replay storm membebani pemulihan secara berlebih → tingkatkan secara bertahap dengan probe terkontrol.
  • Mewajibkan counter global yang presisi → jalur perlindungan mendapatkan lebih banyak dependensi kegagalan → buat keputusan lokal cepat dengan toleransi error yang terbatas.

Pertanyaan lanjutan dan jawaban

Pertanyaan lanjutan 1: Apa perbedaan admission control dengan rate limiting?

Rate limiting membatasi lalu lintas identitas selama suatu rentang waktu. Admission control memutuskan apakah suatu pekerjaan dapat menggunakan sumber daya nyata berdasarkan konkurensi, waktu tunggu antrean, biaya, dan kesehatan dependensi. Keduanya dapat berdampingan, tetapi batas QPS tetap bukanlah admisi sumber daya.

Pertanyaan lanjutan 2: Bagaimana cara mencegah tenant berprioritas rendah menyingkirkan tenant kritis?

Cadangkan kumpulan atau kuota minimum untuk tenant kritis, lalu jadwalkan kapasitas bersama berdasarkan bobot. Berikan anggaran maksimum untuk setiap tenant agar lonjakan tidak dapat meminjam kuota cadangan tanpa batas.

Pertanyaan lanjutan 3: Mengapa tidak mengantrekan semuanya saja?

Setelah batas waktu bisnis terlampaui, menunggu hanya akan menciptakan timeout dan percobaan ulang daripada menghasilkan pekerjaan yang berguna. Bounded queue memperjelas adanya kelebihan permintaan dan memberikan umpan balik kepada pemanggil.

Pertanyaan lanjutan 4: Sinyal apa saja yang menggerakkan pengontrol?

Minimal latensi p95/p99, pekerjaan in-flight, usia antrean tertua, tingkat kesalahan dependensi, dan utilisasi sumber daya. Lakukan penghalusan (smoothing), tambahkan histeresis, dan pisahkan lalu lintas percobaan ulang klien dari permintaan normal yang sehat.

Pertanyaan lanjutan 5: Bisakah operasi penulisan kritis didegradasi?

Hanya jika semantik bisnis mengizinkan enqueue secara persisten yang diikuti dengan penyelesaian asinkron. Pembayaran, izin, dan inventaris tidak boleh mengembalikan status berhasil palsu; operasi tersebut harus gagal secara aman dan dicoba ulang dengan sifat idempoten.

Pertanyaan lanjutan 6: Bagaimana Anda memverifikasi bahwa pemulihan tidak akan memicu kelebihan beban lagi?

Injeksi pemulihan dependensi, backlog, dan percobaan ulang klien, lalu amati laju peningkatan, reservasi, usia antrean, dan error. Tetapkan peningkatan maksimum, masa jeda (cooldown), dan tombol jeda manual.

Sumber publik

Pertanyaan terkait

Alat wawancara terkait

Gunakan Jawab untuk jawaban desain sistem

Perjelas persyaratan terlebih dahulu, lalu lanjutkan dengan skala, arsitektur, pilihan komponen, dan trade-off.

Lihat alat