Soft delete vs hard delete: pilih siklus hidup data yang tepat

Apa sebenarnya arti soft delete dan hard delete

"Hapus" bisa berarti dua hal yang sangat berbeda. Mencampurnya adalah cara tim kehilangan riwayat atau gagal memenuhi permintaan privasi.

Hard delete adalah yang kebanyakan orang bayangkan: baris dihilangkan dari database. Dicari nanti dan sudah tidak ada. Itu penghapusan sejati, tetapi juga bisa memutus referensi (mis. order yang menunjuk ke customer yang dihapus) kecuali Anda mendesain untuk itu.

Soft delete mempertahankan baris, tetapi menandainya sebagai terhapus, biasanya dengan field seperti deleted_at atau is_deleted. Aplikasi menganggapnya sudah hilang, tetapi datanya tetap ada untuk laporan, dukungan, dan audit.

Pertukaran di balik soft delete vs hard delete sederhana: riwayat vs penghapusan nyata. Soft delete melindungi riwayat dan memungkinkan “undo”. Hard delete mengurangi apa yang Anda simpan, yang penting untuk privasi, keamanan, dan aturan hukum.

Penghapusan memengaruhi lebih dari sekadar penyimpanan. Mereka mengubah apa yang tim Anda bisa jawab nanti: agen dukungan yang mencoba memahami keluhan lama, tim keuangan yang merekonsiliasi tagihan, atau kepatuhan yang memeriksa siapa mengubah apa dan kapan. Jika data menghilang terlalu cepat, laporan bergeser, total tidak cocok, dan investigasi berubah jadi tebakan.

Model mental yang berguna:

• Soft delete menyembunyikan record dari tampilan sehari-hari tetapi menyimpannya untuk keterlacakan.
• Hard delete menghapus record secara permanen dan meminimalkan data pribadi yang disimpan.
• Banyak aplikasi nyata menggunakan keduanya: menyimpan catatan bisnis, menghapus identifier pribadi saat diperlukan.

Praktisnya, Anda mungkin soft delete akun pengguna untuk mencegah login dan menjaga riwayat order tetap utuh, lalu hard delete (atau anonimisasi) field pribadi setelah periode retensi atau permintaan GDPR right to erasure yang terverifikasi.

Tidak ada alat yang membuat keputusan ini untuk Anda. Bahkan jika Anda membangun dengan platform no-code seperti AppMaster, pekerjaan sebenarnya adalah memutuskan, per tabel, apa arti “dihapus” dan memastikan setiap layar, laporan, dan API mengikuti aturan yang sama.

Masalah nyata yang ditimbulkan penghapusan di aplikasi sehari-hari

Kebanyakan tim baru menyadari penghapusan ketika sesuatu bermasalah. Penghapusan yang “sederhana” bisa menghapus konteks, riwayat, dan kemampuan Anda menjelaskan apa yang terjadi.

Hard delete berisiko karena sulit dibatalkan. Seseorang menekan tombol yang salah, job otomatis punya bug, atau agen dukungan mengikuti playbook yang keliru. Tanpa backup yang bersih dan proses restore yang jelas, kehilangan itu menjadi permanen, dan dampak bisnis terasa cepat.

Referensi yang rusak adalah kejutan berikutnya. Anda menghapus customer, tapi order mereka tetap ada. Sekarang Anda punya order yang menunjuk ke mana-mana, faktur yang tidak bisa menampilkan nama penagihan, dan portal yang error saat memuat data terkait. Bahkan dengan foreign key constraints, “perbaikan”-nya bisa lebih buruk: cascading delete mungkin menghapus jauh lebih banyak dari yang Anda inginkan.

Analitik dan pelaporan juga menjadi berantakan. Saat record lama menghilang, metrik berubah secara retrospektif. Conversion rate bulan lalu bergeser, lifetime value turun, dan garis tren menjadi bolong yang tak bisa dijelaskan. Tim mulai berdebat soal angka daripada membuat keputusan.

Dukungan dan kepatuhan adalah tempat yang paling terasa. Pelanggan bertanya, “Kenapa saya ditagih?” atau “Siapa yang mengubah paket saya?” Jika record hilang, Anda tidak bisa merekonstruksi garis waktu. Anda kehilangan jejak audit yang menjawab pertanyaan dasar seperti apa yang berubah, kapan, dan oleh siapa.

