ACID Garantileri Güvenilir İşlemsel Sistemleri Nasıl Şekillendirir

ACID Garantilerinin Güvenilir İşlemsel Sistemleri Nasıl Şekillendirdiği

Market alışverişi ödemeniz, uçuş rezervasyonu veya hesaplar arasında para transfer ederken sonucu net bekleriz: ya başarılı olur ya da olmaz. Veritabanları da aynı kesinliği sağlamaya çalışır—aynı anda birçok kişi sistemi kullanırken, sunucular çökerken veya ağda kesinti olunca bile.

Basitçe bir işlem nedir

İşlem, veritabanının tek bir “paket” olarak ele aldığı bir iş birimidir. Birden fazla adım içerebilir—envanteri azaltma, sipariş kaydı oluşturma, kartı tahsil etme ve makbuz yazma gibi—ama tek bir uyumlu eylem gibi davranması beklenir.

Herhangi bir adım başarısız olursa, sistem yarım kalmış bir iş bırakmak yerine güvenli bir noktaya geri sarılmalıdır.

Kısmi güncellemeler neden gerçek iş problemleri yaratır

Kısmi güncellemeler sadece teknik aksaklıklar değildir; müşteri destek biletlerine ve finansal riske dönüşür. Örneğin:

• Ödeme alınır ama sipariş oluşturulmaz—müşteri ücretlendirilir ama onay yoktur.
• Sipariş oluşturulur ama envanter azaltılmaz—siteler aşırı satış yapar ve iptal eder.
• Banka transferi bir hesaptan düşer ama diğer hesaba geçmez—bakiye tutarsızlıkları oluşur.

Bu hataların izini sürmek zordur çünkü her şey “çoğunlukla doğru” görünür, ama rakamlar tutmaz.

ACID bir özellik değil, bir garanti setidir

ACID, birçok veritabanının işlemler için sağlayabileceği dört garantiyi kısaca ifade eder:

• Atomiklik: hepsi ya da hiçbiri
• Tutarlılık: veri geçerli kurallar içinde kalır
• İzolasyon: eşzamanlı işlemler güvensiz şekilde birbirine karışmaz
• Kalıcılık: commit edilen değişiklikler kalıcı olur

Bu, belirli bir veritabanı markası veya tek bir açıp kapatılacak özellik değildir; davranış hakkında bir sözdür.

Faydalar—ve beklemeniz gereken maliyetler

Daha güçlü garantiler genellikle veritabanının daha fazla iş yapmasını gerektirir: ekstra koordinasyon, kilitler için bekleme, versiyon takibi ve günlük yazma. Bu, yüksek yük altında verimliliği düşürebilir veya gecikmeyi artırabilir. Ama amaç her zaman "her zaman maksimum ACID" değil; iş risklerinizle uyumlu garantileri seçmektir.

Atomiklik: Hepsi veya Hiçbir Etki

Atomiklik, bir işlemin tek bir iş birimi olarak ele alınması demektir: ya tamamen biter ya da hiçbir etkisi olmaz. Veritabanında "yarım güncelleme" görünmez.

Basit bir banka transferi örneği

Alice'ten Bob'a 50$ aktarımı düşünün. Arkada genellikle en az iki değişiklik olur:

• Alice'in bakiyesinden 50$ düşmek
• Bob'un bakiyesine 50$ eklemek

Atomiklik ile bu iki değişiklik beraber başarılır ya da beraber başarısız olur. Sistem her ikisini güvenli şekilde yapamıyorsa, hiçbiri yapılmamalıdır. Bu, Alice ücretlendirilip Bob'un parayı almaması gibi kabus senaryolarını önler.

Commit vs. rollback (basit bir benzetme)

Veritabanları işlemler için iki çıkış sunar:

• Commit: “Tüm adımlar başarılı; sonuçları resmileştir.”
• Rollback: “Bir şey yolunda gitmedi; bu işlemdeki her şeyi geri al.”

Faydalı bir zihinsel model "taslak vs. yayınla"dır. İşlem çalışırken değişiklikler geçicidir. Sadece commit ile yayınlanırlar.

