ACID Özellikleri: Her Projede Tamamen Şart mı?

Geçenlerde bir yan ürünümün finansal hesaplayıcılarının backend’ini yeniden yazarken, veritabanı işlemlerinde ACID özelliklerinin ne kadar zorunlu olduğunu tekrar düşündüm. Özellikle dağıtık sistem mimarileri ve yüksek ölçeklenebilirlik hedefleri devreye girdiğinde, ACID’in katı kuralları bazen bir engel gibi durabiliyor. Peki, gerçekten her projede tam ACID uyumluluğu şart mı? Yoksa bazı durumlarda bu özelliklerden ödün vermek, daha esnek ve performanslı çözümler sunabilir miyiz?

Yıllar içinde hem büyük bir üretim ERP’si geliştirirken, hem de kendi ufak projelerimde farklı veritabanı yaklaşımları denedim. Gördüm ki, “en iyi” çözüm diye bir şey yok; sadece o anki iş ihtiyaçlarına, bütçeye ve ekibin yetkinliğine en uygun trade-off’lar var. Bu yazıda, ACID’in her bir bileşenini kendi deneyimlerim üzerinden ele alıp, ne zaman sıkı sıkıya bağlı kalmak gerektiğini, ne zaman esneyebileceğimizi anlatacağım.

Atomicity ve İşlem Bütünlüğü: Geri Dönüş Olmayan Nokta

Atomicity, bir veritabanı işlemindeki tüm adımların ya tamamen başarılı olması ya da hiçbirinin olmaması prensibidir. Yani, ya hepsi gerçekleşir (commit edilir) ya da hiçbiri gerçekleşmez (rollback edilir). Benim için Atomicity, özellikle finansal işlemler gibi kritik noktalarda kesinlikle olmazsa olmaz. Bir bankanın iç platformunda bakiye transferi yaparken, paranın hem gönderen hesaptan düşüp hem de alıcı hesaba eklenmesi gerekiyor. Bu iki adımın arasındaki herhangi bir hata durumunda (ağ kesintisi, sunucu çökmesi), işlemin tamamının geri alınması, kimsenin para kaybetmemesi veya çifte harcama olmaması için hayati önem taşıyor.

Bir üretim ERP’sinde, bir siparişin sevkiyatı yapıldığında stoktan düşülmesi, sevk irsaliyesinin oluşturulması ve muhasebe kayıtlarının güncellenmesi gibi adımlar genellikle tek bir atomik işlem içinde ele alınır. Eğer stoktan düşme gerçekleşip, irsaliye oluşmadan sistem çökerse, ciddi bir tutarsızlık yaşanır. Benim tecrübemde, bu tür senaryoları yönetmek için PostgreSQL’in transaction mekanizmalarını sıkça kullandım. Aşağıdaki gibi basit bir SQL transaction’ı, Atomicity’nin en temel örneğidir:

BEGIN;

-- Stoktan ürün düş
UPDATE products SET stock_quantity = stock_quantity - 5
WHERE product_id = 123 AND stock_quantity >= 5;

-- Eğer stok yeterli değilse işlemi iptal et
IF NOT FOUND THEN
    RAISE EXCEPTION 'Yetersiz stok';
END IF;

-- Sipariş durumunu güncelle
UPDATE orders SET status = 'Shipped' WHERE order_id = 456;

-- Sevkiyat kaydı oluştur
INSERT INTO shipments (order_id, product_id, quantity, shipment_date)
VALUES (456, 123, 5, NOW());

COMMIT;

Bu örnekte, BEGIN ile başlayan ve COMMIT ile biten blok içindeki tüm işlemler ya başarılı olur ya da RAISE EXCEPTION durumunda ROLLBACK edilir. Eğer bu transaction’ın ortasında bir hata olursa, sistem otomatik olarak ROLLBACK yapar ve veritabanı, işlem başlamadan önceki tutarlı haline geri döner. Bu, benim için birçok kritik iş akışında vazgeçilmez bir güvenlik katmanı olmuştur.