Mode kegagalan umum di balik debat soft delete vs hard delete:

• Kehilangan permanen dari penghapusan tidak sengaja atau otomatisasi yang buggy
• Record induk yang hilang meninggalkan anak (order, tiket) yatim
• Laporan berubah karena baris historis lenyap
• Kasus dukungan menjadi tak terjawab tanpa riwayat

Kapan soft delete menjadi default yang lebih baik

Soft delete biasanya pilihan paling aman ketika record punya nilai jangka panjang atau terhubung ke data lain. Alih-alih menghapus baris, Anda menandainya sebagai terhapus (mis. deleted_at atau is_deleted) dan menyembunyikannya dari tampilan normal. Dalam keputusan soft delete vs hard delete, default ini cenderung mengurangi kejutan nanti.

Ini berguna di mana Anda membutuhkan audit trail in databases. Tim operasi sering perlu menjawab pertanyaan sederhana seperti “Siapa yang mengubah order ini?” atau “Kenapa faktur ini dibatalkan?” Jika Anda hard delete terlalu dini, Anda kehilangan bukti yang penting untuk keuangan, dukungan, dan pelaporan kepatuhan.

Soft delete juga membuat “undo” mungkin. Admin bisa mengembalikan tiket yang ditutup karena kesalahan, mengembalikan produk yang diarsipkan, atau memulihkan konten buatan pengguna setelah laporan spam yang keliru. Alur restore seperti itu sulit ditawarkan jika data sudah hilang secara fisik.

Relasi adalah alasan besar lainnya. Hard delete parent dapat memecahkan foreign key constraint atau meninggalkan celah membingungkan di laporan. Dengan soft delete, join tetap stabil dan total historis tetap konsisten (pendapatan harian, order yang dipenuhi, statistik waktu respons).

Soft delete merupakan default kuat untuk catatan bisnis seperti tiket dukungan, pesan, order, faktur, log audit, riwayat aktivitas, dan profil pengguna (setidaknya sampai Anda mengonfirmasi penghapusan final).

Contoh: agen dukungan “menghapus” catatan order yang berisi kesalahan. Dengan soft delete, catatan menghilang dari UI normal, tetapi supervisor masih bisa meninjaunya saat ada komplain, dan laporan keuangan tetap bisa dijelaskan.

Kapan hard delete diperlukan

Soft delete adalah default yang bagus untuk banyak aplikasi, tetapi ada saatnya menyimpan data (bahkan tersembunyi) adalah pilihan yang salah. Hard delete berarti record benar-benar dihapus, dan terkadang itu satu-satunya opsi yang cocok untuk kebutuhan hukum, keamanan, atau biaya.

Kasus paling jelas adalah kewajiban privasi dan kontraktual. Jika seseorang menggunakan hak penghapusan GDPR, atau kontrak Anda berjanji penghapusan setelah periode tertentu, “ditandai sebagai dihapus” seringkali tidak cukup. Anda mungkin harus menghapus baris, salinan terkait, dan identifier yang dapat mengarah kembali ke orang tersebut.

Keamanan adalah alasan lain. Beberapa data terlalu sensitif untuk disimpan: akses token mentah, kode reset kata sandi, private key, kode verifikasi sekali pakai, atau secret yang tidak terenkripsi. Menyimpannya demi riwayat jarang sebanding dengan risikonya.

Hard delete juga tepat untuk skala. Jika Anda punya tabel besar berisi event lama, log, atau telemetri, soft delete membuat database terus bertambah dan memperlambat kueri. Kebijakan purge terencana menjaga sistem responsif dan biaya dapat diprediksi.

Hard delete sering tepat untuk data sementara (cache, session, draft import), artefak keamanan jangka pendek (reset token, OTP, kode undangan), akun uji/demo, dan dataset historis besar di mana hanya statistik agregat yang dibutuhkan.

Pendekatan praktis adalah memisahkan “riwayat bisnis” dari “data pribadi.” Misalnya, simpan faktur untuk akuntansi, tetapi hard-delete (atau anonimisasi) field profil pengguna yang mengidentifikasi seseorang.

Jika tim Anda masih berdebat soft delete vs hard delete, gunakan tes sederhana: jika menyimpan data menimbulkan risiko hukum atau keamanan, hard delete (atau anonimisasi yang tidak dapat dipulihkan) harus menang.

Cara memodelkan soft delete tanpa kejutan

