Konteks dan arahan
Setelah sebuah tenant ditutup, sistem menerima permintaan penghapusan. Data tenant tersebar di database utama, object storage, search index, cache, dan cadangan (backup). Penghapusan tidak boleh memblokir thread permintaan atau kehilangan pekerjaan secara diam-diam saat salah satu downstream tidak tersedia. Wawancara ini berfokus pada orkestrasi, idempotensi, pemulihan (recovery), dan bukti di balik status “complete”.
Apa yang sedang diuji oleh pewawancara
Pewawancara ingin melihat semantik penghapusan didefinisikan sebelum komponen digambar. Desain yang kuat mencakup katalog data, state machine, partisi tugas, kunci idempotensi, percobaan ulang (retry) dan dead letter, kontrol konkurensi, observabilitas, serta bukti akhir. Dokumentasi object-storage membedakan penghapusan langsung, versi, dan aturan siklus hidup (lifecycle rules); replika dan penghapusan asinkron berarti bahwa keberhasilan pada database utama bukanlah bukti bahwa setiap salinan telah diproses.
Pertanyaan klarifikasi yang perlu diajukan terlebih dahulu
Tanyakan apakah cakupannya adalah satu tenant, satu pengguna, atau sumber daya tertentu; bagaimana hard delete, delayed delete, dan jendela retensi didefinisikan; apakah cadangan langsung dihapus atau kedaluwarsa setelah jendela tertentu; catatan audit mana yang harus tetap ada tanpa menyalin data pribadi mentah; serta batasan konsistensi, waktu penyelesaian, skala, dan kebijakan apa yang berlaku. Jangan mengarang tenggat waktu hukum yang tidak diberikan.
Kerangka jawaban 30 detik
Katakan: “Saya akan membangun katalog data tenant dan kebijakan penghapusan, kemudian mengorkestrasikan tugas-tugas penghapusan berversi melalui adaptor penyimpanan. Permintaan tersebut membuat satu tugas idempoten dan kembali dengan cepat; sebuah antrean mendorong fase-fasenya, dan setiap fase mencatat bukti, percobaan ulang, serta kesalahan terakhirnya. Verifikator menandai tugas selesai hanya ketika data utama, indeks turunan, cache, dan cadangan yang diizinkan oleh kebijakan telah memenuhi statusnya; jika tidak, verifikator akan menjadwalkan percobaan ulang atau penanganan manusia.”
Analisis mendalam langkah demi langkah
1. Bangun katalog data dan kebijakan
Untuk setiap sumber daya, catat kepemilikan tenant, lokasi, derivasi, metode penghapusan, jendela retensi, dan kueri verifikasi. Tandai cadangan atau log yang tidak dapat segera dihapus sebagai pengecualian kebijakan, termasuk masa kedaluwarsa, persetujuan, dan bagaimana data tersebut tetap tidak dapat diakses untuk pembacaan produk selama masa retensi.
2. Kirimkan tugas penghapusan yang idempoten
Alur penutupan membuat deletionJobId yang unik secara global dan menggunakan generasi tenant atau versi event penutupan sebagai kondisi idempotensi. API mengembalikan status diterima dengan cepat; permintaan duplikat mengembalikan tugas yang sama. Simpan snapshot dari versi katalog sehingga pengeditan katalog di kemudian hari tidak mengubah batasan tugas.
3. Pisahkan pekerjaan yang dapat diulang berdasarkan dependensi
Bekukan penulisan atau alihkan status tenant terlebih dahulu, lalu proses rekaman dan objek utama, diikuti oleh search index, cache, dan file turunan. Setiap adaptor menggunakan (deletionJobId, resourceId, generation) sebagai kunci idempotensinya. Keberhasilan, kondisi sudah tidak ada (already-absent), dan kesalahan yang aman untuk diulang memerlukan hasil yang berbeda; kesalahan yang tidak dapat diulang masuk ke antrean dead-letter dengan jalur pemulihan manusia.
4. Tangani replika, versi, dan cadangan
Object storage mungkin memiliki versi, aturan siklus hidup, dan replika lintas wilayah; panggilan API penghapusan yang berhasil tidak membuktikan bahwa salinan asinkron langsung hilang. Catat waktu permintaan, versi atau penanda hapus (delete marker) yang diamati, dan pemeriksaan terakhir untuk setiap replika. Biarkan cadangan melewati kebijakan retensinya dan verifikasi bahwa data tidak dapat dipulihkan setelah kedaluwarsa, daripada berpura-pura bahwa penghapusan terjadi seketika.
5. Rancang verifikator dan status penyelesaian
Verifikator mengueri katalog dan memeriksa pembacaan utama, pencarian indeks, pembacaan cache, dan daftar objek. State machine harus membedakan setidaknya ACCEPTED, RUNNING, WAITING_RETRY, BLOCKED, VERIFIED, dan FAILED. Hanya sumber daya yang diperlukan dengan bukti dan pengecualian kebijakan eksplisit yang dapat mencapai VERIFIED; penulisan kondisional mencegah percobaan ulang yang lama menimpa hasil yang lebih baru.
6. Tambahkan observabilitas, isolasi, dan audit
Lacak latensi, tingkat keberhasilan, percobaan ulang, dead letter, downstream throttling, dan sumber daya yang tersisa berdasarkan tenant dan tugas. Gunakan kredensial khusus dan hak istimewa paling minimal (least privilege) untuk mencegah penghapusan lintas-tenant. Catatan audit hanya menyimpan ID tugas, jenis sumber daya, versi kebijakan, aktor, dan ringkasan hasil, tidak pernah data mentah. Peringatan (alerts) membedakan satu tenant yang terblokir dari pemadaman (outage) downstream global.
Contoh jawaban berkualitas tinggi
“Saya akan mulai dengan katalog tabel, prefiks objek, indeks, kunci cache, dan kebijakan cadangan, masing-masing dengan kepemilikan tenant, metode penghapusan, dan kueri verifikasi. Menutup tenant menulis satu deletionJobId yang unik, membekukan penulisan baru, dan memasukkan tugas ke dalam antrean. Orkestrator mengikuti dependensi: data utama dan objek terlebih dahulu, kemudian indeks dan cache; setiap adaptor bersifat idempoten berdasarkan generasi sumber daya. Bukti replika dan versi objek dicatat, sementara cadangan mengikuti kebijakan retensinya alih-alih diklaim terhapus seketika. Sebuah verifikator memeriksa ulang daftar utama, pencarian, cache, dan objek serta beralih ke VERIFIED hanya ketika setiap sumber daya yang diperlukan telah terbukti. Kegagalan downstream menggunakan exponential backoff dan kemudian jalur dead-letter dengan pemilik yang ditentukan. Audit menyimpan versi kebijakan, ringkasan hasil, dan ID tugas; kredensial diisolasi per-tenant. Klien menerima status dan bukti yang dapat dikueri, bukan sekadar string ‘deleted’ yang tidak didukung bukti.”
Kesalahan umum dan perbaikan
- Hanya menghapus baris utama: Buat katalog data dan derivasinya, lalu tentukan penghapusan dan verifikasi untuk masing-masing.
- Memanggil setiap downstream secara sinkron: Gunakan antrean tugas dan state machine untuk mengisolasi latensi permintaan dari pemadaman.
- Memperlakukan pekerjaan duplikat sebagai pengecualian (exception): Tentukan kunci idempotensi per sumber daya dan bedakan kondisi sudah tidak ada dari kegagalan.
- Menjanjikan penghapusan cadangan instan: Nyatakan jendela retensi, siklus hidup, dan status kedaluwarsa yang dapat diverifikasi.
Pertanyaan lanjutan dan responsnya
Apa yang harus dilihat klien saat downstream terus mengalami kegagalan?
Kembalikan status tugas, fase, kelas kesalahan, dan waktu percobaan ulang berikutnya yang dapat dikueri tanpa mengekspos kredensial internal. Setelah anggaran percobaan ulang habis, beralihlah ke BLOCKED atau FAILED, beri tahu pemiliknya, dan pertahankan jalur lanjutkan (resume) yang aman.
Bagaimana Anda mencegah tugas lama menghapus penulisan baru?
Bekukan penulisan atau gunakan generasi tenant. Setiap penghapusan membawa generasi yang ditangkap saat pembuatan, dan kondisi penyimpanan akan menolak ketidakcocokan. Pembaruan katalog dan status juga menggunakan penulisan kondisional berversi.
Bagaimana Anda menguji bahwa VERIFIED tidak memberikan hasil positif palsu (false positive)?
Sisipkan pesan duplikat, replika yang tertunda, pembangunan ulang indeks, pengisian ulang cache, dan pemulihan cadangan. Jika kueri yang disimulasikan masih dapat membaca data, verifikator harus tetap dalam status belum selesai dan mencatat bukti yang hilang.
Bagaimana jika log audit itu sendiri berisi informasi tenant?
Simpan hanya referensi atau hash tenant yang tidak dapat dibalik (irreversible), ID tugas, versi kebijakan, dan ringkasan hasil. Batasi akses dan berikan kebijakan retensi tersendiri untuk catatan audit. Pengauditan harus membuktikan pemrosesan tanpa menyalin data yang dihapus.