İşlem ortasında neler ters gidebilir?

Atomiklik önemlidir çünkü hatalar normaldir:

• Uygulama çökmesi: servis bir tabloyu güncelledikten sonra diğerini güncellemeden durabilir.
• Ağ kopması: uygulama veritabanına ulaşamaz veya istemci "başarılı" yanıtını almaz.
• Elektrik kesintisi: veritabanı sunucusu beklenmedik şekilde durur.

Eğer bunlardan biri commit tamamlanmadan olursa, atomiklik veritabanının geri almasını sağlayarak kısmi çalışmaların kalıcı hâle gelmesini engeller.

Atomiklik artı idempotentlik ve yeniden denemeler

Atomiklik veritabanı durumunu korur, ama uygulamanız belirsizlikle başa çıkmak zorundadır—özellikle ağ kesintileri komitin olup olmadığını belirsiz kıldığında.

Pratik tamamlayıcılar:

• Yeniden denemeler: yanıt alamadığınızda isteği tekrarlayın.
• İdempotentlik: aynı isteği tekrar etmenin güvenli olmasını sağlayın (ör. "transfer #123" en fazla bir kez uygulanır).

Atomik işlemler ve idempotent yeniden denemeler birlikte hem kısmi güncellemeleri hem de kazara çift ücretlendirmeyi önlemeye yardımcı olur.

Tutarlılık: Veriyi Geçerli Kurallar İçinde Tutmak

ACID'teki tutarlılık, "veri makul görünsün" ya da "tüm replikalar eşleşsin" anlamına gelmez. Her işlem, veritabanını sizin tanımladığınız kuralların izin verdiği bir geçerli durumdan diğerine taşımalıdır.

Tutarlılık sizin seçtiğiniz kurallarla tanımlanır

Veritabanı, "geçerli"nin ne olduğunu tanımlayan açık kısıtlar, tetikleyiciler ve invariantlara göre tutarlılığı sağlayabilir. ACID bu kuralları icat etmez; işlemler sırasında bunları uygular.

Yaygın örnekler:

• Foreign key'ler: her order.customer_id mevcut bir müşteriye işaret etmelidir.
• Unique constraint'ler: iki kullanıcı aynı e-postayı paylaşamaz.
• Check constraint / invariantlar: hesap bakiyesi sıfırın altına düşemez veya ürün miktarı negatif olamaz.

Bu kurallar varsa, veritabanı bunları ihlal edecek herhangi bir işlemi reddeder—böylece "yarım-geçerli" veri oluşmaz.

Uygulama doğrulaması vs. veritabanı kısıtları

Uygulama düzeyinde doğrulama önemli ama tek başına yeterli değildir.

• Uygulama doğrulaması kullanıcı deneyimini geliştirir (açık hata mesajları, erken geri bildirim) ve karmaşık iş kurallarını uygulayabilir.
• Veritabanı kısıtları ise aynı tabloları birçok hizmetin, arka plan işlerinin, içe aktarmaların veya yönetici araçlarının yazdığı durumlarda nihai bekçi rolündedir.

Klasik bir hata modu, uygulamada bir şeyi kontrol edip ("e-posta müsait"), sonra satırı eklemektir. Eşzamanlılık altında iki istek aynı anda kontrolü geçebilir. Veritabanındaki unique constraint sadece bir insert'in başarılı olmasını garanti eder.

Tutarlılık pratikte nasıl görünür

"Negatif bakiye olamaz" kuralını bir kısıt olarak kodlarsanız (veya tek bir işlem içinde güvenilir şekilde uygularsanız), bir transfer hesabı eksiye düşürecekse tüm transferin başarısız olması gerekir. Eğer bu kuralı hiçbir yerde kodlamazsanız, ACID bunu koruyamaz—çünkü korunacak bir kural yoktur.

Tutarlılık nihayetinde açık olmaktır: kuralları tanımlayın, sonra işlemlerin bu kuralların asla bozulmamasını sağlayın.

İzolasyon: Eşzamanlılık Altında Güvenli Çalışma