Consistency ve İş Veri Modelleri: Veri Neden Tutarlı Kalmalı?

Consistency (Tutarlılık), bir transaction’ın veritabanını bir geçerli durumdan diğerine taşıması prensibidir. Bu, veritabanının önceden tanımlanmış tüm kurallara (constraints, trigger’lar, cascading rule’lar) uyması anlamına gelir. Yani, işlem tamamlandığında veritabanı şemasını ve iş kurallarını ihlal eden hiçbir durum kalmamalıdır. Örneğin, FOREIGN KEY kısıtlamaları, UNIQUE kısıtlamaları ve CHECK kısıtlamaları, veritabanı düzeyinde tutarlılığı sağlamanın temel yollarıdır.

Bir üretim ERP’sinde, üretim emri oluşturulurken, hammaddelerin stokta olup olmadığını kontrol eden ve eğer yeterli değilse uyarı veren bir iş kuralı vardır. Bu kural, sistemin tutarlılığını garanti eder. Eğer hammaddesiz bir üretim emri kaydedilebilirse, bu durum üretim planlamasını alt üst eder. Ben bu tür durumlarda, uygulama katmanında validasyon yapmanın yanı sıra, veritabanı katmanında da tutarlılık kısıtlamalarını kullanmayı tercih ediyorum. Bu, özellikle birden fazla uygulamanın aynı veritabanını kullandığı senaryolarda kritik.

-- Ürün tablosunda stok miktarının negatif olmamasını sağlayan CHECK constraint
ALTER TABLE products
ADD CONSTRAINT chk_stock_quantity CHECK (stock_quantity >= 0);

-- Sipariş kalemi tablosunda, ürün ID'sinin ürünler tablosunda mevcut olmasını sağlayan FOREIGN KEY constraint
ALTER TABLE order_items
ADD CONSTRAINT fk_product
FOREIGN KEY (product_id) REFERENCES products (product_id);

Bu kısıtlamalar, hatalı verinin sisteme girmesini engeller. Ancak Consistency, yalnızca veritabanı şemasıyla sınırlı değildir; aynı zamanda iş mantığı tutarlılığını da kapsar. Örneğin, bir kullanıcının kredi limiti varken yeni bir siparişin bu limiti aşmaması gibi. Bu tür kontrolleri genellikle uygulama katmanında yönetiyorum, ancak bazı durumlarda TRIGGER’lar veya STORED PROCEDURE’lar ile veritabanı seviyesine de indirebiliyorum.

Bazen dağıtık sistemlerde veya yüksek yazma yükü olan sistemlerde “eventual consistency” (nihai tutarlılık) kabul edilebilir bir trade-off olabilir. Örneğin, kendi yan ürünümdeki bir analitik panosunda, kullanıcı verilerinin anlık olarak güncel olması şart değil. Yeni bir kullanıcı kaydolduğunda, bu bilginin analitik sistemine ulaşması birkaç saniye veya dakika gecikebilir. Bu, sistemin genel performansını artırırken, işin kritik akışını etkilemez. Veriler anlık olmasa da kısa bir gecikmeyle nihayetinde tutarlı hale geliyordu. Burada önemli olan, hangi verinin ne kadar “taze” olması gerektiğine doğru karar vermek.

Isolation ve Eşzamanlılık Problemleri: Aynı Anda Farklı Gerçeklikler

Isolation (İzolasyon), eşzamanlı olarak çalışan işlemlerin birbirini etkilememesi prensibidir. Bir işlemin yaptığı değişiklikler, o işlem commit edilene kadar diğer işlemler tarafından görünmez olmalıdır. Bu, birden fazla kullanıcının veya sürecin aynı veriye aynı anda eriştiği durumlarda veritabanı tutarlılığını korumak için hayati öneme sahiptir. Veritabanları, bu izolasyon seviyesini yönetmek için farklı mekanizmalar sunar: Read Committed, Repeatable Read, Serializable gibi.

