Soft deletes vs hard deletes: tradeoff yang penting dalam aplikasi nyata

Apa arti sebenarnya soft delete dan hard delete

Tombol hapus bisa berarti dua hal sangat berbeda di basis data.

Hard delete menghapus baris. Setelah itu, record hilang kecuali Anda punya backup, log, atau replika yang masih menyimpannya. Sederhana untuk dipahami, tetapi bersifat final.

Soft delete menyimpan baris tetapi menandainya sebagai dihapus, biasanya dengan field seperti deleted_at atau is_deleted. Aplikasi lalu memperlakukan baris bertanda sebagai tidak terlihat. Anda mempertahankan data terkait, merekam riwayat, dan kadang bisa mengembalikan record.

Pilihan ini muncul dalam pekerjaan sehari-hari lebih sering daripada yang orang kira. Ia memengaruhi bagaimana Anda menjawab pertanyaan seperti: “Kenapa pendapatan turun bulan lalu?”, “Bisakah kembalikan proyek yang saya hapus?”, atau “Kami mendapat permintaan penghapusan GDPR — apakah data pribadi benar-benar terhapus?” Juga membentuk arti “dihapus” di UI. Pengguna sering berharap bisa membatalkan sampai mereka tidak bisa lagi.

Aturan praktis singkat:

• Gunakan soft delete saat pengguna mengharapkan undo, saat support perlu memulihkan kesalahan, atau saat Anda butuh jejak audit.
• Gunakan hard delete saat menyimpan data menghadirkan risiko hukum, risiko keamanan, atau biaya penyimpanan yang jelas tanpa nilai nyata.
• Gunakan keduanya saat Anda ingin periode “sampah”: soft delete dulu, lalu purge permanen nanti.

Contoh: seorang pelanggan menghapus workspace lalu menyadari ada faktur yang diperlukan untuk akuntansi. Dengan soft delete, support dapat merestore (jika aplikasi Anda dirancang untuk restore yang aman). Dengan hard delete, Anda kemungkinan terjebak menjelaskan backup, keterlambatan, atau “tidak bisa.”

Tidak ada pendekatan yang selalu “terbaik.” Pilihan paling sedikit menyakitkan bergantung pada apa yang perlu Anda lindungi: kepercayaan pengguna, akurasi pelaporan, atau kepatuhan privasi.

Tradeoff analytics: akurasi vs menjaga riwayat

Pilihan penghapusan cepat terlihat di analytics. Pada hari Anda mulai melacak pengguna aktif, konversi, atau pendapatan, “dihapus” berhenti menjadi status sederhana dan menjadi keputusan pelaporan.

Jika Anda hard delete, banyak metrik tampak bersih karena record yang dihapus hilang dari query. Tapi Anda juga kehilangan konteks: langganan masa lalu, ukuran tim sebelumnya, atau seperti apa funnel bulan lalu. Pelanggan yang dihapus bisa membuat grafik historis berubah saat Anda menjalankan ulang laporan, yang menakutkan untuk tinjauan keuangan dan growth.

Jika Anda soft delete, Anda menjaga riwayat, tetapi bisa secara tidak sengaja membengkakkan angka. Sederhana “COUNT users” mungkin termasuk orang yang sudah pergi. Grafik churn bisa menghitung ganda jika Anda menganggap deleted_at sebagai churn di satu laporan dan mengabaikannya di laporan lain. Bahkan pendapatan bisa berantakan jika faktur tetap ada tetapi akun ditandai dihapus.

Yang cenderung bekerja adalah memilih pola pelaporan yang konsisten dan menaatinya:

• Filter record yang dihapus dalam metrik “kondisi saat ini” (pengguna aktif, MRR saat ini).
• Gunakan tabel snapshot untuk dashboard berbasis waktu agar riwayat tidak berubah saat entitas dihapus kemudian.
• Pisahkan fakta dari entitas: simpan baris event yang immutable (pembayaran, login) meskipun Anda menyembunyikan record pengguna.
• Perlakukan “dihapus” sebagai status lifecycle dengan tanggalnya sendiri, dan laporkan secara eksplisit (created, activated, deleted).
• Tentukan window retensi: kapan data soft-deleted menjadi benar-benar dihapus.

