Petunjuk dan cakupan
Pertanyaan desain data-engineering ini menguji seluruh siklus hidup record yang ditolak: deteksi, karantina, perbaikan, pemutaran ulang (replay), dan penutupan. Jawabannya harus melindungi throughput pada jalur yang sehat sambil mempertahankan bukti yang cukup untuk mereproduksi suatu keputusan.
Hal yang diuji oleh pewawancara
- Membedakan kegagalan skema, aturan bisnis, duplikat, keterlambatan (late data), dan poison pill.
- Merancang record karantina dengan bukti payload, posisi sumber, dan alasan.
- Menggunakan idempotensi, aturan berversi, dan status yang dapat diaudit untuk replay.
- Mencakup backpressure, peringatan (alerting), privasi, retensi, dan kepemilikan (ownership).
Pertanyaan klarifikasi yang perlu diajukan
Klarifikasi apakah input berupa batch, streaming, atau keduanya; apakah record yang valid boleh di-commit secara independen; apakah event memiliki event_id yang stabil, stempel waktu bisnis, dan offset sumber; apakah replay membaca event asli atau mengambil ulang dari sumber; serta persyaratan privasi dan retensi apa yang berlaku.
Jawaban 30 detik
Saya akan memisahkan lapisan raw yang tidak dapat diubah (immutable), router validasi, jalur data valid, dan jalur karantina. Setiap record yang gagal menyimpan buktinya, posisi sumber, versi aturan, alasan, dan status; record yang valid ditulis secara idempoten berdasarkan event_id. Setelah perbaikan, batch replay menjalankan batas transformasi dan penulisan yang sama, dengan versi aturan yang terkontrol dan metrik rekonsiliasi yang membuktikan bahwa record tidak hilang secara senyap maupun terduplikasi.
Pembahasan mendalam langkah demi langkah
1. Pertahankan fakta sebelum perutean
Tulis event yang masuk ke penyimpanan yang tidak dapat diubah atau log yang dapat diputar ulang terlebih dahulu, termasuk sumber, partisi/offset, waktu penerimaan, event_id, dan hash payload. Kegagalan parsing atau skema harus dirutekan dengan kode kesalahan ke karantina alih-alih dibuang. Record yang lolos melanjutkan melalui jalur normal, sehingga satu record yang buruk tidak menghentikan batch atau partisi yang tidak terkait.
2. Buat karantina dapat ditindaklanjuti (actionable)
Simpan payload atau referensi yang terkontrol, field yang gagal, nama dan versi aturan, waktu kegagalan pertama, posisi sumber, jumlah percobaan ulang, batch perbaikan, dan status seperti open, ready_for_replay, replayed, atau rejected. Enkripsi atau minimalkan field sensitif dan terapkan kebijakan retensi. Tabel karantina adalah antrean operasional, bukan arsip tanpa batas.
3. Berikan batas kebenaran yang sama untuk replay
Buat versi aturan perbaikan dan jangan pernah menimpa event asli. Tugas replay memilih status dan versi aturan yang disetujui, memvalidasi sampel kecil atau target bayangan (shadow target), lalu memanggil jalur transformasi dan penulisan yang sama dengan yang digunakan oleh traffic langsung. Gunakan event_id ditambah versi bisnis sebagai kunci idempotensi; tentukan apakah konflik berupa upsert, no-op, atau versi baru. Memutar ulang dua kali harus menghasilkan hasil akhir yang sama.
4. Tangani duplikat, keterlambatan, dan poison pill
Deteksi duplikat dengan event_id, posisi sumber, atau jendela deduplikasi yang terdokumentasi; offset saja bukanlah identitas bisnis. Rutekan event yang terlambat berdasarkan waktu bisnis dan nyatakan bagaimana watermark atau backfill memengaruhi hasil downstream. Batasi percobaan ulang untuk poison pill dan serahkan ke pemilik atau status penolakan terminal, mencegah satu record menghabiskan seluruh kapasitas worker.
5. Buktikan kesehatan sistem dengan observabilitas
Lacak tingkat kelulusan data valid, jumlah karantina berdasarkan sumber dan aturan, usia data belum terselesaikan yang tertua, tingkat keberhasilan replay, konflik penulisan duplikat, latensi menyeluruh (end-to-end), dan kesegaran data (freshness). Berikan peringatan pada ambang batas tertentu atau isolasi satu sumber sebelum menghentikan seluruh pipeline. Rekonsiliasi jumlah raw, valid, karantina, di-replay, dan ditolak untuk setiap batch atau rentang offset; perbedaan yang tidak dapat dijelaskan dianggap sebagai insiden.
Contoh jawaban yang kuat
Pertama-tama, saya akan mengklarifikasi identitas event dan persyaratan konsistensi. Kemudian saya akan mempertahankan event mentah secara immutable, memvalidasi skema, aturan bisnis, duplikat, dan urutan, serta merutekan kegagalan ke penyimpanan karantina alih-alih membuangnya. Record karantina menyimpan referensi payload, offset sumber, versi aturan, alasan terperinci, dan status siklus hidup. Record yang valid dan record yang diputar ulang berbagi jalur penulisan idempoten yang sama yang dikunci oleh event_id dan versi bisnis. Perbaikan menghasilkan batch replay yang disetujui tanpa mengubah event asli; saya akan menguji sampel kecil, membatasi percobaan ulang poison pill, dan memperjelas perilaku event yang terlambat. Terakhir, saya akan memantau usia karantina, keberhasilan replay, konflik penulisan, kesegaran, dan rekonsiliasi jumlah, sambil melindungi field sensitif dan menegakkan retensi.
Kesalahan umum
- Membuang baris yang gagal atau hanya mencatat string kesalahan.
- Menghilangkan posisi sumber, identitas event, atau versi aturan.
- Mengimplementasikan replay dengan transformasi terpisah yang dapat menyimpang dari traffic langsung.
- Mencoba ulang poison pill tanpa batas atau pemilik.
- Memperlakukan karantina sebagai tempat pembuangan sampah tanpa status, retensi, atau kondisi penutupan.
- Hanya memantau tingkat keberhasilan agregat alih-alih dimensi sumber, aturan, dan usia.
Pertanyaan lanjutan dan tanggapan
Bagaimana cara Anda melindungi data pribadi di karantina?
Simpan hanya field minimum yang diperlukan untuk diagnosis, enkripsi payload sensitif, batasi akses, dan ambil data asli melalui referensi yang terkontrol. Audit pembacaan data dan terapkan penghapusan pada batas waktu retensi.
Bagaimana jika data baru tiba selama replay?
Gunakan batch replay terpisah dan versi event yang eksplisit. Gabungkan menggunakan kunci idempotensi; jika urutan penting, tentukan batas partisi atau entitas dan catat keputusan konflik.
Kapan Anda akan menghentikan seluruh pipeline?
Hanya untuk skema yang merusak (breaking schema), target yang tidak tersedia, atau risiko korupsi yang dapat mencemari data valid. Sumber atau aturan tunggal yang buruk biasanya harus diisolasi sementara jalur lain tetap berjalan.
Bagaimana Anda membuktikan bahwa tidak ada data yang hilang?
Buat buku besar (ledger) untuk setiap batch input atau rentang offset dan rekonsiliasi jumlah raw, valid, karantina, di-replay, dan ditolak. Ambil sampel kumpulan event_id dan sertakan usia data yang belum terselesaikan dalam SLO kualitas.