Soft delete bekerja terbaik saat ia membosankan dan dapat diprediksi. Tujuannya sederhana: record tetap di database, tetapi bagian normal aplikasi bertindak seolah-olah sudah hilang.

Pilih satu sinyal delete, dan jelaskan artinya

Anda akan melihat tiga pola umum: timestamp deleted_at, flag is_deleted, atau enum status. Banyak tim memilih deleted_at karena menjawab dua pertanyaan sekaligus: apakah terhapus, dan kapan itu terjadi.

Jika Anda sudah punya beberapa status lifecycle (active, pending, suspended), enum status masih bisa bekerja, tetapi pisahkan “deleted” dari “archived” dan “deactivated.” Itu berbeda:

• Deleted: tidak boleh muncul di daftar normal atau bisa dipakai.
• Archived: disimpan untuk riwayat, tetapi masih terlihat di tampilan “masa lalu”.
• Deactivated: dinonaktifkan sementara, sering bisa dibalik oleh pengguna.

Tangani field unik sebelum jadi masalah

Soft delete vs hard delete sering gagal pada field unik seperti email, username, atau nomor order. Jika pengguna “dihapus” tetapi email masih tersimpan dan unik, orang yang sama tidak bisa daftar lagi.

Dua solusi umum: terapkan keunikan hanya pada baris non-deleted, atau ubah nilai saat delete (mis. tambahkan suffix acak). Pilihan tergantung kebutuhan privasi dan audit Anda.

Buat aturan filtering eksplisit (dan konsisten)

Putuskan siapa yang melihat apa. Aturan umum: pengguna biasa tidak pernah melihat record terhapus, support/admin bisa melihat dengan label jelas, dan ekspor/laporan hanya menyertakan record terhapus jika diminta.

Jangan mengandalkan "semua orang ingat menambahkan filter". Letakkan aturan di satu tempat: views, query default, atau lapisan akses data Anda. Jika Anda membangun di AppMaster, biasanya berarti memasukkan filter ke dalam cara endpoint dan business process mengambil data, sehingga baris terhapus tidak muncul lagi di layar baru.

Tuliskan maknanya dalam catatan internal singkat (atau komentar skema). Anda akan berterima kasih ketika “deleted”, “archived”, dan “deactivated” muncul di meeting yang sama.

Menjaga referensi tetap utuh: parent, child, dan join

Penghapusan paling sering merusak aplikasi melalui relasi. Record jarang berdiri sendiri: pengguna punya order, tiket punya komentar, proyek punya file. Trik utama dalam soft delete vs hard delete adalah menjaga referensi konsisten sambil membuat produk berperilaku seperti item itu “hilang”.

Foreign keys: pilih mode kegagalan dengan sengaja

Foreign key melindungi Anda dari referensi rusak, tetapi tiap opsi punya makna berbeda:

• RESTRICT memblokir penghapusan jika anak ada.
• SET NULL mengizinkan penghapusan, tapi memutus anak.
• CASCADE otomatis menghapus anak.
• NO ACTION mirip RESTRICT di banyak database, tetapi timing bisa berbeda.

Jika Anda memakai soft delete, RESTRICT sering jadi default paling aman. Anda mempertahankan baris, jadi kunci tetap valid, dan Anda menghindari anak menunjuk ke mana-mana.

Soft delete dalam relasi: menyembunyikan tanpa membuat yatim

Soft delete biasanya tidak mengubah foreign key. Sebaliknya, Anda memfilter parent yang terhapus di aplikasi dan laporan. Jika customer di-soft-delete, faktur mereka tetap bisa di-join dengan benar, tetapi layar tidak boleh menampilkan customer itu di dropdown.

Untuk attachment, komentar, dan log aktivitas, putuskan apa arti “hapus” bagi pengguna. Beberapa tim mempertahankan shell tetapi menghapus bagian berisiko: ganti konten lampiran dengan placeholder jika privasi mengharuskan, tandai komentar sebagai dari pengguna yang dihapus (atau anonimisasi penulis), dan simpan log aktivitas tidak berubah.

Join dan pelaporan perlu aturan jelas: apakah baris terhapus disertakan? Banyak tim mempertahankan dua query standar: satu “hanya aktif” dan satu “termasuk terhapus”, sehingga dukungan dan pelaporan tidak sengaja menyembunyikan riwayat penting.