Kuncinya adalah dokumentasi agar analis tidak menebak. Tuliskan apa arti “aktif”, apakah pengguna soft-deleted disertakan, dan bagaimana pendapatan diatribusi jika akun kemudian dihapus.

Contoh konkret: sebuah workspace dihapus oleh kesalahan, lalu dipulihkan. Jika dashboard Anda menghitung workspace tanpa filter, Anda akan menunjukkan penurunan dan pemulihan mendadak yang sebenarnya tidak terjadi dalam penggunaan riil. Dengan snapshot, grafik historis tetap stabil sementara tampilan produk masih bisa menyembunyikan workspace yang dihapus.

Support dan jejak audit: apa yang bisa dipulihkan nanti

Sebagian besar tiket support terkait penghapusan terdengar sama: “Saya menghapusnya karena keliru,” atau “Ke mana record saya?” Strategi hapus Anda menentukan apakah support bisa menjawab dalam hitungan menit, atau apakah jawaban jujur satu-satunya adalah “Sudah hilang.”

Dengan soft delete, Anda biasanya bisa memverifikasi apa yang terjadi dan membatalkannya. Dengan hard delete, support sering harus bergantung pada backup (jika ada), dan itu bisa lambat, tidak lengkap, atau mustahil untuk satu item. Karena itu pilihan ini bukan hanya detail basis data. Ia membentuk seberapa “membantu” produk Anda setelah sesuatu salah.

Jejak audit sederhana (apa yang disimpan)

Jika Anda mengharapkan support nyata, tambahkan beberapa field yang menjelaskan event penghapusan:

• deleted_at (timestamp)
• deleted_by (user id atau sistem)
• delete_reason (opsional, teks singkat)
• deleted_from_ip atau deleted_from_device (opsional)
• restored_at dan restored_by (jika Anda mendukung restore)

Bahkan tanpa log aktivitas penuh, detail ini membantu support menjawab: siapa yang menghapus, kapan terjadi, dan apakah itu kecelakaan atau pembersihan otomatis.

Apa arti hard delete untuk support

Hard delete bisa baik untuk data sementara, tetapi untuk record yang terlihat pengguna mereka mengubah apa yang bisa dilakukan support.

Support tidak bisa merestore satu record kecuali Anda membangun recycle bin di tempat lain. Mereka mungkin perlu restore backup penuh, yang bisa memengaruhi data lain. Mereka juga tidak mudah membuktikan apa yang terjadi, yang menyebabkan bolak-balik panjang.

Fitur restore mengubah beban kerja juga. Jika pengguna bisa self-restore dalam jendela waktu, tiket berkurang. Jika restore membutuhkan support melakukan secara manual, tiket mungkin meningkat, tetapi menjadi cepat dan berulang alih-alih investigasi satu-satu.

Penghapusan ala GDPR: soft delete bukan penghapusan penuh

“Right to be forgotten” biasanya berarti Anda harus berhenti memproses data seseorang dan menghapusnya dari tempat-tempat di mana data itu masih bisa digunakan. Itu tidak selalu berarti Anda harus menghapus setiap agregat historis segera, tetapi itu berarti Anda tidak boleh menyimpan data yang bisa diidentifikasi “hanya untuk berjaga-jaga” jika Anda tidak lagi punya alasan hukum untuk menyimpannya.

Di sinilah soft delete vs hard delete menjadi lebih dari sekadar pilihan produk. Soft delete (mis. men-set deleted_at) sering hanya menyembunyikan record dari aplikasi. Data masih ada di basis data, masih bisa di-query oleh admin, dan sering masih muncul di ekspor, indeks pencarian, dan tabel analytics. Untuk banyak permintaan penghapusan GDPR, itu bukan penghapusan.

Anda masih perlu purge ketika:

• Pengguna meminta penghapusan dan Anda tidak punya alasan retensi yang valid (mis. aturan penagihan).
• Anda menyimpan data kategori khusus dan kebijakan Anda mengatakan harus dihapus.
• Record muncul di ekspor yang terlihat pengguna atau bisa dipulihkan oleh support.
• Pihak ketiga (email, analytics, alat support) masih menyimpannya.

