Petunjuk dan ruang lingkup
Endpoint bootstrap mengorkestrasi tiga panggilan downstream. Profil dan izin diperlukan untuk shell yang benar; feed mungkin basi (stale) atau tidak ada. Endpoint harus mengembalikan respons berjenis data (typed) yang memungkinkan klien merender bagian yang aman secara independen. Anggaran p95 sebesar 300 md mencakup overhead orkestrasi, dan rancangan harus menyatakan data mana yang dapat di-cache dan untuk berapa lama.
Apa yang sedang diuji oleh pewawancara
- Menurunkan paralelisme, batas waktu (timeout budget), dan semantik kegagalan dari kebutuhan yang terlihat oleh pengguna.
- Membedakan antara data yang hilang, hasil kosong, dan kesalahan dependensi.
- Menyusun retries, circuit breaker, bulkhead, dan kebijakan cache tanpa melipatgandakan beban.
- Merancang kontrak respons yang dapat berkembang (evolvable) dan sinyal operasional yang berguna.
Pertanyaan klarifikasi yang perlu diajukan
Tanyakan apakah izin boleh basi, apakah data feed memiliki batas kesegaran (freshness limit), apakah klien dapat merender secara progresif, dan apakah panggilan berbagi konteks tenant atau otorisasi. Jika izin tidak pernah diizinkan basi, data tersebut tetap berada di jalur kritis; jika feed memiliki target kesegaran lima menit, cache stale-while-revalidate dapat melindungi latensi.
Jawaban 30 detik
Saya akan membuat gateway melakukan autentikasi sekali, menyebarkan (fan-out) panggilan profil, izin, dan feed secara paralel, serta mencadangkan batas waktu akhir (deadline) untuk perakitan respons. Bagian wajib bersifat fail closed; bagian opsional mengembalikan status tidak tersedia secara eksplisit beserta kode alasan dan stempel waktu kesegaran. Percobaan ulang dibatasi hanya untuk panggilan transien yang idempoten dan mengonsumsi anggaran bersama. Batas waktu per dependensi, bulkhead, circuit breaker, stale cache, dan amplop problem-details yang bertipe mencegah satu pemadaman membuat shell menjadi kosong. Metrik melacak keberhasilan tingkat bagian, habisnya batas waktu, penyajian data basi, dan saturasi dependensi.
Pembahasan mendalam langkah demi langkah
1. Tetapkan anggaran waktu dan konkurensi
Pada 2.000 permintaan per detik, tiga panggilan berurutan akan memboroskan anggaran 300 md. Lakukan fan-out secara bersamaan, berikan setiap dependensi batas waktu di bawah batas waktu keseluruhan, dan pertahankan proses perakitan serta serialisasi di dalam sisa waktu yang ada. Gunakan connection pool terbatas dan sinyal pembatalan per permintaan sehingga dependensi yang kehabisan batas waktu berhenti mengonsumsi komputasi.
2. Tentukan semantik respons parsial
Kembalikan amplop yang stabil dengan status untuk setiap bagian: ready, stale, atau unavailable. Sertakan alasan yang dapat dibaca mesin dan stempel waktu data, tetapi jangan membocorkan nama host internal. Kesalahan profil atau izin harus fail closed atau mengembalikan status login/tindakan; batas waktu feed yang terlampaui tetap dapat membiarkan shell dapat digunakan. Objek kesalahan yang mengikuti RFC 9457 dapat mendeskripsikan kegagalan seluruh permintaan tanpa berpura-pura bahwa setiap bagian gagal.
3. Lindungi dependensi dari percobaan ulang dan pemadaman
Coba ulang hanya untuk kegagalan transien, hanya untuk pembacaan idempoten, dan hanya sekali dalam batas waktu bersama. Tambahkan jitter dan hentikan percobaan ulang saat sirkuit terbuka. Bulkhead membatasi panggilan bersamaan per dependensi; cache basi atau nilai default terbatas menangani data feed opsional. Circuit breaker berguna ketika kegagalan downstream berulang dapat menghabiskan seluruh kapasitas gateway, tetapi itu tidak menggantikan batas waktu atau probe pemulihan.
4. Kembangkan dan amati kontrak
Lakukan versioning field secara aditif, biarkan klien mengabaikan bagian yang tidak dikenal, dan sertakan pengidentifikasi korelasi permintaan. Catat latensi dependensi, penyebab batas waktu, status sirkuit, usia cache, status bagian, dan ukuran muatan (payload). Lacak pohon fan-out, ambil sampel permintaan yang lambat, dan beri peringatan pada tingkat kegagalan bagian yang wajib, usia stale, serta volume percobaan ulang. Pengujian kontrak harus mencakup hasil campuran seperti izin siap, profil basi, dan feed tidak tersedia.
Contoh jawaban yang kuat
Saya akan mengklarifikasi kesegaran dan apakah rendering progresif diizinkan. Gateway mengautentikasi sekali, menyebarkan tiga pembacaan, dan menetapkan batas waktu per panggilan dalam anggaran keseluruhan 300 md. Gateway mengembalikan status tingkat bagian ready, stale, atau unavailable. Identitas dan izin wajib bersifat fail closed; data feed dapat berasal dari cache basi yang dibatasi. Satu percobaan ulang dengan jitter diizinkan hanya untuk pembacaan transien yang idempoten, dilindungi oleh bulkhead dependensi dan circuit breaker. Metrik dan pelacakan (traces) mengekspos kegagalan bagian serta tekanan batas waktu, sementara versioning aditif menjaga klien lama tetap berfungsi.
Kesalahan umum
- Memanggil dependensi secara berurutan → latensi bertambah melebihi anggaran → lakukan fan-out dengan pool terbatas dan batas waktu.
- Mengembalikan HTTP 200 dengan nilai null yang ambigu → klien tidak dapat membedakan data kosong dari kegagalan → gunakan status bagian dan kode alasan eksplisit.
- Mencoba ulang setiap kesalahan di setiap lapisan → satu pemadaman menjadi badai percobaan ulang (retry storm) → klasifikasikan kesalahan dan terapkan satu anggaran percobaan ulang bersama.
- Meng-cache izin tanpa kebijakan → akses dapat bertahan melampaui otorisasi aslinya → tentukan batas kesegaran atau buat fail closed.
- Menggunakan satu sirkuit global → pemadaman feed memblokir data identitas → isolasi pemutus sirkuit dan bulkhead berdasarkan dependensi.
- Hanya mencatat latensi total → kegagalan opsional dan wajib tidak dapat dibedakan → kirimkan metrik dan pelacakan tingkat bagian.
Pertanyaan lanjutan dan tanggapan
Feed lambat tetapi pengguna membutuhkan shell segera. Apa yang berubah?
Persingkat batas waktu feed, sajikan hasil basi yang dibatasi jika usianya dapat diterima, dan kembalikan unavailable jika tidak. Jaga agar respons shell tetap independen sehingga klien dapat memuat feed nanti.
Data izin basi di satu wilayah. Bisakah Anda menyajikannya?
Hanya jika kebijakan otorisasi secara eksplisit mengizinkan kebasian tersebut dan respons mengomunikasikan usianya. Untuk tindakan sensitif, periksa kembali terhadap sumber otoritatif dan buat fail closed jika ada ketidakpastian.
Bagaimana Anda mencegah percobaan ulang melampaui 300 md?
Teruskan satu batas waktu mutlak melalui konteks fan-out. Sebelum setiap percobaan ulang, cadangkan waktu untuk percobaan dan perakitan; jika tidak ada waktu tersisa, kembalikan status batas waktu bagian daripada memulai pekerjaan yang tidak dapat diselesaikan.
Dependensi pulih setelah sirkuit terbuka. Bagaimana lalu lintas dipulihkan?
Setelah periode cool-down, kirim sejumlah kecil probe half-open. Tutup sirkuit hanya setelah probe yang berhasil memenuhi kriteria batas waktu dan kesalahan yang sama; jika tidak, biarkan tetap terbuka dengan waktu probe berikutnya yang dapat diamati.