Langkah demi langkah: desain siklus hidup data yang memakai keduanya

Kebijakan praktis sering memakai soft delete untuk kesalahan sehari-hari dan hard delete untuk kebutuhan hukum atau privasi. Jika Anda menganggapnya sebagai satu keputusan (soft delete vs hard delete), Anda melewatkan jalan tengah: simpan riwayat untuk sementara, lalu hapus apa yang harus dihapus.

Rencana 5 langkah sederhana

Mulailah dengan mengelompokkan data ke beberapa bucket. “Profil pengguna” adalah data pribadi, “transaksi” adalah catatan finansial, dan “log” adalah riwayat sistem. Setiap bucket butuh aturan berbeda.

Rencana singkat yang bekerja di banyak tim:

• Definisikan grup data dan pemiliknya, dan tentukan siapa yang menyetujui penghapusan.
• Tetapkan aturan retensi dan proses restore.
• Putuskan apa yang dianonimkan daripada dihapus.
• Tambahkan langkah purge terjadwal (soft delete dulu, hard delete nanti).
• Catat event audit untuk setiap hapus, restore, dan purge (siapa, kapan, apa, dan kenapa).

Buat nyata dengan satu skenario

Misal pelanggan meminta menutup akunnya. Soft delete record pengguna segera agar mereka tidak bisa login dan Anda tidak memutus referensi. Lalu anonimisasi field pribadi yang tidak boleh dipertahankan (nama, email, telepon), sambil menyimpan fakta transaksi non-pribadi yang dibutuhkan untuk akuntansi. Terakhir, job purge terjadwal menghapus apa pun yang masih bersifat pribadi setelah periode tunggu.

Kesalahan umum dan jebakan yang harus dihindari

Tim bermasalah bukan karena memilih pendekatan yang salah, tetapi menerapkannya tidak merata. Pola umum: “soft delete vs hard delete” di dokumen, tetapi “sembunyikan di satu layar dan lupa sisanya” dalam praktik.

Satu kesalahan mudah: Anda menyembunyikan record terhapus di UI, tetapi mereka masih muncul lewat API, ekspor CSV, alat admin, atau job sinkronisasi. Pengguna cepat menyadari ketika “customer yang dihapus” muncul di daftar email atau hasil pencarian mobile.

Laporan dan pencarian adalah jebakan lain. Jika query laporan tidak konsisten memfilter baris terhapus, total bergeser dan dashboard kehilangan kepercayaan. Kasus terburuk adalah job latar yang mengindeks ulang atau mengirim ulang item yang sudah dihapus karena mereka tidak memakai aturan yang sama.

Hard delete juga bisa berlebihan. Satu cascading delete bisa menghapus order, faktur, pesan, dan log yang sebenarnya Anda butuhkan untuk audit. Jika Anda harus hard delete, jelaskan apa yang boleh hilang dan apa yang harus dipertahankan atau dianonimisasi.

Constraint unik menyebabkan sakit kepala halus dengan soft delete. Jika pengguna menghapus akun lalu mencoba mendaftar ulang dengan email yang sama, pendaftaran bisa gagal jika baris lama masih menyimpan email unik. Rencanakan ini sejak awal.

Tim kepatuhan akan bertanya: bisakah Anda membuktikan penghapusan terjadi, dan kapan? “Kami kira sudah dihapus” tidak akan lulus banyak review kebijakan retensi. Simpan timestamp penghapusan, siapa/apa yang memicunya, dan entri log yang tidak bisa diubah.

Sebelum rilis, cek seluruh permukaan: API, ekspor, pencarian, laporan, dan job latar. Juga tinjau cascade tabel demi tabel, dan pastikan pengguna bisa membuat ulang data “unik” seperti email atau username bila itu bagian janji produk Anda.

Daftar periksa cepat sebelum rilis

Sebelum memilih soft delete vs hard delete, verifikasi perilaku nyata aplikasi Anda, bukan hanya skema.

• Restore aman dan dapat diprediksi. Jika admin “membatalkan hapus”, apakah record kembali ke keadaan yang benar tanpa menghidupkan kembali data yang harus tetap hilang (mis. token akses yang dicabut)?
• Query menyembunyikan data terhapus secara default. Layar baru, ekspor, dan API tidak boleh secara tidak sengaja menyertakan baris terhapus. Tentukan satu aturan dan terapkan di mana-mana.
• Referensi tidak rusak. Pastikan foreign key dan join tidak menghasilkan record yatim atau layar setengah kosong.
• Purge punya jadwal dan pemilik. Soft delete hanya separuh rencana. Definisikan kapan data dihapus permanen, siapa yang menjalankannya, dan apa yang dikecualikan (mis. sengketa aktif).
• Penghapusan dicatat seperti tindakan sensitif lain. Catat siapa memicunya, kapan, dan alasannya.