Backup dan log adalah bagian yang sering terlupakan. Anda mungkin tidak bisa menghapus satu baris dari backup terenkripsi, tetapi Anda bisa menetapkan aturan: backup kadaluwarsa cepat, dan backup yang dipulihkan harus menerapkan ulang event penghapusan sebelum sistem live. Log harus menghindari menyimpan data pribadi mentah bila memungkinkan, dan punya batas retensi yang jelas.

Kebijakan sederhana dan praktis adalah penghapusan dua langkah:

1. Soft delete segera (supaya produk berperilaku benar, akun dinonaktifkan, dan “restore deleted records” bisa bekerja untuk kesalahan).
2. Mulai timer retensi (mis. 7 sampai 30 hari) dan jadwalkan job purge yang hard-delete atau meng-anonimkan field pribadi.
3. Catat apa yang terjadi di jejak audit menggunakan penanda non-identifikasi (timestamp, kode alasan) supaya support bisa menjelaskan tindakan tanpa mempertahankan data.

Jika platform Anda mendukung ekspor kode sumber atau ekspor data, perlakukan file yang diekspor sebagai penyimpanan data juga: tentukan di mana mereka berada, siapa yang dapat mengaksesnya, dan kapan mereka dihapus.

Kompleksitas query dan perilaku produk: biaya tersembunyi

Soft delete terdengar sederhana: tambahkan deleted_at (atau is_deleted) dan sembunyikan baris. Biaya tersembunyi adalah setiap tempat Anda membaca data sekarang harus mengingat flag itu. Terlewat sekali, dan Anda mendapat bug aneh: total menyertakan item yang dihapus, pencarian menampilkan hasil “hantu”, atau pengguna melihat sesuatu yang mereka kira sudah hilang.

Edge case UI dan UX muncul cepat. Bayangkan sebuah tim menghapus proyek bernama “Roadmap” lalu mencoba membuat “Roadmap” baru. Jika basis data Anda punya aturan unik pada nama, pembuatan bisa gagal karena baris yang dihapus masih ada. Pencarian juga bisa membingungkan: jika Anda menyembunyikan item di list tapi tidak di pencarian global, pengguna akan menganggap aplikasi Anda rusak.

Filter soft delete sering terlupa di:

• Dashboard admin dan alat support
• Job background (email, pengingat, pembersihan)
• Query dan ekspor analytics
• Pemeriksaan izin (“apakah record ini ada?”)
• Autocomplete dan pencarian

Performa biasanya baik pada awalnya, tetapi kondisi ekstra menambah pekerjaan. Jika sebagian besar baris aktif, memfilter deleted_at IS NULL murah. Jika banyak baris dihapus, basis data harus melewati lebih banyak baris kecuali Anda menambahkan index yang tepat. Dalam kata sederhana: ini seperti mencari dokumen saat ini di laci yang juga berisi banyak dokumen lama.

Area “Arsip” terpisah dapat mengurangi kebingungan. Buat tampilan default hanya menunjukkan record aktif, dan tempatkan item yang dihapus di satu lokasi dengan label jelas dan jendela waktu. Dalam alat yang dibuat cepat (mis. aplikasi internal yang dibuat di Koder.ai), keputusan produk ini sering mencegah lebih banyak tiket support daripada trik query apa pun.

Model data umum untuk soft delete

Soft delete bukan satu fitur tunggal. Ini pilihan model data, dan model yang Anda pilih akan membentuk semua yang mengikuti: aturan query, perilaku restore, dan apa arti “dihapus” bagi produk Anda.

Model 1: deleted_at plus deleted_by

Pola paling umum adalah timestamp nullable. Saat record dihapus, set deleted_at (dan sering deleted_by ke id pengguna). “Aktif” adalah record yang deleted_at-nya null.

Ini bekerja baik saat Anda butuh restore bersih: restore cukup menghapus deleted_at dan deleted_by. Ini juga memberi sinyal audit sederhana untuk support.

Model 2: status eksplisit

