Back to Blog

Soft Delete & Audit Logs

February 19, 20263 min
Soft DeleteAudit LoggingData Integrity
Soft Delete & Audit Logs

Soft Delete

Neden Soft Delete Kullanırız?

Bir kaydı DELETE FROM users WHERE id=1; ile fiziksel olarak sildiğinde veri tamamen kaybolur.

Gerçek dünyada:

  • Kullanıcı yanlışlıkla silme yapabilir
  • Hukuki gereksinimler olabilir
  • Geçmiş raporlar için veri saklanmalıdır
  • İlişkisel bütünlük korunmalıdır

Soft Delete, veriyi fiziksel olarak silmek yerine mantıksal olarak silinmiş işaretlemektir.

Kullanmazsak Ne Olur?

  • Yanlış silinen veri geri getirilemez
  • Raporlar bozulur
  • Foreign key ilişkileri anlamsızlaşır
  • “Sahipsiz” kayıtlar oluşabilir

Örneğin:

Kullanıcı silindi → Eski siparişleri kime ait?

Nasıl Yapılır?

Tabloya bir kolon eklenir:

  • deleted_at TIMESTAMP NULL veya
  • is_deleted BOOLEAN

Örnek

UPDATE users 
SET deleted_at = NOW() 
WHERE id = 1;

Sorgular:

SELECT * 
FROM users 
WHERE deleted_at IS NULL;

Kritik Nokta

Soft delete kullandığında tüm SELECT sorgularına otomatik filtre eklenmelidir:

WHERE deleted_at IS NULL

Bunu:

  • Middleware
  • Repository layer
  • ORM global scope
  • Sequelize paranoid: true

ile otomatik hâle getirmek gerekir.

Aksi halde silinen veriler her yerde görünür.

Soft Delete vs Status

AlanAnlamı
statusBusiness state (aktif, blokeli, beklemede)
updated_atSon değişiklik zamanı
deleted_atLifecycle event (silinme zamanı)

Önemli nokta:

Soft delete bir state değildir. Bir lifecycle event’tir.

Lifecycle = Kaydın zaman çizelgesindeki olayları.

Silme işlemi:

  • İş yaşam döngüsünden çıkışı temsil eder
  • Ancak soft delete sayesinde geri alınabilir

Soft Delete'in Bedeli

  • Veritabanı büyür
  • Index maliyeti artar
  • Sorgular daha karmaşık olur

Çözüm:

  • Arşivleme
  • Periodic cleanup
  • Partitioning

Audit Logs

Neden Audit Log Kullanırız?

Sorular:

  • Bu kullanıcının şifresini kim değiştirdi?
  • Bu ürünün fiyatını kim güncelledi?
  • Bu siparişi kim iptal etti?

Audit Log = Hesap verebilirlik (Accountability)

Kullanmazsak Ne Olur?

  • Güvenlik ihlali tespit edilemez
  • Veri tutarsızlığı kaynağı bulunamaz
  • Sistem kara kutuya dönüşür
  • Hukuki sorunlarda kanıt üretilemez

Ne Kaydederiz?

AlanAçıklama
entity_typeuser / order / payment
entity_id123
actionCREATE / UPDATE / DELETE
old_valueJSON (önceki veri)
new_valueJSON (yeni veri)
user_idişlemi yapan
ip_addressIP
created_atzaman

Örnek Audit Log

{
  "entity": "users",
  "entity_id": 5,
  "action": "UPDATE",
  "old_value": { "email": "a@mail.com" },
  "new_value": { "email": "b@mail.com" },
  "user_id": 12,
  "created_at": "2026-01-05 14:30"
}

Soft Delete + Audit Flow

User “Delete” tuşuna bastı
↓
Soft delete yapıldı (deleted_at set)
↓
Audit log yazıldı

Aralarındaki Fark

Soft DeleteAudit Log
Veri güvenliğiHesap verebilirlik
Mantıksal silmeDeğişim geçmişi
Geri alınabilirİzlenebilirlik

Best Practice

  • Soft delete ile veri kaybını önle
  • Audit log ile sistem davranışını kaydet
  • İkisini birlikte kullan