İzolasyon, işlemlerin birbirinin üzerine basmasını önler. Bir işlem sürerken diğer işlemler yarım değişiklikleri görmemeli veya yanlışlıkla üstüne yazmamalıdır. Amaç basit: birçok kullanıcı aynı anda aktif olsa bile her işlem sanki yalnız çalışıyormuş gibi davranmalıdır.

Eşzamanlılık bunu neden zorlaştırır

Gerçek sistemler yoğundur: müşteriler sipariş verir, destek ajanları profilleri günceller, arka plan işleri ödemeleri uzlaştırır—hepsi aynı anda. Bu eylemler çakışır ve genellikle aynı satırlara dokunurlar (hesap bakiyesi, envanter adedi, rezervasyon slotu).

İzolasyon yoksa zamanlama iş mantığınızın bir parçası olur. "Envanteri azalt" güncellemesi başka bir ödeme işlemiyle yarışabilir veya bir rapor veriyi değişim ortasındayken okuyup asla var olmamış sayıları gösterebilir.

İzolasyon genelde yapılandırılabilir

Tam anlamıyla "yalnızmış gibi davran" izolasyon pahalı olabilir. Throughput'u düşürebilir, beklemeleri artırabilir (kilitler) veya işlemlerin yeniden denenmesine yol açabilir. Oysa birçok iş akışı en katı korumaya ihtiyaç duymaz—örneğin dünün analitiğini okumak küçük tutarsızlıklara katlanabilir.

Bu yüzden veritabanları yapılandırılabilir izolasyon seviyeleri sunar: daha iyi performans ve daha az çatışma karşılığında ne kadar eşzamanlılık riskini kabul edeceğinizi seçersiniz.

Hangi anormallikleri izolasyon önler (veya izin verir)

İzolasyon çok zayıfsa aşağıdaki klasik anormalliklerle karşılaşırsınız:

• Dirty reads: başka bir işlem commit etmemiş değişiklikleri okumak
• Lost updates: iki işlem birbirinin üzerine yazarak bir set değişikliğin kaybolmasına neden olur
• Phantom reads: aynı sorgu tekrarlandığında başka işlem tarafından eklenen veya silinen satırlar görünür

Bu başarısızlık modlarını anlamak, işinizin beklentileriyle uyumlu bir izolasyon seviyesi seçmenizi kolaylaştırır.

İzolasyonun Önlediği Yaygın Anormallikler (veya İzin Verdikleri)

İzolasyon, işleminiz çalışırken başka işlemlerin sizi hangi değişikliklerle "görmesine" izin verildiğini belirler. Zayıf izolasyon bir iş yükü için uygunsuzsa anormalliklerle karşılaşırsınız—kullanıcıları şaşırtan davranışlar teknik olarak mümkün hale gelir.

Okuma anormallikleri

Dirty read: henüz commit edilmemiş bir işlemin yazdığı veriyi okumaktır.

Senaryo: Alex 500$ transfer ederken bakiye geçici olarak 200$ olur ve siz o 200$'ı okursunuz; sonra Alex'in transferi başarısız olup rollback olursa siz yanlış düşük bakiyeyi görmüş olursunuz.

Kullanıcı sonucu: müşteri yanlış düşük bakiye görür, sahtecilik kuralı yanlış çalışır veya destek yanlış bilgi verir.

Non-repeatable read: aynı satırı iki kere okuduğunuzda aradaki commit yüzünden farklı değerler alırsınız.

Senaryo: Bir sipariş toplamını ($49.00) yüklersiniz, sonra bir yenilemede $54.00 görürsünüz çünkü bir indirim satırı kaldırılmıştır.

Kullanıcı sonucu: "Toplamım kontrol ederken değişti" hissi, güvensizlik veya sepetten vazgeçme.

Phantom read: non-repeatable read'e benzer ama satır seti ile ilgilidir: başka bir işlem eşleşen kayıtlar eklediği veya sildiği için ikinci sorgu farklı satırlar döndürür.

Senaryo: Otel araması "3 oda mevcut" gösterir, rezervasyon sırasında sistem yeniden kontrol ettiğinde hiç oda kalmamıştır çünkü yeni rezervasyonlar eklenmiştir.