Alih-alih timestamp, beberapa tim memakai field status dengan state jelas seperti active, archived, dan deleted. Ini berguna ketika “archived” adalah status produk yang nyata (tersembunyi dari sebagian besar layar tetapi masih dihitung untuk penagihan, misalnya).

Biayanya adalah aturan. Anda harus mendefinisikan arti tiap state di mana-mana: pencarian, notifikasi, ekspor, dan analytics.

Model 3: penyimpanan terpisah untuk record bernilai tinggi

Untuk objek sensitif atau bernilai tinggi, Anda bisa memindahkan baris yang dihapus ke tabel terpisah, atau merekam event di log append-only.

• Timestamp soft delete: deleted_at, deleted_by
• State machine: status dengan state bernama
• Tabel deleted terpisah: tabel “aktif” tetap kecil
• Event log: simpan “siapa melakukan apa” tanpa menyimpan baris penuh selamanya

Ini sering dipakai saat restore harus sangat dikontrol, atau saat Anda ingin jejak audit tanpa mencampur data yang dihapus ke query sehari-hari.

Catatan: child record juga butuh aturan jelas. Jika sebuah workspace dihapus, apa yang terjadi pada proyek, file, dan keanggotaan?

• Cascade: tandai anak juga dihapus
• Restrict: hentikan penghapusan sampai anak ditangani
• Archive: ubah anak menjadi archived (bukan dihapus)
• Detach: hapus relasi tapi pertahankan anak

Pilih satu aturan per relasi, tuliskan, dan jaga konsistensi. Sebagian besar bug “restore salah” muncul karena parent dan child memakai arti deleted yang berbeda.

Cara mengimplementasikan fitur restore yang aman (langkah demi langkah)

Tombol restore terdengar sederhana, tetapi bisa diam-diam merusak izin, menghidupkan kembali data lama ke tempat yang salah, atau membingungkan pengguna jika “restored” bukan yang mereka harapkan. Mulailah dengan menuliskan janji tepat yang dibuat produk Anda.

Alur restore praktis

Gunakan urutan kecil dan ketat supaya restore dapat diprediksi dan diaudit.

1. Tentukan apa arti “restore”. Apakah record akan mempertahankan ID yang sama? Haruskah kembali ke parent yang sama (workspace, project) dan mempertahankan relasi yang sama? Putuskan apa yang terjadi pada keanggotaan, peran, dan visibilitas.
2. Minta konfirmasi pengguna dan tangkap alasan. Tampilkan apa yang akan direstore (nama, pemilik, tanggal terakhir diubah) dan minta konfirmasi jelas. Untuk tim support, field alasan singkat (“salah hapus”, “menutup tiket”) biasanya cukup.
3. Periksa konflik sebelum mengubah apa pun. Masalah umum: nama lama dipakai ulang, pengguna tidak lagi punya izin, atau record terkait dihapus secara permanen. Pilih aturan: blokir restore dengan pesan jelas, atau restore ke state “butuh tinjauan”.
4. Log tindakan restore. Catat siapa yang merestore, kapan, dari mana (UI, API), dan apa yang berubah. Ini membantu audit dan support, dan esensial bila ada pertanyaan “Kenapa ini kembali?”.
5. Tambahkan batas waktu jika cocok. Banyak aplikasi mengizinkan restore selama 30 atau 90 hari, lalu memerlukan proses pemulihan berbeda atau menganggapnya permanen.

Jika Anda membangun aplikasi cepat di tool chat-driven seperti Koder.ai, jadikan pengecekan ini bagian dari workflow yang dihasilkan supaya setiap layar dan endpoint mengikuti aturan yang sama.

Kesalahan umum dan jebakan yang harus dihindari

Kesulitan terbesar dengan soft delete bukan pada penghapusan itu sendiri, tetapi semua tempat yang lupa bahwa record “hilang.” Banyak tim memilih soft delete demi keamanan, lalu secara tidak sengaja menampilkan item yang dihapus di hasil pencarian, badge, atau total. Pengguna cepat menyadarinya ketika dashboard menulis “12 proyek” tetapi hanya muncul 11 di daftar.