Benim için izolasyon seviyesi seçimi, performans ve veri tutarlılığı arasında hassas bir denge meselesidir. Örneğin, PostgreSQL’de varsayılan izolasyon seviyesi READ COMMITTED’dır. Bu seviye çoğu uygulama için yeterli olur ve iyi bir eşzamanlılık sağlar. Ancak, bir üretim ERP’sinde karmaşık bir raporlama işi yaparken, aynı raporu kısa aralıklarla çalıştırdığımda farklı sonuçlar alabiliyordum. Bunun nedeni, READ COMMITTED seviyesinde bir transaction içinde bile başka transaction’ların commit ettiği değişikliklerin görünür olmasıydı (non-repeatable read). Bu durumu çözmek için raporlama transaction’larını REPEATABLE READ seviyesinde çalıştırdım.

-- PostgreSQL'de belirli bir transaction için izolasyon seviyesini ayarlama
BEGIN;
SET TRANSACTION ISOLATION LEVEL REPEATABLE READ;

-- Raporlama sorguları
SELECT product_name, SUM(quantity)
FROM order_items oi
JOIN products p ON oi.product_id = p.product_id
WHERE order_date BETWEEN '2026-01-01' AND '2026-01-31'
GROUP BY product_name;

COMMIT;

Bu sayede, işlem boyunca okuduğum veriler sabit kalıyor ve raporun tutarlılığı sağlanıyordu. Ancak SERIALIZABLE gibi en yüksek izolasyon seviyeleri, eşzamanlılık üzerinde ciddi bir performans yükü getirebilir. SERIALIZABLE seviyesi, tüm transaction’ların sanki seri olarak (art arda) çalışıyormuş gibi davranmasını sağlar, bu da transaction’ların kilitlenme ve tekrar deneme (retry) olasılığını artırır. Çok yüksek yoğunluklu bir sistemde, bu seviyeyi kullanmak ciddi performans darboğazlarına yol açabilir.

Bir keresinde, bir müşteri projesinde, yoğun bir yazma işlemi sırasında SERIALIZABLE kullanmak zorunda kalmıştık. Orada, özellikle deadlock sorunları ve transaction’ların sürekli serialization failure hatası alıp tekrar denenmesi yüzünden sistemin throughput’u (işlem hacmi) inanılmaz düşmüştü. Bu durumda, optimistic locking veya eventual consistency gibi alternatif yaklaşımları değerlendirmek zorunda kaldık. Optimistic locking’de, veriyi okurken bir versiyon numarası veya timestamp alırız ve güncelleme yaparken bu versiyon numarasının değişip değişmediğini kontrol ederiz. Eğer değişmişse, işlemi tekrar deneriz. Bu, yüksek eşzamanlılık gerektiren sistemlerde daha esnek bir çözüm sunar.

Durability ve Felaket Senaryoları: Veri Kaybına Karşı Sigorta

Durability (Kalıcılık), bir transaction başarılı bir şekilde commit edildikten sonra, sistemde herhangi bir donanım veya yazılım hatası olsa bile o değişikliklerin kalıcı olacağını garanti eder. Yani, veritabanı sistemi çökerse bile, commit edilmiş veriler kaybolmaz. Bu özellik, benim için veritabanı yönetimindeki en kritik unsurlardan biridir. Veri kaybı, bir işletme için telafisi zor, hatta imkansız sonuçlar doğurabilir.

PostgreSQL gibi ilişkisel veritabanları, bu kalıcılığı sağlamak için Write-Ahead Logging (WAL) mekanizmasını kullanır. Herhangi bir veri değişikliği, önce diske yazılan WAL dosyalarına kaydedilir ve daha sonra ana veri dosyalarına uygulanır. Sistem aniden çökerse, yeniden başlatıldığında WAL kayıtları kullanılarak veritabanı, çökme anından önceki son tutarlı durumuna geri getirilir.