Kullanıcı sonucu: çift rezervasyon denemeleri, tutarsız uygunluk ekranları veya aşırı satış.

Yazma anormallikleri (gerçek dünya hataları)

Lost update: iki işlem aynı değeri okur ve ikisi de güncelleme yazar; son yazan öncekinin değişikliğini siler.

Senaryo: İki yönetici aynı ürün fiyatını düzenler. İkisi de $10'dan başlar; biri $12 kaydeder, diğeri daha sonra $11 kaydeder.

Kullanıcı sonucu: birinin değişikliği kaybolur; raporlar yanlış çıkar.

Write skew: iki işlem ayrı ayrı geçerli bir değişiklik yapar ama birlikte bir kuralı bozar.

Senaryo: Kural: "En az bir nöbetçi doktor görevde olmalı." İki doktor birbirinin hâlâ görevde olduğunu kontrol edip aynı anda devre dışı kalmayı işaretler.

Kullanıcı sonucu: her biri kendi kontrolünü geçerken sonuçta görevde kimse kalmaz.

Neden her zaman en katı izolasyonu kullanmıyoruz?

Daha güçlü izolasyon anormallikleri azaltır ama beklemeleri, yeniden denemeleri ve maliyetleri artırabilir. Birçok sistem okuma ağırlıklı analitik işler için daha zayıf izolasyon seçerken, para transferi, rezervasyon gibi doğruluk açısından kritik akışlar için daha katı ayarlar kullanır.

İzolasyon Seviyeleri: Doğru Güvenlik Ayarını Seçmek

İzolasyon, işleminiz diğer işlemler sürerken neyi "görebilir" sorusunun cevabıdır. Veritabanları bunu izolasyon seviyeleri olarak sunar: daha yüksek seviye şaşırtıcı davranışları azaltır ama maliyeti olabilir.

Yaygın izolasyon seviyeleri

• Read Uncommitted: Başkalarının commit etmediği değişiklikleri okuyabilirsiniz ("kirli okumalar"). Neredeyse hiçbir şey engellenmez.
• Read Committed: Yalnızca commit edilmiş veriyi okursunuz; böylece kirli okumalar engellenir. Ama aynı sorguyu iki kez çalıştırırsanız başkası arada commit yaptığı için farklı sonuç görebilirsiniz ("non-repeatable read").
• Repeatable Read: Daha önce okuduğunuz okumalar işlem süresince sabit kalır, yani non-repeatable read'ler genelde engellenir. Motorun davranışına bağlı olarak hâlâ “phantom” görebilirsiniz veya görmeyebilirsiniz.
• Serializable: İşlemler sanki tek tek çalışıyormuş gibi davranır. Bu en güçlü ayardır; genellikle kirli okumaları, non-repeatable read'leri ve phantom'ları engeller ve birçok ince yazma anomalisini azaltır.

Seviye seçimi: throughput vs. doğruluk

Ekipler genellikle kullanıcıya yönelik uygulamalar için Read Committed'i varsayılan olarak seçer: iyi performans ve "kirli okumaların olmaması" beklentilerle uyumludur.

Repeatable Read işlem içinde sabit sonuçlara ihtiyaç duyduğunuzda (ör. bir fatura oluştururken) tercih edilir. Serializable ise doğruluğun eşzamanlılıktan daha önemli olduğu durumlar içindir (ör. envanterin asla aşılmaması).

Read Uncommitted OLTP sistemlerde nadirdir; bazen izleme veya yaklaşık raporlama için kabul edilebilir yanlış okumalar tolere ediliyorsa kullanılır.

Önemli uyarı: davranış motorlara göre değişir

İsimler standart olsa da tam garantiler veritabanı motoruna göre farklılık gösterebilir (hatta bazen konfigürasyona göre değişir). İlgili anormallikleri işiniz için test edin ve dokumentasyonu doğrulayın.

Kalıcılık: Commitlerin Kalıcı Olmasını Sağlamak

