Petunjuk dan cakupan
Pertanyaan ini menguji perancangan siklus hidup dan pembuktiannya, bukan sekadar DELETE tunggal. Lacak pengenal subjek melalui raw objects, file tabel, hasil turunan, cache, fitur, ekspor, log, snapshot, dan cadangan. Tentukan kapan sistem dapat secara jujur mengklaim penyelesaian.
Petunjuk ini tidak menentukan kewajiban hukum. Nyatakan bahwa pemilik privasi dan hukum menentukan kewajiban retensi, pengecualian, dan tenggat waktu; tim rekayasa mengubahnya menjadi cakupan yang dapat dieksekusi, status, dan bukti.
Hal yang dievaluasi pewawancara
- Inventaris data dan lineage yang mencakup salinan, nilai turunan, log, snapshot, cache, dan cadangan.
- Permintaan yang idempoten, dapat dicoba ulang (retryable), dan dapat dijeda yang tidak dapat dimasukkan kembali melalui ingestion atau replay.
- Batasan yang jelas antara invisibilitas logis, penghapusan fisik, kedaluwarsa snapshot, dan kedaluwarsa cadangan.
- Isolasi kueri dan pelatihan selama penghapusan, dengan perlindungan penyewa (tenant) dan data sensitif.
- Bukti yang membuktikan setiap cakupan telah diproses, bukan sekadar satu nilai boolean sukses.
Struktur jawaban yang disarankan
Tentukan kunci subjek, status permintaan, dan kontrak penyelesaian. Petakan domain dan lineage. Tetapkan erasure_id yang stabil, blokir ingestion dan replay untuk subjek tersebut, hapus atau bangun ulang setiap domain, lalu jalankan pemeriksaan independen dan pembersihan retensi. Simpan versi input, hitungan, kegagalan, dan kursor secara persisten agar pemulihan dapat dilanjutkan tanpa menimbulkan efek duplikat.
Pembahasan mendalam: dari permintaan hingga pembuktian
Tentukan cakupan dan identitas terlebih dahulu
Petakan akun, perangkat, pesanan, dan pengenal eksternal ke kunci subjek yang tidak dapat diubah (immutable). Buat daftar raw objects, baris Iceberg, agregat, fitur, indeks, ekspor, cache, log, dan cadangan. Data yang tidak dikenal atau tidak terlacak menjadi item risiko eksplisit.
Buat penghapusan mutually exclusive dengan ingestion
Layanan penghapusan mendaftarkan erasure_id dan status subjek. Pekerjaan ingestion, replay, dan derivasi memeriksa penanda penghapusan sebelum menulis. Tombstone atau penghalang partisi subjek memblokir event lama, sementara versi atau lease mencegah snapshot yang lebih lama melakukan commit setelah penghapusan.
Pisahkan penghapusan logis dari pembersihan fisik
Equality delete atau position delete pada Iceberg dapat menyembunyikan baris dari pembacaan saat file lama, snapshot, dan orphan files masih ada. Jadwalkan pemadatan (compaction), kedaluwarsa snapshot, dan pembersihan file yatim dalam jendela retensi. Hapus raw objects dari inventaris. Untuk cadangan, catat aturan pemulihan terkontrol dan tugas penghapusan saat kedaluwarsa.
Data turunan tidak dapat diperbaiki hanya dengan menghapus input
Hitung ulang agregat yang dapat dilacak berdasarkan subjek. Untuk agregat yang tidak dapat dilacak kembali, pertahankan status perantara tingkat subjek atau bangun ulang partisinya. Pemilik fitur, cache, dan ekspor harus membersihkan versi mereka; jeda publikasi selama penghapusan dan bangun ulang dari input yang telah disanitasi.
Tentukan penyelesaian dengan bukti
Untuk setiap domain, catat cakupan pemindaian, jumlah kecocokan, versi penghapusan, pekerjaan pembersihan fisik, kegagalan, dan waktu verifikasi. Jalur kueri, ekspor, dan replay independen tidak boleh mengembalikan subjek target. Bukti yang hilang berarti penyelesaian parsial, bukan keberhasilan.
Contoh jawaban
“Pertama-tama saya akan mengonfirmasi kunci subjek, pengecualian retensi, dan tenggat waktu dengan pemilik privasi. Layanan penghapusan membuat erasure_id yang idempoten, memblokir ingestion dan replay, serta menulis item kerja untuk setiap domain. Raw objects dihapus dari inventaris. Iceberg menerima equality delete terlebih dahulu, kemudian pemadatan dan kedaluwarsa snapshot; agregat dan fitur dibangun ulang berdasarkan subjek, sementara pemilik cache dan ekspor membersihkan versi mereka. Cadangan hanya mengizinkan pemulihan terkontrol dan memutar ulang tombstone sebelum dirilis. Setiap langkah mencatat versi, hitungan, dan kegagalan. Hanya jika tidak ada kecocokan di semua domain (nol) dan tidak ada kegagalan yang belum terselesaikan, barulah status permintaan dipindahkan ke selesai.”
Mode kegagalan umum dan perbaikannya
- Hanya menghapus tabel utama → Rincikan salinan mentah, turunan, cache, ekspor, log, dan cadangan.
- Menyebut delete files sebagai penghapusan fisik → Jelaskan tentang snapshot, file lama, pemadatan, dan pembersihan file yatim.
- Mengabaikan concurrent writes → Tambahkan penghalang (barriers), tombstone, pemeriksaan versi, dan gerbang replay.
- Menggunakan satu tanda keberhasilan → Simpan cakupan per-domain, hitungan, versi, dan pemeriksaan independen secara persisten.
- Menjanjikan penulisan ulang cadangan seketika → Nyatakan aturan retensi, kontrol akses, pembersihan saat kedaluwarsa, dan pengecualian yang disetujui.
Rubrik penilaian dan pemeriksaan mandiri
Jawaban yang kuat mencakup identitas yang stabil, lineage yang lengkap, state machine yang idempoten, penghalang penulisan dan replay, batasan logis/fisik, pembangunan ulang data turunan, penanganan cadangan, pemulihan kegagalan, bukti per-domain, verifikasi nol-kecocokan, isolasi tenant, dan minimalisasi audit.
Tanyakan pada diri Anda: Apakah saya mengetahui pemilik setiap salinan? Bisakah event lama kembali masuk? Data mana yang disembunyikan vs dihapus? Bagaimana proses replay mengonsumsi tombstone? Bagaimana pemulihan dilanjutkan saat terjadi kegagalan? Bukti apa yang mengubah status penyelesaian?
Pertanyaan lanjutan dan perluasan
Bagaimana jika tabel Iceberg terlalu besar untuk penulisan ulang file secara langsung?
Tulis penghapusan tingkat baris (row-level delete) agar pembacaan langsung mengecualikan subjek tersebut, kemudian jadwalkan pemadatan berdasarkan kepadatan penghapusan dan batas waktu retensi. Sementara itu, batasi akses snapshot dan ekspor, serta catat waktu pembersihan fisik dalam status.
Bagaimana jika permintaan penghapusan dan event baru tiba secara bersamaan?
Gunakan penghalang subjek atau versi monotonik untuk menolak atau mengarantina event baru hingga penghapusan selesai. Replay harus memeriksa tombstone; hanya event yang secara eksplisit lebih baru dan diizinkan yang dapat lolos setelah dirilis.
Bagaimana jika suatu metrik turunan tidak dapat dilacak kembali ke pengguna?
Tandai domain tersebut sebagai tidak dapat dibuktikan, jeda publikasi, dan pilih antara mempertahankan status perantara tingkat subjek, pembangunan ulang partisi, atau alternatif yang disetujui. Tanpa bukti lineage, jangan mengklaim penghapusan.
Bagaimana Anda menjaga agar jejak audit tidak membocorkan data pribadi?
Simpan referensi subjek yang tidak dapat dibalik (irreversible), ID permintaan, cakupan, dan hitungan, bukan nama, email, atau isi konten event. Lindungi akses audit secara terpisah dan selaraskan retensinya dengan kebijakan privasi.