Lalu uji jalur privasi end-to-end. Bisakah Anda memenuhi permintaan hak penghapusan GDPR di seluruh salinan, ekspor, indeks pencarian, tabel analitik, dan integrasi, bukan hanya database utama?

Cara praktis untuk validasi ini adalah menjalankan satu dry run “hapus pengguna” di staging dan mengikuti jejak data.

Contoh: menghapus pengguna sambil menjaga riwayat penagihan

Seorang pelanggan menulis: “Tolong hapus akun saya.” Anda juga punya faktur yang harus disimpan untuk akuntansi dan cek chargeback. Di sinilah soft delete vs hard delete jadi praktis: Anda bisa menghapus akses dan detail pribadi sambil menyimpan catatan finansial yang bisnis harus simpan.

Pisahkan “akun” dari “catatan penagihan.” Akun berkaitan dengan login dan identitas. Catatan penagihan berkaitan dengan transaksi yang sudah terjadi.

Pendekatan bersih:

• Soft delete akun pengguna sehingga mereka tidak bisa login dan profilnya hilang dari tampilan normal.
• Simpan faktur dan pembayaran sebagai record aktif, tetapi berhenti mengikatnya ke field pribadi.
• Anonimisasi data pribadi (nama, email, telepon, alamat) dengan menggantinya menjadi nilai netral seperti “Deleted User” ditambah referensi internal non-identifying.
• Hard delete item akses sensitif seperti API token, password hash, session, refresh token, dan perangkat yang diingat.
• Simpan hanya yang benar-benar diperlukan untuk kepatuhan dan dukungan, dan dokumentasikan alasannya.

Tiket dukungan dan pesan sering berada di tengah-tengah. Jika isi pesan mengandung data pribadi, Anda mungkin perlu meredaksi bagian teks, menghapus lampiran, dan menjaga shell tiket (timestamp, kategori, resolusi) untuk pelacakan kualitas. Jika produk Anda mengirim pesan (email/SMS, Telegram), hapus identifier outbound juga, sehingga orang tersebut tidak dikontak lagi.

Apa yang masih bisa dilihat dukungan? Biasanya nomor faktur, tanggal, jumlah, status, dan catatan bahwa pengguna dihapus serta kapan. Yang tidak boleh dilihat adalah apa pun yang mengidentifikasi orang: email login, nama lengkap, alamat, detail metode pembayaran tersimpan, atau sesi aktif.

Langkah berikutnya: tetapkan aturan, lalu terapkan secara konsisten

Keputusan penghapusan hanya bertahan ketika ditulis dan diterapkan dengan cara yang sama di seluruh produk. Perlakukan soft delete vs hard delete sebagai pertanyaan kebijakan dulu, bukan trik pemrograman.

Mulai dengan kebijakan retensi data sederhana yang bisa dibaca siapa saja di tim. Harus menjelaskan apa yang Anda simpan, berapa lama, dan kenapa. “Kenapa” penting karena menjelaskan apa yang menang ketika dua tujuan bertentangan (mis. riwayat dukungan vs permintaan privasi).

Default yang baik sering kali: soft delete untuk catatan bisnis sehari-hari (order, tiket, proyek), hard delete untuk data yang benar-benar sensitif (token, secret) dan apa pun yang tidak boleh Anda simpan.

Setelah kebijakan jelas, bangun alur yang menegakkannya: tampilan “trash” untuk restore, antrean “purge” untuk penghapusan tidak dapat dikembalikan setelah pemeriksaan, dan tampilan audit yang menunjukkan siapa melakukan apa dan kapan. Buat “purge” lebih sulit daripada “delete” agar tidak digunakan secara tidak sengaja.

Jika Anda mengimplementasikan ini di AppMaster (appmaster.io), membantu untuk memodelkan field soft-delete di Data Designer dan memusatkan logika delete, restore, dan purge di satu Business Process, sehingga aturan yang sama berlaku di seluruh layar dan endpoint API.