Kalıcılık, bir işlem commit edildiğinde sonuçlarının bir çöküş—güç kaybı, süreç yeniden başlatma veya ani makine yeniden başlaması—sonrasında bile korunacağını ifade eder. Uygulamanız bir müşteriye "ödeme başarılı" diyorsa, kalıcılık veritabanının bu sonucu unutmayacağını vaat etmesidir.

Veritabanları commitleri çöküşlerden nasıl korur

Çoğu ilişkisel veritabanı kalıcılığı write-ahead logging (WAL) ile sağlar. Yüksek düzeyde, veritabanı commit kabul etmeden önce değişikliklerin dizisel bir "makbuz"unu diske yazar. Çökme halinde, veritabanı başlatıldığında bu günlüğü oynatarak commit edilmiş değişiklikleri geri yükleyebilir.

Kurtarma süresini makul tutmak için veritabanları ayrıca checkpoint oluşturur. Checkpoint, veritabanının yeterli son değişikliği ana veri dosyalarına yazdığından emin olduğu bir andır, böylece kurtarma sonsuz miktarda günlük geçmişi oynatmak zorunda kalmaz.

Kalıcılık depolama ve konfigürasyona bağlıdır

Kalıcılık tek bir açık/kapalı düğmesi değildir; veritabanının veriyi kalıcı depolamaya ne kadar agresif zorladığına bağlıdır.

• Senkron ayarlarda veritabanı commit onaylamadan önce günlüğün diske flush edilmesini bekler (çoğunlukla OS seviyesinde fsync). Bu daha güvenlidir ama gecikme ekleyebilir.
• Asenkron ayarlarda veritabanı commit onayını günlüğün tamamen kalıcı depolamaya yazılmasını beklemeden verebilir. Performans artar ama çöküşte en son "commit edilmiş" işlemler kaybolabilir.

Altyapı da önemlidir: SSD'ler, yazma önbellekli RAID denetleyicileri ve bulut hacimleri başarısızlık altında farklı davranabilir.

Yedekleme ve replikasyon ilişkili ama farklıdır

Yedekleme ve replikasyon kurtarmaya veya kesinti süresini azaltmaya yardımcı olur ama kalıcılığın kendisi değildir. Bir işlem birincilde kalıcı olsa bile replikaya henüz ulaşmamış olabilir; yedekler ise genellikle anlık görüntülerdir, commit bazlı garanti değildir.

Veritabanları ACID'i İçeriden Nasıl Uygular

BEGIN deyip sonra COMMIT ettiğinizde veritabanı birçok parçayı koordine eder: kim hangi satırları okuyabilir, kim güncelleyebilir ve aynı kaydı değiştirmek isteyen iki kişi olursa ne olur.

Pessimist vs. optimist eşzamanlılık kontrolü

Çatışmaları ele almanın temel bir seçimi vardır:

• Pessimist kilitleme çatışmaların sık olduğunu varsayar. Bir işlem bir satırı güncellediğinde veritabanı onu kilitler, diğer işlemler beklemelidir. Bu birçok anomalinin önüne geçer ama bloklamaya neden olabilir.
• Optimizm çatışmaların nadir olduğunu varsayar. İşlemler daha az engelleme ile ilerler ve veritabanı commit zamanında çatışmaları tespit eder ve bir işlemi reddedip yeniden denenmesi için geri döndürebilir.

Birçok sistem iş yükü ve izolasyon seviyesine göre her iki yaklaşımı harmanlar.

MVCC: okuyucular yazıcıları engellemez

Modern veritabanları genellikle MVCC (Çok-Sürümlü Eşzamanlılık Kontrolü) kullanır: veritabanı sadece bir satırın tek kopyasını tutmak yerine birden çok sürüm tutar.

• Okuyucular kilit beklemeden tutarlı bir anlık görüntü görebilir.
• Yazıcılar okuma sürümleri devam ederken yeni bir sürüm oluşturabilir.

Bu, bazı veritabanlarının çok sayıda okuma ve yazmayı daha az bloklamayla yönetebilmesinin önemli nedenidir—ama yazma/yazma çatışmaları yine çözülmelidir.

Deadlock'lar: beklemenin döngü oluşturması

