Perintah dan konteks
Pertanyaan system design ini menguji apakah Anda dapat mengubah parameter TCP keep-alive tingkat rendah menjadi kapabilitas platform yang terkelola dengan baik. Tantangannya bukan sekadar mengirim probe lebih sering. Pisahkan liveness transport dari health aplikasi, lalu rancang isolasi tenant, versi kebijakan, siklus hidup koneksi, biaya jaringan, dan pemulihan.
Hal yang diuji oleh pewawancara
- Menjelaskan hubungan antara idle time, probe interval, kegagalan maksimum, dan false positive.
- Merancang default yang aman, kuota tenant, izin, dan validasi konfigurasi.
- Menerapkan kebijakan pada titik siklus hidup koneksi yang tepat tanpa menyebabkan churn selama hot update.
- Menyediakan auditabilitas, metrik, rollout bertahap, rollback, dan perlindungan kelebihan beban.
Pertanyaan klarifikasi
Konfirmasikan jenis koneksi, kendali klien dan server, shared node, NAT, jaringan seluler, proxy, dan target bisnis untuk mendeteksi koneksi mati. Periksa dukungan kernel, apakah keep-alive dinonaktifkan secara default, heartbeat aplikasi yang ada, jumlah koneksi dan anggaran per-tenant, serta apakah perubahan harus bersifat instan. Probe TCP hanya memastikan respons transport; ini tidak menggantikan health check tingkat aplikasi.
Kerangka jawaban 30 detik
Saya akan membangun layanan kebijakan tenant berversi dengan default global yang konservatif dan batasan tenant, memvalidasi kombinasi idle time, probe interval, dan failure count. Koneksi baru membaca dan mengikat versi kebijakan; penyegaran runtime dikontrol untuk menghindari reset socket dalam jumlah masif. Publikasi memerlukan otorisasi, audit, rollout bertahap, dan rollback otomatis, sementara data plane mencatat probe, pemutusan koneksi, dan false positive. Saya akan membatasi total anggaran probe, tetap menggunakan versi valid terakhir saat control plane tidak tersedia, dan mencadangkan heartbeat aplikasi untuk semantik bisnis.
Desain langkah demi langkah
1. Tentukan model kebijakan dan default yang aman
Sertakan idle-time, probe-interval, max-probes, cakupan koneksi, versi, masa kedaluwarsa, dan sumber. RFC 9293 mewajibkan keep-alive dapat diaktifkan/dinonaktifkan per koneksi dan dinonaktifkan secara default; RFC 9643 merekomendasikan interval yang konservatif karena probe mengonsumsi sumber daya. Gunakan default idle time dan interval yang cukup panjang, dan izinkan tenant memperpendeknya hanya dalam batas anggaran sumber daya.
2. Pisahkan control plane dan data plane
Control plane menyimpan kebijakan tenant, versi, dan catatan audit, serta mengekspos validasi, persetujuan, publikasi, rollout, dan rollback. Setelah pembuatan koneksi atau handshake, data plane membaca snapshot bertanda tangan, menerapkannya ke socket yang dapat dikontrol, dan melaporkan versi efektif. Pemadaman singkat pada control plane tidak boleh menggagalkan setiap koneksi; simpan snapshot valid terakhir di cache dan tentukan perilaku kedaluwarsa.
3. Validasi kombinasi dan kuota
Tolak probe interval di bawah batas aman minimum, batasi jumlah koneksi dan laju probe per-tenant, serta pastikan failure count sesuai dengan target waktu deteksi. Hitung anggaran berdasarkan node, zona, dan jalur egress agar satu tenant tidak dapat memusatkan probe pada satu kelompok instance. Terapkan batas kedua berdasarkan beban node waktu nyata bahkan setelah validasi konfigurasi.
4. Distribusikan versi dan tangani pembaruan
Ikat versi kebijakan ke setiap koneksi, dengan koneksi baru menggunakan versi publikasi terbaru. Koneksi yang ada dapat disegarkan secara bertahap (batch), saat reconnect alami, atau pada siklus idle berikutnya; jangan memperbarui jutaan socket sekaligus. Lakukan rollout setiap rilis ke sebagian kecil tenant dan node, bandingkan waktu deteksi, false positive, CPU, bandwidth, dan churn koneksi, lalu perluas.
5. Bangun observabilitas dan klasifikasi kegagalan
Catat versi kebijakan, probe yang dikirim, rasio respons, kegagalan berurutan, alasan pemutusan akhir, keberhasilan reconnect, dan penggunaan sumber daya per-tenant. Bedakan penutupan oleh peer, kehilangan paket, beban berlebih pada node, kebijakan kedaluwarsa, dan kegagalan heartbeat aplikasi. Tidak adanya respons keep-alive saja tidak membuktikan kematian koneksi; peringatan harus menggabungkan probe berulang dengan hasil aplikasi.
6. Rancang rollback dan perlindungan kelebihan beban
Simpan versi stabil sebelumnya dan kebijakan global darurat. Jika suatu rollout meningkatkan pemutusan koneksi, lalu lintas probe, atau CPU di atas ambang batas, hentikan publikasi dan pulihkan versi lama; jika pembaruan gagal, lanjutkan dengan snapshot yang tervalidasi. Tambahkan rate limit, circuit breaker tenant, dan backpressure antrean sehingga lonjakan kebijakan tidak membebani connection manager.
Contoh jawaban berkualitas tinggi
Saya akan mengimplementasikan kebijakan keep-alive sebagai layanan control plane berversi yang memuat idle time, probe interval, probe maksimum, cakupan koneksi, dan data audit. Platform akan menggunakan default global konservatif yang dinonaktifkan dan membatasi pengaturan tenant berdasarkan anggaran koneksi dan probe. Koneksi baru akan membaca snapshot bertanda tangan dan mengikat versinya; koneksi yang ada hanya akan diperbarui melalui batch atau reconnect alami. Rollout akan memerlukan persetujuan, metrik bertahap, dan rollback otomatis, melacak laju probe, respons, penyebab pemutusan, false positive, reconnect, dan beban node. Keep-alive akan mencakup liveness transport sementara heartbeat aplikasi mengonfirmasi health bisnis. Jika lalu lintas probe atau pemutusan meningkat secara tak terduga, saya akan menghentikan propagasi dan memulihkan versi yang stabil.
Kesalahan umum
- Menganggap keep-alive sebagai health check aplikasi hanya karena ACK diterima.
- Mengizinkan tenant memperpendek interval tanpa anggaran probe tingkat node, egress, dan global.
- Menyisir setiap koneksi segera setelah perubahan kebijakan dan menyebabkan churn yang tersinkronisasi.
- Mengabaikan versi, tanda tangan, catatan audit, dan snapshot kondisi baik terakhir (last-known-good).
- Hanya melihat jumlah pemutusan koneksi tanpa mengklasifikasikan packet loss, penutupan peer, overload, dan false positive.
- Memublikasikan secara global tanpa peluncuran bertahap atau jalur rollback.
Pertanyaan lanjutan dan jawaban
Mengapa tidak menyetel probe interval menjadi beberapa detik saja?
Probe yang sering mengonsumsi sumber daya jaringan, CPU, dan baterai serta dapat memperparah kemacetan (congestion). Hitung parameter berdasarkan target deteksi, jumlah koneksi, dan anggaran sumber daya, serta prioritaskan heartbeat aplikasi jika diperlukan semantik bisnis.
Tenant menginginkan perubahan instan. Apa yang Anda lakukan?
Biarkan koneksi baru menggunakan versi yang disetujui secara langsung dan perbarui koneksi yang ada melalui batch terbatas dengan rate limit per-node. Perubahan keamanan darurat dapat menerima prioritas lebih tinggi, tetapi tetap memerlukan pemberi persetujuan, cakupan, perkiraan churn, dan kondisi rollback.
Apa yang terjadi saat control plane down?
Data plane terus menggunakan snapshot bertanda tangan terakhir yang belum kedaluwarsa untuk jangka waktu terbatas. Setelah kedaluwarsa, data plane beralih ke default global yang aman, bukan konfigurasi kosong. Setelah pulih, rekonsiliasi versi tanpa menyegarkan semua koneksi sekaligus.
Bagaimana cara mendeteksi false positive keep-alive?
Bandingkan kegagalan probe berurutan dengan heartbeat aplikasi, hasil reconnect, dan metrik jalur. Satu ACK yang terlewat tidaklah cukup; wajibkan failure count yang telah dikonfigurasi dan sinyal pendukung dari bisnis atau aplikasi.
Bagaimana cara mencegah satu tenant besar menghabiskan anggaran probe?
Gunakan kuota hierarkis untuk tenant, node, zona, dan global berdasarkan jumlah koneksi dan laju probe. Di atas kuota, perpanjang interval, tolak pengaturan yang agresif, atau wajibkan peningkatan kuota sambil tetap menjaga tingkat layanan minimum bagi tenant lainnya.