Konteks dan cakupan
Rancang sistem shadow-traffic untuk layanan yang menerima 20.000 permintaan per detik. Permintaan utama harus mempertahankan latensi p99 yang ada, sementara versi bayangan (shadow) boleh mengalami kelambatan (lag). Sistem harus melakukan sampling per endpoint, menyimpan cukup bukti untuk memutar ulang (replay) ketidakcocokan, membandingkan field respons yang bermakna, dan tidak pernah membiarkan permintaan yang dicerminkan mengirim pembayaran, email, atau efek samping eksternal lainnya.
Perbedaan utamanya adalah pencerminan permintaan (request mirroring), bukan penangkapan paket (packet capture). Load balancer dapat meneruskan salinan fire-and-forget ke backend mirror, sementara respons utama tetap menjadi otoritatif. Pencerminan paket jaringan memiliki target dan enkapsulasi yang berbeda, sehingga bukan merupakan pengganti jalur pemutaran ulang yang sadar aplikasi (application-aware).
Apa yang diuji oleh pewawancara
Pewawancara mencari kerangka perbandingan yang aman, bukan layanan produksi kedua dengan lalu lintas yang disalin mentah-mentah. Jawaban yang kuat menjaga jalur latensi utama, menghapus kredensial, mengisolasi operasi penulisan, membuat sampling dapat direproduksi, dan menjelaskan mengapa perbandingan byte-demi-byte sering kali salah.
Mereka akan menggali apa yang terjadi ketika antrean penangkapan penuh, ketika shadow lebih lambat, ketika respons berisi stempel waktu (timestamp), dan ketika permintaan utama telah melakukan penulisan. Perlakukan masing-masing hal tersebut sebagai kebijakan eksplisit.
Klarifikasi yang mengubah desain
- Apakah permintaan bersifat hanya-baca (read-only)? Permintaan hanya-baca dapat diputar ulang secara langsung; permintaan yang melakukan mutasi memerlukan sandbox, stub, atau identitas sintetis.
- Apakah perbandingannya persis atau semantik? Perbandingan persis cocok untuk JSON deterministik; mask atau pemeriksaan invarian cocok untuk timestamp dan ID yang dibuat otomatis.
- Bisakah body yang ditangkap berisi data pribadi? Jika ya, redaksikan sebelum penyimpanan, enkripsi referensi, dan tentukan retensi serta audit akses.
- Apakah tujuannya adalah kebenaran migrasi, latensi, atau kapasitas? Metrik dan kebijakan sampling berubah sesuai dengan tujuan.
Kerangka jawaban 30 detik
“Saya akan menangkap permintaan yang terotentikasi setelah otorisasi tetapi sebelum penulisan eksternal, membersihkan (sanitize) rahasia dan data pribadi, serta memasukkan sampel deterministik ke dalam antrean secara asinkron. Respons utama tetap otoritatif. Worker shadow yang terisolasi memutar ulang permintaan ke sandbox dengan batas laju tertentu dan kredensial terpisah. Layanan diff membandingkan status, field terpilih, invarian, dan latensi sambil mengabaikan non-determinisme yang telah dideklarasikan. Penangkapan yang tahan lama (durable) mendukung investigasi, tetapi luapan antrean akan membuang mirror alih-alih memperlambat pengguna. Promosi memerlukan batas divergensi dan error budget yang terdefinisi, ditambah pemeriksaan bahwa penulisan, privasi, dan kapasitas shadow aman.”
Desain langkah demi langkah
1. Menangkap tanpa menyentuh jalur kritis
Tempatkan kait penangkapan (capture hook) setelah autentikasi dan otorisasi sehingga sistem mengetahui kebijakan endpoint dan tenant, tetapi sebelum panggilan eksternal yang tidak dapat dibatalkan. Salin hanya field yang dibutuhkan oleh shadow. Hapus otorisasi, cookie, token pengguna, dan materi pembayaran; ganti dengan kredensial shadow berumur pendek atau identitas uji yang tetap.
Publikasikan MirroredRequest yang berisi ID permintaan, ID trace, endpoint, header yang telah dibersihkan, referensi body, waktu penangkapan, versi target, dan versi konfigurasi sampling. Operasi memasukkan ke antrean (enqueue) harus memiliki batas waktu (timeout) yang terbatas. Jika buffer lokal atau antrean durable penuh, catat metrik drop dan kembalikan respons utama.
2. Membuat sampling dapat direproduksi
Lakukan hash pada ID permintaan atau trace yang stabil dan bandingkan dengan tingkat sampel yang dikonfigurasi. Ini menjaga percobaan ulang dan investigasi tetap deterministik. Terapkan token bucket kedua per endpoint dan tenant untuk membatasi RPS mirror; nilai terendah antara persentase dan anggaran token yang akan digunakan.
Simpan versi konfigurasi sampel bersama setiap penangkapan. Laporan di kemudian hari dapat membedakan divergensi nyata dari aturan sampling yang berubah.
3. Memutar ulang di lingkungan yang terisolasi
Worker membaca antrean durable dan memanggil target shadow dengan batas waktu yang singkat. Shadow harus menggunakan database terpisah atau fixture tanpa transaksi, melakukan stub pada penyedia pembayaran dan email, serta menonaktifkan callback keluar. Untuk jalur baca, replika hanya-baca atau snapshot yang telah dibersihkan biasanya lebih aman daripada penyimpanan produksi.
Pengiriman setidaknya sekali (at-least-once) dapat diterima untuk antrean penangkapan karena replay ditandai dengan ID permintaan. Worker mencatat SHADOW_ERROR, DROPPED, atau COMPLETED; batas waktu shadow tidak boleh mencoba lagi tanpa batas atau memblokir permintaan utama.
4. Membandingkan respons berdasarkan makna
Bandingkan kode status terlebih dahulu. Untuk respons JSON yang berhasil, hapus field yang secara eksplisit dinyatakan non-deterministik, kemudian bandingkan jalur yang dipilih atau hash body yang dikanonisasi. Tambahkan invarian domain seperti "total tidak negatif" atau "pengguna yang dikembalikan termasuk dalam tenant yang diminta." Bandingkan latensi secara terpisah; respons bisa saja benar tetapi terlalu lambat untuk dipromosikan.
Simpan kedua hash, jalur diff, latensi utama dan shadow, versi deployment, dan referensi sampel permintaan. Jangan simpan body sensitif mentah dalam laporan.
5. Menentukan gerbang promosi (promotion gates)
Buat ambang batas sebelum replay dimulai: tingkat divergensi, tingkat error shadow, regresi latensi, usia antrean, dan kegagalan redaksi. Segmentasikan laporan berdasarkan endpoint, tingkatan tenant, wilayah, dan kelas respons; tingkat hijau agregat dapat menyembunyikan endpoint pembayaran yang rusak.
Gunakan sliding window dengan jumlah sampel minimum. Ambang divergensi 1% adalah contoh kebijakan, bukan aturan universal. Promosi juga memerlukan nol efek samping yang tidak aman, kapasitas shadow yang dapat diterima, dan contoh yang ditinjau untuk setiap diff tingkat keparahan tinggi.
6. Mengoperasikan dan memulihkan
Jeda replay tanpa menonaktifkan penangkapan saat shadow kelebihan beban. Buat masa berlaku penangkapan berakhir sesuai kebijakan privasi, dan audit akses ke referensi permintaan yang disimpan. Jika versi shadow di-rollback, jaga agar laporannya tetap ditautkan ke deployment sehingga analisis selanjutnya tidak mencampurkan versi.
Uji kehilangan antrean, penangkapan duplikat, konfigurasi usang, kebocoran kredensial, upaya efek samping, field non-deterministik, timeout shadow, dan kegagalan wilayah. Kriteria keberhasilannya adalah layanan utama tetap berada dalam SLO-nya sementara shadow menghasilkan bukti yang dapat ditindaklanjuti dan dapat direproduksi.
Contoh jawaban berkualitas tinggi
“Saya akan membangun hook mirror yang sadar aplikasi setelah autentikasi dan sebelum penulisan eksternal. Hook ini menghapus kredensial asli dan field sensitif, menyimpan referensi body, dan mengambil sampel secara deterministik berdasarkan trace ID. Jalur utama tidak pernah menunggu mirror; antrean berbatas dapat membuang pekerjaan mirror saat berada di bawah tekanan beban.
“Worker yang terisolasi memutar ulang ke versi shadow dengan identitas terpisah, database terpisah, dan penyedia layanan yang di-stub. Setiap replay memiliki ID permintaan dan batas waktu. Layanan perbandingan memeriksa status, jalur JSON yang dipilih, invarian domain, dan latensi, hanya mengabaikan field yang dinyatakan non-deterministik. Laporan mempertahankan hash, jalur diff, versi, dan contoh yang telah dibersihkan.
“Sebelum mempromosikan, saya akan menetapkan gerbang tingkat endpoint untuk divergensi, error, latensi, usia antrean, dan kegagalan privasi, mewajibkan sampel minimum, dan memeriksa diff yang parah. Endpoint yang melakukan mutasi memerlukan sandbox atau dikecualikan. Saya akan memvalidasi luapan antrean, duplikat, penghapusan kredensial, efek samping, dan kegagalan regional sambil membuktikan bahwa SLO utama tidak berubah.”
Kesalahan umum
- Kesalahan → Kegagalan → Perbaikan: Memutar ulang kredensial produksi → panggilan shadow dapat membocorkan data atau memutasi sistem nyata → hapus rahasia dan gunakan identitas serta penyedia yang terisolasi.
- Kesalahan → Kegagalan → Perbaikan: Menunggu shadow sebelum merespons → pengujian migrasi meningkatkan latensi pengguna → masukkan ke antrean secara asinkron dan buang pekerjaan mirror di bawah tekanan beban.
- Kesalahan → Kegagalan → Perbaikan: Hanya membandingkan body mentah → timestamp dan ID yang dibuat otomatis menghasilkan positif palsu (false positives) → kanonisasi dan bandingkan field yang dideklarasikan beserta invarian.
- Kesalahan → Kegagalan → Perbaikan: Mencerminkan setiap permintaan selamanya → penyimpanan, risiko privasi, dan kapasitas shadow membengkak tanpa batas → gunakan sampling deterministik, kuota, retensi, dan audit akses.
- Kesalahan → Kegagalan → Perbaikan: Menggunakan satu tingkat divergensi global → endpoint penting yang bervolume kecil dapat gagal di dalam agregat yang tampak hijau → pasang gerbang per endpoint, tenant, wilayah, dan tingkat keparahan.
Pertanyaan lanjutan dan tanggapan
Bagaimana jika endpoint menulis ke database?
Arahkan shadow ke database sekali pakai atau stub transaksi, dan ganti panggilan eksternal dengan implementasi palsu (fake) yang mencatat niat tindakan. Jika penulisan tidak dapat diisolasi, kecualikan endpoint tersebut dan nyatakan celah cakupan daripada berpura-pura hasilnya aman.
Bagaimana jika antrean penangkapan penuh?
Gunakan pendekatan fail-open untuk permintaan utama: buang salinan yang dicerminkan, naikkan metrik berlabel, dan beri peringatan ketika anggaran drop terlampaui. Memberikan backpressure pada permintaan utama akan membatalkan properti keamanan utama.
Bagaimana Anda menangani informasi pengenal pribadi (PII)?
Klasifikasikan field pada saat penangkapan, redaksikan atau lakukan tokenisasi sebelum penyimpanan tahan lama, enkripsi referensi body, batasi retensi, dan audit akses. Hash dari muatan sensitif masih dapat mengidentifikasi seseorang, jadi itu tidak otomatis aman.
Bisakah pencerminan paket menggantikan pencerminan aplikasi?
Tidak. Pencerminan paket menyalin lalu lintas jaringan ke target analisis, sedangkan pencerminan aplikasi memahami semantik endpoint, kredensial, kebijakan tenant, dan perbandingan respons. Gunakan pencerminan paket untuk inspeksi jaringan dan jalur yang sadar aplikasi untuk validasi perilaku.