Kilitler deadlock'lara yol açabilir: İşlem A, B'nin tuttuğu kilidi beklerken B de A'nın tuttuğu kilidi bekleyebilir. Veritabanları genelde döngüyü tespit edip bir işlemi sonlandırır ("deadlock victim"), uygulamaya hata döner ve uygulama yeniden denemelidir.

ACID uygulamada sürtünme yaratıyorsa belirtiler

ACID uygulanması sürtünme yaratıyorsa genellikle şunları görürsünüz:

• Zirve kullanımda artan kilit beklemeleri
• Zaman aşımı (uzun bekleme sonrası sorguların hataya düşmesi)
• İçerme noktaları (sürekli güncellenen birkaç satır/tablo; ör. sayaçlar veya "son görülme" alanları)

Bu semptomlar genellikle işlem boyutunu, indekslemeyi veya hangi izolasyon/kilit stratejisinin uygun olduğunu yeniden gözden geçirmenin zamanı olduğunu gösterir.

ACID Tasarım Kararlarını Nasıl Etkiler

ACID garantileri sadece veritabanı teorisi değildir—API'lerinizi, arka plan işlerinizi ve hatta kullanıcı arayüzü akışlarınızı nasıl tasarladığınızı etkiler. Temel fikir basit: hangi adımların birlikte başarılı olması gerektiğine karar verin ve yalnızca o adımları bir işlem içinde sarın.

"Bir iş değişikliği" etrafında API tasarlamak

İyi bir işlemsel API genellikle bir iş eylemine karşılık gelir; birden fazla tabloyu etkiliyor olsa bile. Örneğin /checkout işlemi bir sipariş oluşturabilir, envanteri rezerve edebilir ve bir ödeme niyeti kaydedebilir. Bu veritabanı yazmaları genellikle tek bir işlemde olmalıdır ki hepsi birlikte commit olsun ya da hiçbiri.

Yaygın bir desen:

• İşlem açmadan önce giriş doğrulaması yapın.
• İşlemi açın.
• Gerekli en az okuma/yazmayı yapın.
• Commit edin.

Bu, atomiklik ve tutarlılığı korurken yavaş, kırılgan işlemlerden kaçınır.

İsteklerde, hizmetlerde ve işlerde işlem sınırları

İşlem sınırlarını nerede koyacağınız "bir iş birimi"nin ne anlama geldiğine bağlıdır:

• Kullanıcı istekleri: İşlemleri kısa tutun—ideal olarak birkaç sorgu. Görüntü render ederken veya harici yanıt beklerken kilit tutmayın.
• Arka plan işler: Her iş denemesini bir iş birimi olarak kabul edin. Bir iş 10.000 kayıt işliyorsa, güvenli yeniden başlatma için toplu commit'ler yapın.
• Servis sınırları: İşlemi bir servisin veritabanı içinde tutmayı tercih edin. Servisler arası işlem sınırlarını geçmek genellikle farklı yaklaşımlar (ör. outbox) gerektirir, çünkü tek bir ACID işlemi birden çok veritabanını kolayca kapsayamaz.

Hata yönetimi: rollback, yeniden deneme ve güvenli yeniden oynatma

ACID yardımcı olur ama uygulamanız yine de hataları doğru ele almalıdır:

• Hata durumunda rollback: Herhangi bir adım başarısız olursa işlemi iptal edin ki kısmi güncellemeler sızmasın.
• Geçici hatalarda yeniden deneme: Seri hale getirme hataları ve deadlock'lar eşzamanlılık altında normaldir. Tüm işlemi yeniden denemek genelde doğru çözümdür.
• İşlemleri idempotent yapın: Bir istek tekrar edilirse (istemci veya iş çalıştırıcı tarafından), çift ücretlendirme veya çift gönderim olmadan güvenli şekilde yeniden oynatılabilmelidir—idempotentlik anahtarları ve unique constraint'ler kullanın.

Yaygın anti-patternler

Uzun işlemler, işlem içinde harici API çağrıları ve kullanıcı düşünme süresini işlem içinde bekletme (ör. "sepet satırını kilitle, kullanıcı onaylasın") gibi uygulamalardan kaçının. Bunlar içeriği artırır ve izolasyon çatışmalarını çok daha olası kılar.

