Konteks dan instruksi
Pertanyaan ini menguji apakah seorang data engineer dapat mengubah satu permintaan penghapusan menjadi siklus hidup lintas sistem, dapat dicoba kembali (retryable), dan dapat diaudit. Penghapusan lebih dari sekadar DELETE di database utama; ini mencakup tabel turunan, cache, indeks, log peristiwa, cadangan, dan pemroses. Cakup penemuan (discovery), pemetaan identitas, penahanan hukum (legal holds), idempotensi, pemulihan, dan bukti penyelesaian.
Apa yang diuji oleh pewawancara
Jawaban yang kuat mendefinisikan cakupan dan pengecualian, lalu membangun katalog data beserta pemiliknya. Alur kerja mengirimkan perintah hapus atau anonimisasi di sepanjang dependensi dan menunggu tanda terima (receipts). Status membedakan antara requested, running, verified, dan blocked, dengan jejak audit yang tidak dapat diubah (immutable). Jika cadangan fisik tidak dapat segera diedit, jelaskan penghapusan enkripsi (crypto-shredding), masa kedaluwarsa, isolasi pemulihan, dan penerapan ulang.
Pertanyaan untuk klarifikasi
- Apa yang mengidentifikasi seseorang, dan bagaimana email, perangkat, pesanan, dan pengidentifikasi anonim dihubungkan?
- Catatan mana yang harus dihilangkan, dan faktur, bukti penipuan, atau penahanan hukum mana yang harus tetap ada untuk sementara?
- Apakah indeks pencarian, cache, agregat, log peristiwa, penyimpanan objek, cadangan, dan pemroses SaaS disertakan?
- Apakah tujuannya adalah penghapusan fisik, anonimisasi yang tidak dapat dibatalkan, atau penghentian penggunaan dalam batas waktu tertentu?
- Apa yang mendefinisikan penyelesaian, batas waktu (timeout), tinjauan manusia, dan tanda terima pengguna?
Kerangka jawaban 30 detik
“Saya akan mengatalogkan sistem, bidang (fields), pemilik, aturan retensi, dan kemampuan penghapusan. Setiap permintaan membuat kasus penghapusan yang tidak dapat diubah dan tugas-tugas idempoten. Orkestrator mengirimkan perintah hapus, anonimisasi, atau penghapusan kunci di sepanjang dependensi; setiap konsumen mengembalikan cakupan, versi, dan ringkasan verifikasi. Kegagalan akan dicoba kembali atau dieskalasi. Data yang ditahan secara hukum akan dibekukan aksesnya dengan pengecualian yang dicatat dan dihapus saat masa penahanan berakhir. Penyelesaian memerlukan cakupan katalog, tanda terima, pembacaan sampel, dan jejak audit; pengguna menerima status yang jujur tanpa mengetahui topologi internal.”
Jawaban mendalam langkah demi langkah
Langkah 1: Bangun peta data dan identitas
Katalogkan tabel, bucket, indeks, kelas bidang, pemilik, dependensi downstream, siklus pencadangan, dan pemroses. Petakan ID pengguna yang stabil ke pesanan, perangkat, email, dan token anonim. Tanpa penggabungan identitas yang andal, klaim penghapusan menyeluruh tidak dapat dipercaya.
Langkah 2: Tentukan kebijakan penghapusan
Klasifikasikan catatan sebagai penghapusan langsung, anonimisasi, retensi agregat, atau penahanan hukum. Catatan keuangan atau bukti penipuan mungkin memerlukan retensi, tetapi minimalkan bidang, batasi akses, dan catat dasar hukumnya. Berikan versi pada kebijakan agar permintaan lama tetap dapat dijelaskan.
Langkah 3: Buat kasus yang idempoten
Buat case_id, ID subjek, versi kebijakan, batas waktu, dan sumber. Setiap target menerima ID kasus dan mengembalikan hasil yang sama saat pengulangan. Gunakan status seperti requested, running, verified, blocked, failed, dan expired.
Langkah 4: Propagasi di sepanjang dependensi
Hapus catatan sumber atau pancarkan tombstone, lalu picu konsumen CDC untuk indeks, cache, dan gudang data turunan. Sistem batch memerlukan tabel penekanan (suppression table) agar pekerjaan berikutnya tidak membuat ulang subjek tersebut. Pihak ketiga mengonfirmasi melalui tanda terima API atau proses kontraktual.
Langkah 5: Tangani cadangan dan penghapusan kunci
Cadangan biasanya kedaluwarsa sesuai jadwal. Jika pengeditan individual tidak memungkinkan, isolasi akses pemulihan, simpan manifes penghapusan, dan terapkan kembali penghapusan selama pemulihan. Kunci enkripsi per subjek dapat membuat teks tersandi sensitif tidak dapat dipulihkan setelah pemusnahan kunci, tetapi ini bukan jalan pintas hukum yang berlaku secara universal.
Langkah 6: Verifikasi melampaui kode keberhasilan
Konsumen mengembalikan jumlah, versi, partisi, dan checksum. Orkestrator mengambil sampel pembacaan di penyimpanan utama, indeks, gudang data, dan penyimpanan objek, serta memeriksa pembatalan cache dan tanda batas CDC (CDC watermarks). Verifikasi yang gagal akan membuat pekerjaan kompensasi, alih-alih menutup kasus.
Langkah 7: Isolasi pengecualian retensi
Simpan catatan penahanan hukum secara terpisah dengan bidang minimal dan tanpa kueri produk. Laporan kasus berisi cakupan, dasar hukum, pemilik, dan tanggal peninjauan. Pelepasan penahanan secara otomatis membuat tugas penghapusan baru; pengecualian tidak boleh menjadi daftar hitam permanen.
Langkah 8: Audit, peringatan, dan tanggapan
Log audit berisi intisari subjek yang tidak dapat diubah, pelaku (actor), waktu, versi kebijakan, dan hasil, bukan muatan sensitif. Pantau usia kasus, tingkat kegagalan, cakupan katalog, tanda terima pihak ketiga, dan simulasi pemulihan. Pengguna melihat status completed, processing, atau legally held dengan batas waktu yang jelas.
Pseudocode alur kerja penghapusan
case = create_case(subject, policy_version)
for target in catalog.targets(subject, policy_version):
enqueue_idempotent(case.id, target, action_for(target))
verify_samples(case)
close(case, "verified" if all_verified(case) else "blocked")Pertukaran (trade-offs) dan batasan
| Skenario | Strategi | Biaya |
|---|---|---|
| Utama dan indeks | Tombstone ditambah penghapusan asinkron | Keterlambatan propagasi |
| Agregat analitik | Hapus detail pengidentifikasi dan hitung ulang | Biaya komputasi |
| Cadangan jangka panjang | Kedaluwarsa atau putar ulang penghapusan selama pemulihan | Bukan penghapusan baris langsung |
| Penahanan hukum | Minimalkan bidang dan bekukan akses | Tinjauan dan tata kelola |
Bukti harus mencakup di mana sistem mencari, target mana yang telah mengonfirmasi, dan pengecualian mana yang tersisa. Ini tidak boleh menjanjikan penghilangan fisik yang tidak dapat diverifikasi. Google Cloud menggambarkan penghapusan sebagai pipeline bertahap di mana data tetap terlindungi hingga tahapan selesai.
Rencana peluncuran dan bukti
Pilih satu kumpulan data pengguna dan hubungkan katalog, peta identitas, penyimpanan utama, indeks, dan gudang data. Suntikkan pesan duplikat, konsumen offline, pemulihan cadangan, dan perubahan kebijakan. Komisi Eropa mendokumentasikan pengecualian hukum untuk penghapusan; Google Cloud mendokumentasikan penghapusan bertahap; pertanyaan desain publik TechInterview menyoroti layanan mikro, penyimpanan objek, analitik, cadangan, dan jejak audit.
Kriteria keluar uji coba (pilot exit criteria)
Cakupan katalog dapat diukur; setiap target memiliki pemilik dan kemampuan; permintaan berulang bersifat idempoten; kegagalan dicoba kembali atau dieskalasi; verifikasi sampel menemukan residu; penahanan memiliki dasar dan masa kedaluwarsa; dan tanda terima pengguna cocok dengan status internal.
Cara membuktikan perolehan hasil nyata
Bandingkan kumpulan data yang tidak terdaftar, waktu penyelesaian, tingkat residu yang ditemukan oleh verifikasi, tingkat percobaan ulang, dan intervensi manusia sebelum dan sesudah. Lakukan simulasi terhadap konsumen offline, pemulihan cadangan, dan batas waktu pihak ketiga alih-alih hanya mengukur jalur sukses (happy path).
Kesalahan umum dan tindak lanjut
Hanya menghapus baris utama
Indeks, cache, gudang data, dan penyimpanan objek mungkin masih mengembalikan data. Cakupan katalog dan tanda terima downstream harus menjadi kriteria penyelesaian.
Satu peristiwa DELETE global untuk setiap sistem
Konsumen membutuhkan tindakan dan versi yang berbeda. Tanpa idempotensi, tanda terima, dan watermarks, peristiwa dapat hilang atau berulang. Gunakan alur kerja berbasis ID kasus.
Mengklaim bahwa cadangan langsung terhapus seketika
Banyak cadangan yang kedaluwarsa berdasarkan jadwal. Jelaskan isolasi akses, manifes penghapusan, pemutaran ulang pemulihan, dan waktu penimpaan akhir.
Bagaimana penahanan hukum menghindari pemblokiran semua penghapusan?
Minimalkan cakupan yang ditahan, bekukan akses, catat dasar hukum, pemilik, dan tanggal peninjauan, serta lanjutkan menghapus semua hal di luar penahanan tersebut.
Bagaimana cara mencegah data dibuat ulang?
Pancarkan tombstone sumber atau catatan penekanan; CDC dan pekerjaan batch memeriksa status penghapusan sebelum membuat turunan, dan pemutaran ulang menerapkan kembali kebijakan.
Bagaimana jika pengguna menuntut penyelesaian segera?
Bedakan target yang terverifikasi dari langkah cadangan atau pihak ketiga yang dibatasi waktu, kembalikan status pemrosesan dan batas waktu, dan jangan pernah mengada-ada tentang penghapusan fisik yang telah selesai.