Petunjuk dan konteks
Aplikasi mengirimkan pembaruan kursor, pose, atau pratinjau seret berfrekuensi tinggi di mana status terbaru lebih penting daripada setiap pembaruan historis. Jelaskan cara menggunakan datagrams WebTransport, menangani kehilangan yang tidak berurutan (unordered loss), anggaran ukuran, backpressure, penyambungan ulang (reconnect), dan browser yang tidak didukung. Jangan hanya membandingkan WebSocket dengan HTTP/3.
Hal yang dievaluasi oleh pewawancara
- Mengetahui bahwa datagram tidak menjamin pengiriman atau urutan dan tidak dapat membawa fakta penting.
- Merancang versi pesan, masa kedaluwarsa, aturan pembuangan (discard rules), dan anggaran lalu lintas.
- Memisahkan datagram dari stream yang andal serta menangani antrean, kongesti, dan penyambungan ulang.
- Menyediakan HTTPS, deteksi kapabilitas, fallback, dan observabilitas.
Pertanyaan klarifikasi yang perlu diajukan
- Pesan mana yang merupakan status sementara (transient state) yang dapat direkonstruksi, dan mana yang memerlukan persistensi berurutan yang andal?
- Berapa ukuran datagram, laju pembaruan, target latensi, dan tingkat kehilangan (loss rate) yang dapat diterima?
- Bisakah klien memulihkan diri dari snapshot, dan dari mana status otoritatif diperoleh saat penyambungan ulang?
- Apakah browser dan jaringan mendukung WebTransport, HTTPS, dan HTTP/3? Apa fallback-nya?
Kerangka jawaban 30 detik
Saya akan mencadangkan datagram untuk status saat ini yang dapat dibuang dan menempatkan operasi, izin, serta hasil akhir pada stream yang andal atau penyimpanan server. Setiap pembaruan status akan membawa urutan, stempel waktu, dan versi objek; penerima hanya menerapkan versi yang lebih baru dan membuang data usang. Pengirim membatasi ukuran, laju, dan panjang antrean daripada melakukan buffering tanpa batas. Koneksi dimulai dengan snapshot yang andal, penyambungan ulang mengambil kembali status otoritatif, dan kegagalan kapabilitas akan dialihkan ke saluran andal yang ada.
Pembahasan mendalam langkah demi langkah
1. Menetapkan batas keandalan
Kursor dan pratinjau dapat direkonstruksi dan cocok untuk datagram. Operasi dokumen, perubahan izin, dan hasil commit memerlukan jalur berurutan yang andal. Berbagi satu koneksi tidak membuat kedua semantik transport tersebut dapat dipertukarkan.
2. Merancang pesan yang dapat dibuang
Lampirkan urutan monotonik, waktu pembuatan, dan versi sesi ke setiap objek. Terima hanya versi yang lebih baru; buang pesan di luar jendela kesegaran (freshness window), untuk objek yang dihapus, atau yang berada di belakang versi saat ini. Datagram tidak boleh berisi fakta unik yang tidak dapat dipulihkan oleh snapshot.
3. Mengontrol anggaran dan pemulihan
Batasi ukuran pesan, laju pengiriman, dan panjang antrean; ketika antrean mendekati batasnya, gabungkan (coalesce) status terbaru untuk setiap objek. Setelah menyambung ulang, ambil snapshot melalui stream yang andal sebelum menerapkan datagram baru agar status sementara yang usang tidak dapat menimpanya.
4. Kompatibilitas dan observabilitas
Bentuk koneksi hanya dalam konteks aman dan deteksi kapabilitas browser. Catat tingkat pembuangan (discard rate), panjang antrean, kegagalan pengiriman, penyambungan ulang, dan waktu perbaikan snapshot. Beralihlah ke WebSocket atau polling saat WebTransport tidak tersedia sambil mempertahankan protokol versi status yang sama.
Contoh jawaban model
Saya akan mengklasifikasikan pesan sebagai status sementara yang dapat direkonstruksi atau fakta non-lossy: kursor dan pratinjau seret menggunakan datagram, sementara operasi dokumen, izin, dan hasil commit menggunakan stream yang andal. Setiap datagram membawa versi objek, urutan, dan stempel waktu; penerima menerima versi yang lebih baru dan membuang yang usang, sementara pengirim membatasi ukuran, laju, dan antrean serta menggabungkan pembaruan. Saat terhubung atau menyambung ulang, snapshot yang andal menetapkan otoritas sebelum datagram dilanjutkan. HTTPS, deteksi kapabilitas, fallback WebSocket atau polling, serta metrik untuk kehilangan, antrean, penyambungan ulang, dan waktu perbaikan melengkapi desain ini.
Kesalahan umum
- Memperlakukan datagram sebagai antrean berurutan yang andal.
- Mengirim izin, pembayaran, atau fakta yang tidak dapat direkonstruksi sebagai datagram.
- Menghilangkan versi dan kesegaran, sehingga membiarkan status lama menimpa status baru.
- Membiarkan antrean pengiriman bertambah tanpa batas saat terjadi kongesti.
- Melanjutkan status lama setelah penyambungan ulang tanpa mengambil snapshot otoritatif.
- Mengabaikan HTTPS, deteksi browser, dan fallback.
Pertanyaan lanjutan dan tanggapan
Apa yang Anda lakukan ketika tingkat kehilangan meningkat?
Perpendek jendela status, turunkan laju pengiriman, dan gabungkan pembaruan untuk setiap objek; simpan fakta penting pada stream yang andal. Pertimbangkan kembali penggunaan datagram jika status tidak dapat dibangun kembali dari snapshot.
Bagaimana Anda mencegah penimpaan di luar urutan?
Bandingkan versi objek atau urutan monotonik dan hanya terima nilai yang lebih besar. Tingkatkan epoch sesi saat menyambung ulang dan tolak pesan dari sesi yang lebih lama.
Mengapa tetap mempertahankan stream yang andal?
Datagram tidak menjamin kedatangan atau urutan dan cocok untuk status di mana "nilai baru menggantikan nilai lama". Log, snapshot, izin, dan konfirmasi akhir memerlukan transport yang andal dan persistensi.