Araçların nasıl yardımcı olabileceği (temeli değiştirmeden)

Hızlıca işlemsel bir sistem kuruyorsanız en büyük risk genellikle "ACID'i bilmemek" değil, bir iş eylemini birden çok uç noktaya, işe veya tabloya dağınık şekilde yaymak ve işlem sınırlarını belirsiz bırakmaktır.

Koder.ai gibi platformlar ACID etrafında tasarlarken hız kazandırabilir: örneğin bir iş akışını ("envanter rezervasyonu ve ödeme niyeti ile checkout") plan odaklı bir sohbetle tarif edebilir, React UI ile Go + PostgreSQL arka ucunu üretebilir ve şema veya işlem sınırı değişikliklerini anlık görüntü ve geri alma ile yineleyebilirsiniz. Veritabanı garantileri hâlâ uygulanır; değer doğru tasarımdan çalışan bir uygulamaya geçiş hızındadır.

Dağıtık ve Çok Hizmetli Sistemlerde ACID

Tek bir veritabanı genellikle bir işlem sınırı içinde ACID garantilerini sağlayabilir. İşleri birden çok hizmete (ve genellikle birden çok veritabanına) yaydığınızda aynı garantileri korumak zorlaşır—ve bunları korumak pahalılaşır.

Tutarlılık vs. kullanılabilirlik: üretimde hissettiğiniz takas

Sıkı tutarlılık, her okumanın "en son commit edilmiş gerçekliği" görmesi demektir. Yüksek kullanılabilirlik ise parçalar yavaş veya erişilemez olsa bile sistemin yanıt vermeye devam etmesidir.

Çok hizmetli bir yapıda geçici ağ problemi sizi bir seçim yapmaya zorlayabilir: tüm katılımcılar anlaşana kadar istekleri bloklamak veya reddetmek (daha tutarlı, daha az kullanılabilir) ya da hizmetlerin kısa süreli olarak uyumsuz olmasını kabul etmek (daha kullanılabilir, daha az tutarlı). Hiçbiri her zaman doğru değildir—işinizin hangi hataları tolere edebileceğine bağlıdır.

Dağıtık işlemler neden zordur

Dağıtık işlemler, tam kontrolünüzde olmayan sınırlar arasında koordinasyon gerektirir: ağ gecikmeleri, yeniden denemeler, zaman aşımı, servis çökmeleri ve kısmi hatalar. Tüm servisler düzgün olsa bile ağ belirsizlik yaratabilir: ödeme servisi commit etti ama sipariş servisi onayı hiç almadı mı? Güvenli çözüm için iki aşamalı commit gibi koordinasyon protokolleri kullanılır; bunlar yavaş olabilir, arıza durumunda kullanılabilirliği azaltabilir ve işletme karmaşıklığını artırır.

"Tek büyük işlem" yerine pratik desenler

Sagas: Bir iş akışını adımlara böler; her adım yerel olarak commit edilir. Daha sonra bir adım başarısız olursa önceki adımlar telafi edici işlemlerle geri alınır (ör. ücreti iade etme).

Outbox/inbox: Olay yayınlama ve tüketmeyi güvenilir kılar. Bir servis iş verisini ve "yayınlanacak olay" kaydını aynı yerel işlem içinde (outbox) yazar. Tüketiciler işlenmiş mesaj ID'lerini (inbox) kaydeder, böylece yeniden denemelerde çoğaltmayı önlerler.

Nihai tutarlılık (Eventual consistency): Hizmetler arasında kısa süreli farklılıkları kabul eder ve uzlaşma için net bir planı olur.

Garantileri ne zaman gevşetmeli ve riski nasıl kontrol etmeli

Garantileri gevşetin quando:

• Geçici uyumsuzluklara katlanabilirsiniz (ör. gönderim durumu sipariş oluşturulmasından sonra biraz gecikebilir).
• Hataları telafi edebiliyorsanız (iade, iptal).
• Gecikme ve çalışma zamanı kullanılabilirliği anlık küresel doğruluktan daha önemliyse.

Riski kontrol edin:

• Hangi invariantların asla bozulmaması gerektiğini tanımlayın
• Operasyonları idempotent yapın
• Zaman aşımı ve tekrar denemelerde geri çekilme (backoff) kullanın
• Sürüklenmeyi izleyin (takılı kalan sagalar, tekrarlayan telafi işlemleri, büyüyen outbox tabloları)

Gerçekten kritik invariantlar (ör. "bir hesabı asla aşmama") için mümkünse bunları tek bir servis ve tek bir veritabanı işlemi içinde tutun.

Pratik Kontrol Listesi: ACID Sistemleri Tasarlamak, Test Etmek ve İzlemek

Bir işlem birim testinde "doğru" olsa bile gerçek trafiğe, yeniden başlatmalara ve eşzamanlılığa maruz kaldığında başarısız olabilir. ACID garantilerini üretimdeki davranışla hizalamak için bu kontrol listesini kullanın.

1) Tasarım: Invariantları ve işlem sınırını tanımlayın

Önce her zaman doğru olması gerekenleri yazın (veri invariantlarınız). Örnekler: "hesap bakiyesi hiçbir zaman negatif olamaz", "sipariş toplamı kalemlerin toplamına eşit olmalı", "envanter sıfırın altına düşemez", "bir ödeme tam olarak bir siparişe bağlanmalıdır." Bunları ürün kuralları olarak ele alın.

Sonra hangi adımların tek bir işlem içinde olması gerektiğine karar verin vs. hangi adımların ertelenebileceğine.

• Veri invariantları: dahil olan tablolar/satırlar ve tam kural.
• Hata senaryoları: istek ortasında proses çökmesi, commit sonrası ağ zaman aşımı, yeniden deneme ile kopyalar, replika failover, disk dolması.
• Eşzamanlılık profili: hangi operasyonlar paralel çalışır, beklenen içerme noktaları, okumaların güncel olması gerekip gerekmediği.

İşlemleri küçük tutun: daha az satıra dokunun, daha az iş yapın (harici API çağrısı yok), ve hızlı commit edin.

2) Test: Yarış ve hata durumlarında davranışı kanıtlayın

Eşzamanlılığı birinci sınıf test boyutu yapın.

• Yarış koşulu testleri: kritik işlemi eşzamanlı çalıştırın (ör. son ürün için iki checkout) ve invariantların asla bozulmadığını doğrulayın.
• Hata enjeksiyonu: uygulama sürecini işlem ortasında öldürün; zaman aşımı, yeniden deneme, DB yeniden başlatma simülasyonu yapın; sonuçların ya bir kez commit edildiğini ya güvenli şekilde rollback olduğunu doğrulayın.
• Doğruluk kontrolleriyle yük testleri: zirve yük altında gecikmeleri değil, aynı zamanda toplamları, sayıları ve "çift kayıt yok" kısıtlarını doğrulayın.

Yeniden denemeleri destekliyorsanız açık bir idempotentlik anahtarı ekleyin ve "başarıdan sonra istek tekrarlandığında" testi yapın.

3) İzle: Kullanıcılar görmeden önce ACID sorunlarını yakalayın

Garantilerinize sürtünme getirdiğini gösteren göstergeleri izleyin:

• Kilit beklemeleri ve kuyruk zamanı (artan içerme)
• Deadlock'lar (sıklık, kurban sorgular)
• Uzun süren işlemler (çoğunlukla asıl neden)
• Replikasyon gecikmesi (stale okumalar, delayed failover)
• Commit/fsync süreleri (depolama baskısı; kalıcılık maliyeti)

Trend tabanlı uyarılar oluşturun ve bu metrikleri onları tetikleyen uç nokta veya işlerle ilişkilendirin.

Kural niteliğinde: izolasyon ve işlem kapsamı

İnvariantlarınızı koruyacak en zayıf izolasyonu kullanın; varsayılan olarak "her şeyi maksimuma çekmeyin". Küçük kritik bölüm (para transferi, envanter azaltma) için katı doğruluk gerektiğinde, işlemi sadece o bölümle sınırlayın ve geri kalan her şeyi dışarıda tutun.