Birkaç yıl önce, kendi sunucumda bir power outage (elektrik kesintisi) yaşadım. Sunucu aniden kapandı. Yeniden başlattığımda, PostgreSQL otomatik olarak WAL’leri kullanarak veritabanını kurtardı ve en son commit edilmiş tüm veriler yerindeydi. Bu tecrübe, fsync ve full_page_writes gibi PostgreSQL ayarlarının ne kadar önemli olduğunu bir kez daha gösterdi. fsync = on ayarı, WAL kayıtlarının gerçekten diske yazılmasını garanti eder ve veri kaybını önler. Eğer bu ayar kapalı olsaydı, güç kesintisi durumunda veri kaybı yaşama ihtimalim çok daha yüksek olurdu.

Durability’yi artırmak için tek başına bir sunucuya güvenmek yetmez. Replikasyon (replication) stratejileri de bu noktada devreye girer. Physical replication (Stream Replication) ve Logical replication gibi yöntemlerle veritabanının kopyalarını farklı sunucularda tutarak felaket durumunda hızlı bir şekilde kurtarma sağlayabiliyorum. Bir üretim ERP’sinde, synchronous replication (senkron replikasyon) kullanarak her commit’in en az iki sunucuda kalıcı olmasını sağladık. Bu, birincil veritabanı sunucusu çökerse bile veri kaybı riskini minimize ediyordu. Ancak synchronous replication, yazma performansı üzerinde bir miktar ek yük getirir, bu da bir trade-off’tur.

ACID’den Ödün Vermek: CAP Teoremi ve Dağıtık Sistemler

ACID’in dört özelliğinin tamamını her zaman sağlamak, özellikle dağıtık sistemlerde ve yüksek ölçeklenebilirlik hedeflendiğinde zorlayıcı olabilir. İşte burada CAP Teoremi devreye giriyor. CAP Teoremi, dağıtık bir sistemin aynı anda Consistency (Tutarlılık), Availability (Erişilebilirlik) ve Partition Tolerance (Bölümleme Hoşgörüsü) özelliklerinden en fazla ikisini sağlayabileceğini söyler. Dağıtık sistemlerde Partition Tolerance’tan vazgeçmek pratik olarak imkansız olduğu için, genellikle Consistency veya Availability’den ödün vermek zorunda kalırız.

Benim pratiğimde, bazı durumlarda bilinçli olarak ACID’den ödün verdim. Örneğin, bir yan ürünümün Android tarafında geliştirdiğim spam engelleyici uygulamasının backend’i için eventual consistency’ye sahip bir NoSQL veritabanı kullandım. Buradaki veriler (spam numaraları, kullanıcı raporları), anlık olarak tüm sunucularda tutarlı olmak zorunda değildi. Bir raporun sisteme girip diğer sunuculara yayılması birkaç saniye gecikebilir, bu da uygulamanın işlevselliğini etkilemezdi. Bu sayede, çok daha yüksek yazma performansı ve erişilebilirlik elde ettim.

Bir üretim firmasının ERP’sinde, üretim planlama motoru için AI ile planlama yaparken, anlık stok ve üretim durumu verileriyle çalışıyorduk. Ancak, AI modelinin sonuçlarını kaydederken, bu sonuçların anında tüm raporlarda görünmesi şart değildi. Planlama sonuçları sisteme kaydedildikten sonra, ilgili dashboard’ların ve raporların güncellenmesi için asenkron bir süreç tetikledik. Bu sayede, planlama motorunun performansı düşmeden, kullanıcılar nihai olarak tutarlı verilere erişebiliyordu. Bu, Consistency’den biraz ödün vererek Availability ve performans kazandığımız bir Architectural Decision örneğiydi.

Gerçek Dünya Uygulamaları ve Benim Yaklaşımım