Kedua adalah kontrol akses. Jika pengguna, tim, atau workspace di-soft-delete, mereka seharusnya tidak bisa login, memanggil API, atau menerima notifikasi. Ini sering terlewat saat cek login mencari berdasarkan email, menemukan baris, dan tidak memeriksa flag deleted.

Jebakan umum yang membuat tiket support:

• Filter deleted hilang di satu jalur baca (tampilan admin, ekspor, pencarian, job background).
• Merestore record yang bertabrakan dengan field unik (email, username, slug, nomor faktur).
• Menghapus parent tapi meninggalkan anak “aktif” (atau menghapus anak sementara parent masih terlihat hidup).
• Menghitung baris yang dihapus dalam analytics, kuota, atau perhitungan billing.
• Mengirim data yang dihapus ke pihak ketiga karena integrasi dan job sinkron tidak memahami “dihapus”.

Tabrakan unik sangat menyebalkan saat restore. Jika seseorang membuat akun baru dengan email yang sama sementara akun lama di-soft-delete, restore bisa gagal atau menimpa identitas yang salah. Tentukan aturan dari awal: blokir penggunaan ulang sampai purge, izinkan penggunaan ulang tapi larang restore, atau restore dengan identifier baru.

Satu skenario umum: agen support merestore workspace yang di-soft-delete. Workspace kembali, tetapi anggotanya tetap dihapus, dan integrasi mulai menyinkron ulang record lama ke alat mitra. Dari sudut pandang pengguna, restore “setengah berhasil” dan membuat kekacauan baru.

Sebelum merilis fitur restore, buat perilaku-perilaku ini eksplisit:

• Apa arti “dihapus” untuk login, akses API, dan notifikasi
• Bagaimana restore menangani field unik dan kepemilikan
• Bagaimana record terkait mengikuti parent (all-or-nothing lebih baik daripada kejutan)
• Bagaimana ekspor dan integrasi memperlakukan data yang dihapus (kecualikan, beri label, atau kirim tombstones)

Contoh realistis: workspace terhapus karena keliru

Tim B2B SaaS punya tombol “Delete workspace”. Suatu Jumat, seorang admin melakukan pembersihan dan menghapus 40 workspace yang tampak tidak aktif. Senin, tiga pelanggan mengeluh proyek mereka hilang dan meminta restore segera.

Tim mengira keputusan sederhana. Ternyata tidak.

Masalah pertama: support tidak bisa merestore apa yang benar-benar dihapus. Jika baris workspace di-hard-delete dan cascade menghapus proyek, file, dan keanggotaan, satu-satunya opsi adalah backup. Itu berarti waktu, risiko, dan jawaban canggung ke pelanggan.

Masalah kedua: analytics terlihat rusak. Dashboard menghitung “active workspaces” dengan query deleted_at IS NULL. Penghapusan tidak sengaja membuat grafik menunjukkan penurunan tiba-tiba. Lebih parah, laporan mingguan membandingkan ke minggu lalu dan menandai lonjakan churn palsu. Data tidak hilang, tetapi dikecualikan di tempat yang salah.

Masalah ketiga: permintaan privasi datang untuk salah satu pengguna yang terdampak. Mereka meminta penghapusan data pribadi. Soft delete murni tidak memadai. Tim butuh rencana untuk mem-purge field pribadi (nama, email, log IP) sambil mempertahankan agregat non-pribadi seperti total penagihan dan nomor faktur.

Masalah keempat: semua bertanya, “Siapa yang klik delete?” Jika tidak ada jejak, support tidak bisa menjelaskan apa yang terjadi.

Pola yang lebih aman adalah memperlakukan penghapusan sebagai event dengan metadata jelas:

• Tandai workspace sebagai dihapus (dan sembunyikan di produk)
• Catat deleted_by, deleted_at, dan alasan atau id tiket
• Log apa yang akan terpengaruh (jumlah proyek, seat, penyimpanan)
• Izinkan restore dalam jendela waktu, lalu purge field pribadi tertentu ketika diperlukan

Ini jenis workflow yang sering dibangun cepat di platform seperti Koder.ai, lalu tim sadar bahwa kebijakan hapus perlu didesain sama pentingnya dengan fitur di sekitarnya.

