Petunjuk dan konteks
Sebuah layanan kolaborasi real-time memiliki puluhan ribu koneksi jangka panjang yang menggunakan library WebSocket pihak ketiga. Node.js 22.4 menandai WebSocket sebagai stabil, dan tim ingin mengurangi dependensi. Bahas kompatibilitas, siklus hidup, backpressure, autentikasi, observabilitas, dan rollback.
Hal yang diuji oleh pewawancara
Mereka memeriksa apakah Anda membedakan stabilitas API dari kematangan produksi, dan apakah Anda dapat merancang batasan, heartbeat, backpressure broadcast, graceful shutdown, serta migrasi yang terukur.
Pertanyaan untuk klarifikasi
Tanyakan tentang protokol klien, dukungan proxy, ukuran pesan, puncak koneksi, pembaruan kredensial, fan-out lintas node, koneksi ulang, dan kegagalan regional. Identifikasi perilaku ekstensi serta jaminan yang harus dipertahankan dari library saat ini.
Jawaban 30 detik
“Saya akan membangun matriks perbedaan API dan protokol serta memverifikasi Node 22.4+, proxy, dan klien. Setiap koneksi mendapatkan batas autentikasi, heartbeat, idle, dan ukuran pesan; broadcast menggunakan antrean berbatas untuk backpressure, dan shutdown melakukan drain setelah menolak koneksi baru. Saya akan melakukan shadow dan canary, membandingkan keberhasilan handshake, pemutusan koneksi, latensi P95, memori, dan CPU, serta mempertahankan sakelar ke implementasi pihak ketiga untuk rollback cepat.”
Pembahasan mendalam langkah demi langkah
Verifikasi runtime dan protokol
Dokumentasi Node menyatakan WebSocket tidak lagi eksperimental mulai v22.4.0. Kunci versi Node dan verifikasi handshake, ekstensi, batas waktu (timeout) proxy, dan pengaturan TLS.
Rancang siklus hidup koneksi
Lakukan autentikasi dan otorisasi saat koneksi dibuat, lalu tetapkan kebijakan idle, heartbeat, dan kode penutupan (close code). Selama restart, hentikan penerimaan koneksi, lakukan drain, dan kirimkan petunjuk koneksi ulang.
Tangani backpressure dan ukuran
Beri setiap koneksi antrean pengiriman yang berbatas. Pada batas maksimal, buang pesan yang dapat dibangun kembali, turunkan kualitas layanan, atau putuskan konsumen yang lambat. Batasi frame dan pesan agregat agar satu klien tidak menghabiskan memori atau event loop.
Terapkan autentikasi dan otorisasi
Validasi kredensial berumur pendek selama handshake dan periksa kembali izin tenant serta resource untuk pesan sensitif. Pembaruan yang gagal akan menutup koneksi dan memerlukan autentikasi ulang.
Skalakan di seluruh node
Pertahankan status koneksi secara lokal dan rute peristiwa melalui message bus. Berikan versi atau kursor pada langganan agar koneksi ulang dapat memutar ulang jeda alih-alih menyiarkan ulang semuanya.
Canary, pantau, dan lakukan rollback
Aktifkan secara internal dan untuk 1% lalu lintas. Bandingkan kegagalan handshake, kelangsungan koneksi, koneksi ulang, pesan terbuang di antrean, latensi P95, memori, dan CPU. Biarkan implementasi lama tetap dapat dialihkan dan lakukan revert jika terjadi regresi protokol atau sumber daya.
Jawaban model
Saya tidak akan mengganti library hanya karena API-nya sudah stabil. Saya akan mengunci Node 22.4+, kompatibilitas proxy, dan klien, lalu menambahkan autentikasi handshake, heartbeat, batas waktu idle, pembatasan ukuran, dan antrean pengiriman berbatas. Node berbagi peristiwa dan kursor, bukan status koneksi, dan koneksi ulang memutar ulang jeda. Sebuah canary membandingkan keberhasilan handshake, pemutusan, koneksi ulang, antrean yang dibuang, P95, memori, dan CPU sementara jalur lama tetap tersedia untuk rollback.
Kesalahan umum
Menyamakan API stabil dengan pengganti yang lengkap
Library mungkin menyediakan ekstensi, kompresi, atau perilaku koneksi ulang. Dokumentasikan dan uji setiap perbedaan.
Menghilangkan kebijakan konsumen lambat
Antrean tanpa batas akan menghabiskan memori. Batasi antrean, buang pesan yang dapat dibangun kembali, atau putuskan koneksi.
Otorisasi hanya pada saat handshake
Izin dapat dicabut selama koneksi yang panjang. Tindakan sensitif memerlukan pemeriksaan tingkat pesan atau versi kebijakan.
Mematikan koneksi secara mendadak saat restart
Hal tersebut memicu badai koneksi ulang (reconnect storm). Lakukan drain, terapkan jitter pada koneksi ulang, dan gunakan kode penutupan eksplisit.
Pertanyaan lanjutan
Bagaimana Anda mengendalikan badai koneksi ulang?
Kembalikan alasan penutupan yang jelas, gunakan exponential backoff dengan jitter pada klien, dan terapkan pembatasan laju (rate-limit) berdasarkan IP, tenant, dan akun di server.
Kapan Anda akan mempertahankan library pihak ketiga?
Pertahankan ketika ekstensi yang diperlukan, kompresi, kompatibilitas proxy, atau telemetri matang tidak terpenuhi dan nilai penggantian rendah; catat batasan evaluasi tersebut.
Bagaimana Anda menguji backpressure?
Injeksi klien lambat dan broadcast beruntun, lalu amati batas antrean, perilaku pembuangan pesan, penundaan event loop, dan kurva memori.
Bagaimana Anda menjaga urutan di seluruh node?
Tetapkan kursor monotonik per aliran langganan dan bawa versi melalui bus; klien mendeteksi jeda dan meminta pemutaran ulang.