Saha tecrübemde gördüm ki, ACID özelliklerine olan yaklaşım, projenin doğasına ve iş gereksinimlerine göre büyük ölçüde değişiyor. Mutlak “her projede şart” diye bir durum söz konusu değil. Benim için önemli olan, her bir ACID bileşeninin sağladığı faydayı ve ondan ödün vermenin getireceği riskleri net bir şekilde anlamak ve bu dengeyi doğru kurmak.

Ne Zaman Tam ACID Kullanıyorum:

• Finansal İşlemler: Banka transferleri, faturalandırma, ödeme sistemleri. Burada Atomicity, Consistency ve Durability vazgeçilmez.
• Stok ve Envanter Yönetimi: Ürün hareketleri, sipariş karşılama, üretim giriş/çıkışları. Atomicity ve Consistency, envanterin doğruluğu için kritik.
• Kullanıcı Kimlik Doğrulama ve Yetkilendirme: Kullanıcı hesapları, roller ve izinler. Verilerin doğru ve kalıcı olması güvenlik açısından şart.
• ERP Çekirdek İş Akışları: Siparişten sevkiyata, üretimden muhasebeye kadar olan temel süreçler. Burada genellikle PostgreSQL’in READ COMMITTED veya REPEATABLE READ izolasyon seviyelerini kullanıyorum, Durability için WAL ve replikasyonu ihmal etmiyorum.

Ne Zaman ACID’den Ödün Veriyorum (veya Esniyorum):

• Loglama ve Denetim Kayıtları: Yoğun yazma yükü olan log sistemleri. Burada verinin anlık olarak %100 tutarlı olması yerine, yüksek yazma hızı ve erişilebilirlik daha önemli. Eventual consistency benim için kabul edilebilir.
• Analitik ve Raporlama Verileri: Anlık dashboard’lar veya istatistikler. Verilerin birkaç dakikalık gecikmeyle güncellenmesi sorun teşkil etmez.
• Önbellekleme Katmanları: Redis gibi sistemlerde, verinin kalıcılığı ve tam tutarlılığı ikincil plandadır. Önemli olan hızlı erişim ve yüksek erişilebilirlik. Redis’in eviction policy seçimlerinde de OOM risklerini yönetmek için bu prensibi göz önünde bulunduruyorum.
• Sosyal Medya Akışları veya Gerçek Zamanlı Bildirimler: Bir bildirimin anında tüm kullanıcılara ulaşmaması veya bir gönderinin birkaç saniye gecikmeli görünmesi genellikle kabul edilebilir.

Bence yazılım mimarisi, çoğu zaman sadece kod yazmaktan ibaret değil; organizasyonel akışları ve işin gerçek ihtiyaçlarını anlamakla ilgili. Bir ERP’de, satın alma sürecinin nasıl işlediğini, tedarik zincirinin nasıl entegre olduğunu anlamadan “en iyi veritabanı mimarisini” kurmak mümkün değil. ACID özelliklerini bu büyük resmin bir parçası olarak değerlendiriyorum. Nerede sıkı tutmam gerektiğini, nerede esneyebileceğimi, projenin risklerini ve fırsatlarını değerlendirerek belirliyorum. Aynı trade-off mantığı veritabanı dışında da geçerli: çoğu zaman daha az kaynak tüketimi ve daha esnek bir iş akışı için anlık tepkiden ödün vermek gerekir.

Sonuç olarak, ACID bir dini öğreti değil, bir araç setidir. Her aracın belirli bir kullanım alanı ve belirli durumlarda daha iyi çalıştığı senaryolar vardır. Önemli olan, bu araçları ne zaman ve nasıl kullanacağımızı bilmek, ve bu kararları somut iş gereksinimlerine ve teknik trade-off’lara dayanarak vermek. Benim net pozisyonum: Kritik iş süreçleri ve finansal veriler için tam ACID uyumluluğu şarttır. Ancak, performans veya ölçeklenebilirlik hedefleri ön plana çıktığında ve işin doğası izin verdiğinde, kontrollü bir şekilde ACID özelliklerinden ödün vermek, daha esnek ve etkili çözümler sunabilir.