Veritabanı İşlemlerinde Çift Fazlı Commit’ın Aslında Atomik Olmadığını Biliyor muydunuz?

İki fiziksel veritabanında yürütülmesi gereken bir işlemde karşılaşılan zorluklardan biri, verilerin tutarlılığını korumaktır. Örneğin, bir veritabanındaki tablolarda yapılan ad değişikliklerinin, başka bir veritabanındaki ilgili tablolara da yansıtılması gerekebilir. Bu senaryoda, geliştiriciler genellikle basit bir çözüme başvurur: her iki veritabanında ayrı ayrı işlem başlatıp, işlemleri sırayla commit ederler. Hatta bu yaklaşıma güvenerek kodlarını da buna göre yazarlar. Ancak, bu yöntemin aslında ne kadar güvenli olduğunu merak ettiniz mi?

Farklı sistemlerdeki iki commit, tek bir atomik işlem değildir

Basit bir senaryo üzerinden gidelim: ilk veritabanında (dbA) bir işlem başlatılır, ardından ikinci veritabanında (dbB) başka bir işlem başlatılır. İşlemler sırayla commit edilir ve herhangi bir hata durumunda rollback mekanizması devreye girer. Bu yaklaşım, birçok geliştiriciye mantıklı ve güvenilir görünür. Ancak gerçek şu ki, her iki commit de ayrı bir "geri dönüşü olmayan nokta" oluşturur.

await using var txA = await dbA.Database.BeginTransactionAsync();
await using var txB = await dbB.Database.BeginTransactionAsync();

await DoWorkOnA(dbA);
await DoWorkOnB(dbB);

await txA.CommitAsync(); // İlk commit başarılı
// Burada bir pencere oluşur: ikinci commit henüz başlamamıştır.
await txB.CommitAsync(); // İkinci commit başarısız olursa ne olur?

Yukarıdaki kodda, ilk commit başarılı olurken, ikinci commit sırasında oluşan bir hata (örneğin, bağlantı kopması, veritabanı hatası, işlemcinin öldürülmesi) durumunda, ilk veritabanındaki değişiklik kalıcı hale gelir. İkinci veritabanındaki değişiklik ise hiç gerçekleşmez. Bu durumda, iki veritabanı arasındaki veri tutarlılığı bozulur ve bu dengesizlik, kod tarafından otomatik olarak düzeltilemez. Bu sorun, çift yazma problemi olarak adlandırılır ve çözümü, basit bir try-catch bloğu ile mümkün değildir.

"Hiç sorun yaşamadım" yanıltmacası

Bu yöntemi kullanan birçok geliştirici, nadiren sorun yaşadıkları için bu yaklaşımın güvenilir olduğunu düşünür. Ancak, sorunun nadir görülmesi, onun tehlikesiz olduğu anlamına gelmez. Aksine, nadir ve tahmin edilemeyen durumlar (örneğin, bir dağıtım sırasında, sistem çökmesi sırasında veya bellek yetersizliği nedeniyle) veri tutarsızlığının ortaya çıkmasına neden olabilir. Bu durumda, sistemlerinizin tutarlılığını korumak için daha sağlam çözümlere ihtiyacınız vardır.

Gerçekçi çözümler: tutarlılığı sağlamanın yolları

İki ayrı veritabanında yapılan ardışık commit işlemlerinin atomik olmadığını kabul etmek, sorunun çözümüne giden ilk adımdır. İşte bu sorunu ortadan kaldıracak veya en aza indirecek yaklaşımlar:

• Tek bir veritabanını kaynak olarak belirleyin: Ana veritabanınızda tüm değişiklikleri atomik olarak gerçekleştirin ve ikinci veritabanı için sadece bir yansıma (projection) olarak kullanın. Bu sayede, asıl veri kaynağı her zaman tutarlı kalırken, ikinci veritabanı asenkron olarak güncellenir. Bu yaklaşım, anında tutarlılık yerine, önemli olan verilerin garantili şekilde yazılmasını sağlar.

• Outbox desenini kullanın: Ana işlemle birlikte, bir "outbox" tablosuna yapılan değişiklikleri de aynı işlem içinde kaydedin. Ayrı bir süreç, outbox tablosundaki kayıtları okuyarak ikinci veritabanına uygular ve başarılı olana kadar yeniden denemeler yapar. Bu sayede, işlemin tamamlanma niyeti (intent) asla kaybolmaz, sadece gecikebilir. Bu desen, endüstri standardı olarak kabul edilmektedir.

• Farklılıkları tespit edin ve düzeltin: Eğer veritabanları arasındaki yapıyı değiştiremiyorsanız, en azından işlemin atomik olmadığını kabul edin. İkinci veritabanındaki yazma işlemini idempotent ve yeniden denenebilir hale getirin. Ardından, iki veritabanındaki verileri karşılaştıran ve farklılıkları düzeltmeye çalışan bir uyumluluk (reconciliation) süreci çalıştırın. Bu, sorunu tamamen çözmese de, yanlış bir garantiden daha iyi bir yaklaşımdır.

Temel yanılgıdan kurtulmak

Bu sorunun asıl çözümü, kod değişikliklerinde değil, zihniyet değişikliğindedir. İki ardışık commit işleminin "temelde atomik" olduğunu düşünmek, yaygın bir yanılgıdır. Oysa ki, iki ayrı sistemdeki bir yazma işlemi, artık veritabanı işlemlerinden çıkıp, dağıtık sistemler dünyasına girmişsiniz demektir. Bu dünyada, kullanılan araçlar, outbox desenleri, sagalar, idempotentlik ve uyumluluk mekanizmalarıdır — ikinci bir CommitAsync değil.

Gerçek şu ki, iki commit arasındaki pencere, sistemlerinizin tutarlılığını bozabilir ve bu pencereyi kapatmanın tek yolu, veritabanlarınızdaki işlemleri yeniden yapılandırmaktır. Eğer bunu yapamıyorsanız, en azından bu yöntemin "iyi yeter" değil, "atomik" olmadığını kabul edin. Dağıtık sistemlerdeki verilerin tutarlılığını sağlamak, basit bir try-catch bloğundan çok daha fazlasını gerektirir.