Checklist cepat untuk memilih strategi hapus yang tepat

Memilih antara soft delete vs hard delete lebih soal apa yang aplikasi Anda harus jamin setelah record “pergi” daripada preferensi. Tanyakan ini sebelum menulis satu query pun.

• Apakah Anda perlu erasure nyata? Jika Anda harus memenuhi permintaan privasi atau hukum, rencanakan penghapusan sejati (termasuk backup, ekspor, dan cache). Flag soft delete saja tidak memenuhi “hapus sepenuhnya”.
• Apakah Anda perlu tombol restore, dan berapa lama? Jika undo penting, tentukan jendela restore (7 hari, 30 hari, selamanya) dan apa yang terjadi setelahnya.
• Apakah pelaporan membutuhkan data lama setelah penghapusan? Beberapa tim ingin grafik mencerminkan apa yang pengguna lihat hari ini; yang lain perlu hitungan historis untuk keuangan atau analisis growth. Pilihan hapus mengubah arti “pengguna aktif” dan “total pendapatan”.
• Bisakah support menjelaskan tanpa kerja detektif? Jika Anda mengharapkan tiket seperti “proyek saya hilang”, Anda perlu jejak jelas: siapa menghapus, kapan, dan dari mana, plus cukup data untuk investigasi.
• Bisakah tim menjaga konsistensi perilaku di mana-mana? Soft delete sering menciptakan aturan tersembunyi: setiap query harus memfilter record yang dihapus, setiap join harus konsisten, dan setiap layar harus setuju tentang arti “dihapus”.

Cara sederhana untuk memeriksa keputusan adalah pilih satu insiden realistis dan jalankan skenario. Contoh: seseorang menghapus workspace karena keliru Jumat malam. Senin, support perlu melihat event penghapusan, mengembalikannya dengan aman, dan menghindari membangkitkan kembali data terkait yang harus tetap dihapus. Jika Anda membangun aplikasi di platform seperti Koder.ai, definisikan aturan ini sejak awal supaya backend dan UI yang digenerasi mengikuti satu kebijakan alih-alih menyebarkan pengecualian di seluruh kode.

Langkah selanjutnya: pilih kebijakan dan bangun dengan aman

Pilih pendekatan dengan menulis kebijakan sederhana yang bisa dibagikan dengan tim dan support. Jika tidak tertulis, kebijakan akan berubah, dan pengguna akan merasakan inkonsistensi.

Mulai dengan seperangkat aturan jelas:

• Apa yang di-soft-delete (dan berapa lama bisa direstore)
• Apa yang di-hard-delete segera (dan kenapa)
• Kapan data soft-deleted dipurge (mis. setelah X hari)
• Siapa yang bisa merestore, dan bukti atau persetujuan apa yang diperlukan
• Bagaimana permintaan penghapusan yang dipicu privasi ditangani secara end-to-end

Lalu bangun dua jalur yang jelas yang tidak bercampur: jalur “admin restore” untuk kesalahan, dan jalur “privacy purge” untuk penghapusan nyata. Jalur restore harus reversible dan tercatat. Jalur purge bersifat final dan menghapus atau meng-anonimkan semua data terkait yang dapat mengidentifikasi orang, termasuk backup atau ekspor jika kebijakan Anda mengharuskannya.

Tambahkan guardrail supaya data yang dihapus tidak bocor kembali ke produk. Cara termudah adalah memperlakukan “dihapus” sebagai state kelas satu dalam pengujian Anda. Tambahkan checkpoint review untuk setiap query, halaman daftar, pencarian, ekspor, dan job analytics. Aturan praktis: jika layar menampilkan data yang terlihat pengguna, harus ada keputusan eksplisit tentang record yang dihapus (sembunyikan, tampilkan dengan label, atau hanya untuk admin).

Jika Anda berada di tahap awal produk, buat prototipe kedua alur sebelum mengunci skema. Di Koder.ai, Anda dapat menggambarkan kebijakan penghapusan di planning mode, menghasilkan CRUD dasar, dan cepat mencoba skenario restore dan purge, lalu menyesuaikan model data sebelum commit.