Dağıtık Sistemlerde Veri Tutarlılığını (Data Consistency) Sağlamak

Bir kullanıcı ödeme yaptıktan sonra sipariş ekranında hâlâ “ödeme bekleniyor” mesajını görürse sorun yalnızca birkaç saniyelik gecikme değildir. Aynı koltuk iki kişiye satılıyorsa, stok sıfırın altına düşüyorsa veya aynı ödeme retry nedeniyle iki kez çekiliyorsa doğrudan iş kuralı bozulmuştur. On yılı aşkın backend ve dağıtık sistem çalışmalarında en faydalı yaklaşımın önce teknoloji seçmek değil, hangi verinin hangi koşullarda ne kadar güncel ve hangi sırada görünmesi gerektiğini tanımlamak olduğunu gördüm. Dağıtık Sistemlerde Veri Tutarlılığını (Data Consistency) Sağlamak bu nedenle yalnızca replication ayarı veya message broker seçmekten ibaret değildir. Bu rehberde consistency modellerinden CAP ve PACELC'e, quorum ve consensus'tan Saga, transactional outbox, idempotency, CRDT, reconciliation ve fault testlerine kadar production seviyesinde ihtiyaç duyulan temel kararları birlikte ele alacağız.

Dağıtık Sistemlerde Veri Tutarlılığı Nedir?

Dağıtık sistemlerde veri tutarlılığı, aynı mantıksal verinin birden fazla node, replica, servis veya projection üzerinde hangi kurallarla gözlemlendiğini tanımlar. Bir write tamamlandıktan sonra bütün reader'ların hemen yeni değeri görmesi zorunlu olabilir veya kısa süre eski değer görülmesi kabul edilebilir. Önemli olan sistemin hangi davranışı garanti ettiğinin açık olmasıdır. Tutarlılık modeli uygulamanın izin verdiği operation history'lerini sınırlar. Bu nedenle dağıtık sistemlerde veri tutarlılığı nasıl sağlanır sorusuna verilecek doğru cevap önce hangi garantinin gerçekten gerekli olduğunu belirlemekle başlar.

Data Consistency Ne Anlama Gelir?

Data consistency aynı verinin farklı kopyaları arasında nasıl bir görünürlük ve sıralama garantisi bulunduğunu ifade eder. Bir kullanıcı yeni adresini kaydettikten sonra başka bir replica eski adresi döndürüyorsa sistem belirli süre stale read üretiyor olabilir. Bu her zaman hata değildir, çünkü eventual consistency kullanan bir sistem bunu kontrollü biçimde kabul edebilir. Hata, uygulamanın güçlü garanti beklerken altyapının daha zayıf davranış sunmasıdır. Bu nedenle distributed systems data consistency modelleri nelerdir sorusu teknik seçimden önce iş beklentisinin açık şekilde yazılmasını gerektirir.

Replica'ların Aynı Veriyi Görmesi Ne Demektir?

Bir kaydın üç replica üzerinde tutulduğunu düşünelim ve kullanıcı A değerini B olarak değiştirsin. Synchronous replication kullanılan modelde write belirli replica'lar değişikliği doğrulamadan tamamlanmış sayılmayabilir. Asynchronous modelde primary kullanıcıya başarı dönerken bazı replica'lar kısa süre eski A değerini tutabilir. “Aynı veriyi görmek” ifadesi bütün replica'ların her anda birebir aynı olması anlamına gelmek zorunda değildir. Asıl soru, farklılığın ne kadar sürebildiği ve hangi read operation'larının yeni değeri görmek zorunda olduğudur.

Stale Data Nedir?

Stale data, authoritative veya daha yeni bir sürüm mevcutken reader'ın eski version görmesidir. Replica lag, cache, delayed projection veya event consumer gecikmesi stale read oluşturabilir. Bir ürün açıklamasının beş saniye eski olması kabul edilebilirken banka bakiyesinin eski görünmesi kullanıcıya yanlış karar verdirebilir. Bu nedenle staleness teknik olarak aynı olsa bile iş etkisi veri sınıfına göre tamamen değişir. Production sistemlerde stale window mümkün olduğunca ölçülebilir bir SLO olarak tanımlanmalıdır.

Veri Tutarlılığı ile Veri Bütünlüğü Arasındaki Fark

Veri bütünlüğü, verinin domain ve schema kurallarına uygun kalmasıyla ilgilidir. Foreign key, unique constraint veya “stok negatif olamaz” kuralı integrity örnekleridir. Veri tutarlılığı ise farklı reader ve replica'ların değişiklikleri hangi sıra ve zamanlama ile gördüğünü açıklar. Bir sistem bütün replica'larda aynı fakat yanlış değeri taşıyabilir ve bu durumda consistency bulunurken integrity bozuk olabilir. Sağlam tasarım iki kavramı birlikte ele alır ve birini diğerinin yerine kullanmaz.

Data Consistency ile ACID Consistency Arasındaki Fark

ACID içindeki consistency, transaction'ın veritabanını tanımlanan invariant'lara uygun bir durumdan yine uygun bir duruma taşıması anlamında kullanılır. Distributed consistency modellerindeki consistency ise operation'ların farklı process ve replica'lar tarafından nasıl gözlemlendiğine odaklanır. Örneğin linearizability gerçek zaman sırasına uygun tek-object görünürlüğü tanımlarken ACID consistency business constraint'lerin korunmasıyla ilişkilidir. Aynı “consistency” kelimesinin iki bağlamda farklı anlam taşıması mimari tartışmalarda sık karışıklık oluşturur. Ekip dokümantasyonunda hangi anlamın kullanıldığı açıkça belirtilmelidir.

Dağıtık Sistemlerde Tutarlılık Neden Zordur?

Tek process içinde memory'ye yazıp hemen okumak görece kolaydır, çünkü communication failure ihtimali sınırlıdır. Dağıtık sistemde ise her mesaj gecikebilir, iki kez gelebilir, sırası değişebilir veya hiç ulaşmayabilir. Node crash olabilir ve tekrar açıldığında diğerlerinden farklı state taşıyabilir. Bir bölgedeki saat diğerinden farklı olabilir ve iki kullanıcı aynı veriyi eşzamanlı değiştirebilir. Tutarlılık tasarımının büyük bölümü bu normal failure koşullarında iş kurallarının nasıl korunacağını belirlemektir.

Network Gecikmesi

Network üzerindeki hiçbir remote call sıfır süre almaz. Aynı data center içindeki birkaç milisaniyelik gecikme bile synchronous coordination sırasında toplam transaction latency'sine eklenir. Cross-region bağlantıda fiziksel mesafe bu bedeli daha da yükseltir. Strong consistency isteyen sistem remote acknowledgement beklediğinde kullanıcı bu round-trip maliyetini doğrudan yaşayabilir. Bu nedenle consistency seviyesi latency bütçesinden bağımsız seçilmemelidir.

Network Partition

Network partition bazı node'ların birbirine ulaşamadığı fakat kendi başlarına çalışmaya devam ettiği durumdur. İki taraf da alive görünse bile aralarındaki communication kesilmiş olabilir. Bu noktada sistem aynı veriye iki taraftan write kabul ederse conflict üretebilir. Strong consistency tercih eden sistem bazı operation'ları reddederek tek ordering'i koruyabilir. Availability tercih eden sistem operation kabul edip daha sonra conflict resolution yapmak zorunda kalabilir.

Node Failure

Bir node process crash, hardware arızası veya işletim sistemi problemi nedeniyle kaybolabilir. Node'un write'ı disk'e yazıp yazmadığı veya replica'lara gönderip göndermediği client açısından belirsiz kalabilir. Retry yapılan işlem aslında daha önce başarılı olmuş olabilir. Bu nedenle idempotency failure recovery'nin temel parçalarından biridir. Replica ve consensus mekanizmaları node failure'ını tamamen engellemez, yalnızca sistemin kontrollü şekilde devam etmesini sağlar.

Message Loss

Publisher mesaj gönderdiğini düşünebilir fakat broker'a ulaşıp ulaşmadığını kesin bilmiyor olabilir. Broker mesajı almış fakat acknowledgement client'a ulaşmamış olabilir. Consumer tarafında da network kesilmesi processing sonucunun teyidini engelleyebilir. Bu belirsizlik retry ihtiyacını doğurur. Retry bulunan her sistem duplicate-safe tasarım gerektirir.

Message Duplication

At-least-once delivery modellerinde aynı message birden fazla kez consumer'a ulaşabilir. İlk processing başarılı olmuş fakat offset veya acknowledgement kaydedilememişse mesaj yeniden gönderilir. Consumer her duplicate event'te tekrar para çekerse ciddi business hatası oluşur. Message ID, unique constraint ve idempotent operation bu riski sınırlar. Duplicate delivery olağan failure davranışı olarak test edilmelidir.

Out-of-Order Messages

Aynı entity için önce “OrderCancelled”, sonra gecikmiş “OrderCreated” event'i gelebilir. Consumer yalnızca arrival order'a güvenirse state geriye dönebilir. Sequence number veya aggregate version doğru order'ı doğrulamaya yardım eder. Broker partition ordering sağlasa bile farklı producer veya retry akışları uygulama seviyesinde ayrıca düşünülmelidir. Global ordering istemek pahalı olduğu için çoğu sistem per-entity ordering ile yetinir.

Clock Skew

İki sunucunun wall clock değerleri tam olarak aynı olmayabilir. NTP farkı küçültse de dağıtık correctness için mutlak senkron saat varsaymak risklidir. Last-write-wins yalnızca timestamp'e dayanıyorsa gerçekte daha eski operation yeni görünebilir. Logical clock veya version number ordering açısından daha güvenilir olabilir. Fiziksel saat business timestamp için faydalı olsa da concurrency sırasını belirleyen tek kaynak yapılmamalıdır.

Concurrent Writes

İki kullanıcı aynı kaydı aynı anda değiştirebilir ve ikisi de eski version üzerinden işlem yapabilir. Son write diğer değişikliği sessizce ezebilir. Optimistic concurrency control version check ile bu durumu fark eder. Domain bazı alanları merge edebiliyorsa conflict otomatik çözülebilir. Çözülemiyorsa kullanıcıya veya business workflow'a conflict sunmak veri kaybetmekten daha güvenlidir.

Multi-Region Deployment

Birden fazla region düşük kullanıcı latency'si ve disaster recovery avantajı sağlar. Bunun karşılığında cross-region coordination fiziksel network mesafesine bağlıdır. Single-writer region tutarlılığı sadeleştirirken uzak region write latency'sini artırabilir. Multi-writer model local write'ı hızlandırır fakat conflict resolution ihtiyacını büyütür. Region tasarımı availability kadar data ownership ve consistency gereksinimine göre yapılmalıdır.

Tutarlılık Önce Business Invariant ile Tanımlanmalıdır

Dağıtık sistem tasarımında en sık gördüğüm sorun “strong mu eventual mı?” sorusunun business kuralından önce sorulmasıdır. Asıl başlangıç noktası sistemde asla bozulmaması gereken invariant'lardır. Bir invariant hangi operasyonların birlikte korunması gerektiğini gösterir. Bu bilgi consistency boundary ve transaction tasarımını doğrudan belirler. Teknoloji kararı iş kuralından türediğinde gereksiz coordination azalırken kritik state daha güçlü korunabilir.

Business Invariant Nedir?

Business invariant sistemin her geçerli durumunda doğru kalması gereken domain kuralıdır. “Sipariş toplamı satır toplamlarıyla eşleşmelidir” buna örnek olabilir. Invariant yalnızca normal operation sırasında değil retry, crash ve concurrent request altında da korunmalıdır. Database constraint bazı invariant'ları doğrudan uygulayabilir. Servisler arası invariant ise workflow, reservation veya reconciliation gibi ek pattern'ler gerektirebilir.

Stok Negatif Olamaz

Inventory değeri sıfır olan üründen yeni rezervasyon kabul edilmemesi gerekir. İki request aynı anda kalan son ürünü okuyup ikisi de satın alırsa lost-update benzeri sorun oluşabilir. Atomic conditional update veya serializable transaction bu invariant'ı tek database boundary içinde koruyabilir. Distributed inventory workflow reservation token kullanabilir. Cache'teki eski stok değeri satın alma kararının tek kaynağı olmamalıdır.

Aynı Koltuk İki Kişiye Satılamaz

Koltuk rezervasyonu unique ownership gerektirir. Aynı seat için iki request farklı application node'larından gelebilir. Database unique constraint veya conditional write güçlü koruma sağlayabilir. Reservation belirli süre lease olarak tutulup ödeme tamamlanınca satışa dönüştürülebilir. Bu invariant yalnızca eventual merge ile sonradan çözülmeye bırakılırsa iki müşteriye aynı anda başarı mesajı verilmiş olabilir.

Ödeme İki Kez Çekilemez

Network timeout sonrası kullanıcı veya application ödeme request'ini tekrar gönderebilir. İlk işlem external payment provider tarafında aslında tamamlanmış olabilir. Idempotency key aynı business operation'ın ikinci kez para çekmesini engeller. Local database unique constraint operation ID'yi kaydedebilir. “Exactly once network delivery” beklentisi yerine duplicate-safe payment semantics tasarlamak daha güvenilir yaklaşımdır.

Muhasebe Toplamı Korunmalıdır

Ledger sisteminde debit ve credit kayıtlarının matematiksel invariant'ı korunmalıdır. Sadece current balance saklamak yerine append-only entries audit ve reconciliation avantajı sağlar. Transferin bir tarafı yazılıp diğer tarafı kaybolmamalıdır. Aynı database içindeyse ACID transaction güçlü çözüm olabilir. Birden fazla sistem arasında çalışıyorsa workflow state ve reconciliation zorunlu hale gelir.

Kullanıcı Adı Tekil Olmalıdır

İki region aynı anda aynı username için create kabul ederse sonradan conflict ortaya çıkabilir. Global uniqueness strong coordination gerektirebilir. Bu maliyet kabul edilmiyorsa username allocation belirli home region veya centralized authority üzerinden yapılabilir. “Sonradan birini sileriz” yaklaşımı kullanıcı deneyimi açısından genellikle kabul edilemez. Invariant'ın ne kadar güçlü olduğu sistem topolojisini doğrudan etkiler.

Teknik Consistency Modelini Business Kuralından Türetmek

Her invariant için ihlal edildiğinde ne olacağı yazılmalıdır. Para kaybı veya duplicate reservation söz konusuysa stronger coordination gerekebilir. Ürün açıklamasının birkaç saniye eski olması düşük risk taşıyabilir ve eventual consistency yeterli olur. Böylece aynı sistem farklı data sınıflarında farklı modeller kullanabilir. Strong consistency ve eventual consistency arasındaki farklar ancak business etkisiyle birlikte değerlendirildiğinde anlamlı bir mimari karara dönüşür.

Consistency Boundary Nedir?

Consistency boundary birlikte atomik veya koordineli tutulması gereken state'in sınırını ifade eder. Bu sınır ne kadar geniş olursa distributed coordination maliyeti o kadar artar. Domain tasarımı mümkün olduğunca invariant'ları küçük sınırlar içinde tutmalıdır. Bir service içindeki local transaction genellikle servisler arası distributed transaction'dan daha ucuz ve güvenilirdir. Bu nedenle service boundary çizerken yalnızca ekip organizasyonu değil business atomicity gereksinimi de dikkate alınmalıdır.

Hangi Değişiklikler Atomik Olmalıdır?

İki field birbirinden bağımsız güncellenebiliyorsa aynı global transaction'a alınmaları gerekmez. Fakat sipariş toplamı ile payment reservation birlikte invariant oluşturuyorsa koordinasyon gerekebilir. Atomik boundary business rule üzerinden belirlenmelidir. Her operation'ı tek dev transaction'a bağlamak availability ve throughput'u azaltır. Gereksiz atomicity distributed system'in ölçeklenmesini zorlaştırır.

Aggregate Boundary

Domain-driven design yaklaşımında aggregate, birlikte tutarlı kalması gereken entity grubunu sınırlar. Bir aggregate içindeki invariant local transaction ile korunabilir. Aggregate'ler arası değişiklik event ve eventual workflow ile yürütülebilir. Çok büyük aggregate lock contention ve write bottleneck yaratabilir. Boundary gerçek business invariant'ları temsil edecek kadar küçük tutulmalıdır.

Service Boundary

Microservice kendi data ownership'ine sahip olduğunda local transaction boundary netleşir. Başka service database'ine doğrudan yazmak bu ownership'i bozar. Cross-service workflow event veya command üzerinden ilerler. Service boundary business capability ile uyumlu değilse sürekli distributed transaction ihtiyacı doğabilir. Bu durum service decomposition kararının yeniden değerlendirilmesi gerektiğine işaret eder.

Bounded Context

Aynı kelime farklı domain bağlamlarında farklı anlam taşıyabilir. “Customer” sales ve billing context'lerinde farklı model olabilir. Her bounded context kendi consistency kurallarını yönetebilir. Context'ler arasında event ile data kopyalandığında kısa süre farklılık normal olabilir. Bu ayrım global ortak model zorunluluğunu azaltır.

Database Boundary

Tek relational database içindeki transaction güçlü atomicity ve isolation sunabilir. Problemi gereksiz biçimde servisler ve database'ler arasında dağıtmak daha pahalı consistency mekanizmaları gerektirir. Bir invariant doğal olarak tek database içinde tutulabiliyorsa bunu bölmek için güçlü gerekçe bulunmalıdır. Scale ihtiyacı geldiğinde partition veya service boundary kontrollü biçimde yeniden ele alınabilir. Basit local transaction dağıtık koordinasyondan çoğu zaman daha güvenlidir.

Gereksiz Dağıtık Transaction'lardan Kaçınmak

Her service'in aynı operation'da synchronous commit vermesi availability'yi zincirin en zayıf halkasına bağlar. Network round-trip ve lock süresi büyür. Domain boundary doğru çizilirse bazı adımlar eventual workflow'a ayrılabilir. Reservation ve compensation pattern'leri atomik global transaction ihtiyacını azaltır. Mikroservislerde Saga pattern distributed transaction ve veri tutarlılığı yönetimi tartışması da tam olarak bu boundary kararından doğar.

Tutarlılık Bir Spektrumdur

Consistency yalnızca strong ve eventual şeklinde iki kutuptan oluşmaz. Linearizability, sequential, causal ve session-level garantiler farklı ihtiyaçlara cevap verir. Uygulamanın bütün operasyonlarında aynı modeli kullanması gerekmez. Daha güçlü garanti genellikle daha fazla coordination ve latency bedeli getirir. En doğru seçim business invariant ve user experience için gerekli minimum güvenceyi sağlayan modeldir.

Strong Consistency

Strong consistency günlük kullanımda write tamamlandıktan sonra reader'ın en güncel state'i görmesi beklentisini ifade eder. Ancak teknik belgelerde “strong” kelimesi tek başına yeterince kesin olmayabilir. Linearizability veya strict serializability gibi daha açık model isimleri tercih edilmelidir. Coordination failure durumunda bazı operation'ların reddedilmesi gerekebilir. Güçlü garanti kritik state için değerli olsa da bütün data üzerinde zorunlu tutulması gereksiz latency yaratabilir.

Linearizability

Linearizability tek-object operation'ların atomik bir noktada gerçekleşmiş gibi görünmesini ve gerçek zaman sırasını korumasını ister. Bir write tamamlandıktan sonra başlayan read eski değeri döndüremez. Concurrent operation'ların kendi aralarında mantıksal sıra seçilebilir. Network partition sırasında bu garanti bütün node'larda availability ile birlikte korunamaz. Distributed lock service veya metadata store gibi sistemlerde linearizable operation kritik olabilir.

Sequential Consistency

Sequential consistency bütün process'lerin operation'ları aynı total order içinde görmesini ister. Ancak bu order gerçek zaman sırasına bağlı olmak zorunda değildir. Bir operation gerçek dünyada önce bitmiş olsa bile logical ordering içinde daha sonra yer alabilir. Bu nedenle linearizability'den daha zayıftır. Bazı coordination problemlerinde gerçek zaman constraint gerekmiyorsa yeterli olabilir.

Causal Consistency

Causal consistency bir operation başka operation'ın sonucu olarak oluşmuşsa bu sebep-sonuç sırasının korunmasını ister. Bir kullanıcı post'u yazdıktan sonra başka kullanıcı o post'a reply verdiyse reply'nin post'tan önce görünmemesi beklenir. Birbiriyle nedensel ilişkisi olmayan concurrent updates farklı order'larda görülebilir. Bu model linearizability'den daha az coordination gerektirebilir. Sosyal ve işbirliği uygulamalarında kullanıcı beklentisiyle iyi örtüşür.

Session Consistency

Session consistency aynı kullanıcı veya client session içinde belirli garantiler verir. Diğer kullanıcılar kısa süre stale data görebilir. Kullanıcı kendi write'ını hemen görüyorsa read-your-writes sağlanmış olur. Monotonic read kullanıcının daha yeni state gördükten sonra eskiye dönmesini engeller. Eventual sistemlerde UX'i belirgin biçimde iyileştiren pratik bir ara modeldir.

Read-Your-Writes

Kullanıcı bir değişiklik yaptıktan sonra kendi sonraki okumalarında bu değişikliği görmelidir. Replica lag bulunan sistemde random replica routing bu garantiyi bozabilir. Write sonrası bir süre primary'ye yönlendirme uygulanabilir. Consistency token reader'ın minimum version şartını belirtmesine yardım edebilir. Bu model bütün kullanıcılar için global strong consistency gerektirmeden iyi kullanıcı deneyimi sağlar.

Monotonic Reads

Monotonic read bir client daha yeni bir version gördükten sonra sonraki read'de daha eski version görmemesini sağlar. Multi-replica routing bunu aksi durumda bozabilir. Session replica affinity veya version token çözüm olabilir. Bu garanti notification veya feed gibi sistemlerde “bilgi geri gitti” hissini azaltır. Eventual consistency üzerinde uygulanabilen faydalı client-centric garantilerden biridir.

Eventual Consistency

Eventual consistency update olmadığı yeterince uzun bir dönemde replica'ların aynı state'e yakınsamasını hedefler. Geçiş sırasında farklı replica'lar farklı version döndürebilir. Model tek başına ne kadar sürede convergence olacağını söylemez. Bu süre uygulama SLO'su olarak ayrıca tanımlanmalıdır. Social feed, analytics veya recommendation gibi bazı workload'larda latency ve availability avantajı nedeniyle uygun olabilir.

Strong Consistency Nedir?

Strong consistency pratik kullanımda write başarıyla tamamlandıktan sonra yeni read'lerin güncel state'i görmesini bekleyen modeldir. Bu hedef çoğu zaman leader coordination, quorum veya consensus benzeri mekanizmalar gerektirir. Coordination network round-trip ve failure sensitivity oluşturur. Buna rağmen duplicate reservation veya yanlış balance gibi kabul edilemez iş sonuçlarını önlemek için bedel ödenebilir. Güçlü model yalnızca gerçekten gerekli veri sınıflarına uygulanmalıdır.

Güncel Yazmanın Hemen Görünmesi

Write response'u kullanıcıya başarı döndüğünde sistem yeni value'yu committed kabul eder. Sonrasında başlayan uygun read operation eski state'i göstermemelidir. Replica üzerinden okuma yapılıyorsa replica'nın gerekli commit seviyesine ulaştığı garanti edilmelidir. Asynchronous follower read bu gereksinimi bozabilir. Uygulama read path'i consistency modeline uygun routing yapmalıdır.

Coordination Gereksinimi

Birden fazla node aynı ordering üzerinde anlaşmak zorundaysa mesaj alışverişi gerekir. Leader write'ı replica'lara aktarabilir ve belirli acknowledgement sayısını bekleyebilir. Consensus protokolü leader değişimini ve log ordering'i koordine eder. Partition sırasında quorum bulunamazsa operation durabilir. Availability kaybı güçlü correctness garantisinin doğal maliyetlerinden biri olabilir.

Network Round-Trip Maliyeti

Synchronous write remote node acknowledgement beklediğinde kullanıcı latency'sine network süresi eklenir. Aynı region içinde bedel düşük olabilir. Cross-region consensus onlarca veya yüzlerce milisaniye ekleyebilir. Her write'ın global coordination gerektirip gerektirmediği bu nedenle dikkatle değerlendirilmelidir. Home-region veya geo-partitioning latency'yi kontrol altında tutabilir.

Strong Consistency Ne Zaman Gereklidir?

Strong consistency özellikle aynı resource üzerinde iki operation'ın yanlış sırada görülmesinin kabul edilemez olduğu durumlarda kullanılır. Ancak domain bazen daha zayıf consistency ile aynı invariant'ı reservation veya idempotency üzerinden koruyabilir. Teknolojik “strong” etiketi tek başına business correctness garantisi değildir. İş kuralının hangi anomaly'yi yasakladığı tanımlanmalıdır. Sonra bu anomaly'yi önleyen minimum model seçilebilir.

Ödeme

Ödeme state'i kullanıcıya yanlış başarı veya başarısızlık göstermemelidir. Aynı idempotency key iki kez para çekmemelidir. Payment provider response belirsizse reconciliation gerekebilir. Strong local transaction payment record invariant'ını koruyabilir. External side effect için idempotency ve durable workflow yine gereklidir.

Stok

Kalan son stok için iki concurrent checkout başarılı olmamalıdır. Atomic decrement veya reservation strong local consistency sağlayabilir. Displayed inventory kısa süre stale olabilir. Final purchase sırasında authoritative kontrol yapılmalıdır. Böylece bütün catalog read'leri global strong olmak zorunda kalmaz.

Rezervasyon

Koltuk veya oda rezervasyonu exclusive ownership gerektirir. Conditional write veya unique constraint en güvenilir guard olabilir. Reservation lease belirli sürede expire edilebilir. Payment ayrı Saga adımı olarak çalışabilir. Expired lease başka kullanıcıya tahsis edilmeden önce authoritative state kontrol edilmelidir.

Kimlik ve Yetkilendirme

Role kaldırıldıktan sonra kullanıcının uzun süre eski permission ile işlem yapması güvenlik sorunudur. Authorization cache staleness sınırı bu nedenle kısa tutulabilir. Critical revocation event explicit invalidation yapmalıdır. Token expiry başka safety layer sağlar. Strong read her request için pahalıysa risk seviyesine göre hibrit yaklaşım kullanılabilir.

Finansal Ledger

Ledger entry'leri audit edilebilir ve invariant koruyan transaction içinde yazılmalıdır. Append-only model geçmişi değiştirmeden correction entry eklemeyi sağlar. Balance materialization eventual projection olabilir. Ancak source ledger correctness güçlü tutulur. Financial reconciliation sistem dışı side effect ve projection farklarını düzenli doğrular.

Linearizability Nedir?

Linearizability operation'ların gerçek zamanla uyumlu tek atomik sıra içinde gerçekleşmiş gibi görünmesini tanımlar. Jepsen'in güncel consistency model açıklamalarında da bu model single-object tarafındaki en güçlü yaygın garantilerden biri olarak tanımlanır. Bir operation tamamen bitmeden başlayan başka operation concurrent kabul edilebilir. Fakat ilk operation bittikten sonra başlayan ikinci operation mantıksal olarak daha önceye yerleştirilemez. Bu garanti lock, metadata ve ownership kararlarında özellikle değerlidir.

Real-Time Ordering

Gerçek zaman ordering bir operation tamamlandıktan sonra başlayan operation'ın logical sırada ondan sonra gelmesini ister. Bu özellik sequential consistency'den temel farktır. Wall clock timestamp'lerin birebir senkron olması gerekmez. Protocol mesaj akışı bu ordering'i sağlayabilir. Kullanıcı açısından “başarı aldıktan sonra sistem eski hale dönmedi” beklentisiyle örtüşür.

Her Operasyonun Tek Bir Noktada Gerçekleşmiş Gibi Görünmesi

Concurrent write'ların fiziksel olarak farklı node'larda işlenmesi mümkündür. Linearizable history dışarıdan bakıldığında bunları tek sıra halinde açıklayabilmelidir. Her operation bir linearization point'e sahipmiş gibi yorumlanır. Bu property concurrent object reasoning'i sadeleştirir. Buna karşılık coordination bedeli vardır.

Linearizable Read

Linearizable read kendisinden önce tamamlanmış write'ları gözlemlemek zorundadır. Stale follower bu garantiyi doğrudan sağlayamaz. Leader read veya quorum/lease tabanlı yöntem kullanılabilir. Read'in tamamen local olması latency açısından avantajlıdır fakat correctness için node'un hâlâ authoritative olduğundan emin olunmalıdır. Lease ve term bilgisi burada önem kazanır.

Linearizable Write

Write başarılı döndüğünde operation ordering içinde committed kabul edilir. Sonraki operation'lar bu write'ı yok sayamaz. Consensus log commit bu guarantee için yaygın mekanizmadır. Client timeout sonucu belirsiz operation yaratabilir ve retry idempotent olmalıdır. Linearizable storage business side effect'in de otomatik olarak exactly-once olmasını sağlamaz.

Linearizability'nin Maliyeti

Partition sırasında bütün node'lar progress sağlayamayabilir. Quorum veya leader'a erişemeyen taraf operation reddedebilir. Cross-region deployment network latency'sini write path'e ekleyebilir. Availability ve tail latency üzerindeki bedel önemli olabilir. Bu yüzden linearizability yalnızca gerçekten real-time ordering isteyen operation'lara uygulanmalıdır.

Serializability ile Linearizability Arasındaki Fark

Serializability transaction'ların sanki birbiri ardına çalışmış gibi sonuç üretmesini ister. Linearizability ise single-object operation ordering'ine gerçek zaman constraint ekler. Jepsen referansında serializability multi-object transactional model olarak, linearizability ise gerçek zaman uyumlu single-object model olarak ele alınır. İkisini birleştiren stronger yaklaşım strict serializability olarak adlandırılır. Hangi garantinin gerekli olduğu transaction scope ve gerçek zaman beklentisine göre belirlenmelidir.

Transaction Ordering

Serializable execution concurrent transaction'ların sonuçlarını bir serial order ile açıklayabilmelidir. Bu order gerçek execution zamanından farklı olabilir. Transaction birden fazla object üzerinde read ve write yapabilir. Isolation anomaly'leri bu model tarafından engellenir. Financial multi-row invariant için serializability yararlı olabilir.

Real-Time Ordering

Linearizability operation A tamamlandıktan sonra B başlıyorsa A'nın logical olarak B'den önce olmasını ister. Serializable sistem böyle gerçek zaman constraint taşımayabilir. User iki ayrı transaction arasında eski state görebilir ve yine serializable history oluşabilir. Bu şaşırtıcı durum model adlarının dikkatli kullanılmasını gerektirir. Real-time requirement varsa strict serializable model düşünülmelidir.

Multi-Object Transaction

Serializability transaction içindeki birden fazla row ve table operation'ı kapsayabilir. Linearizability tarihsel tanımında object bazlıdır. Distributed database bazı key'lerde linearizable operation sunarken multi-key transaction sunmayabilir. Business invariant birden fazla object kapsıyorsa yalnızca per-key linearizability yeterli değildir. Transaction model ayrıca değerlendirilmelidir.

Strict Serializability

Strict serializability serializable transaction ordering ile real-time ordering'i birleştirir. Bu nedenle çok güçlü bir modeldir. User bir transaction'ın tamamlandığını gördükten sonra başlayan başka transaction geçmiş state'e dönemez. Coordination maliyeti yükselebilir. Kritik finansal workflow için güçlü değer sağlayabilir.

Hangi Garanti Hangi Problem İçindir?

Single key ownership veya distributed lock için linearizable operation gerekir. Çok-row business invariant için serializable transaction daha ilgili olabilir. İkisi birlikte gerekiyorsa strict serializability hedeflenir. Eventual projection için bunların hiçbiri zorunlu olmayabilir. Model seçimi problem türünden türetilmelidir.

Eventual Consistency Nedir?

Eventual consistency write'ın bütün kopyalara aynı anda ulaşmasını zorunlu tutmaz. Replicas kısa süre farklı state taşıyabilir. Yeni update gelmezse sistemin sonunda aynı değere yakınsaması beklenir. Cassandra güncel belgeleri de divergent replica version'larının geçici olarak bulunabildiği ve sonunda reconcile edildiği eventual modeli açıkça tanımlar. Uygulama bu geçici farkın maksimum süresini ayrıca ölçmeli ve iş açısından kabul edilebilir sınır belirlemelidir.

Asynchronous Replication

Primary client'a response döndürmeden önce bütün followers'ı beklemez. Replica update network üzerinden daha sonra ulaşır. Bu write latency'sini düşürür ve bazı failure durumlarında availability'yi artırır. Ancak failover sırasında henüz replica'ya ulaşmamış write kaybolabilir. Read replica da kısa süre stale sonuç verebilir.

Geçici Replica Farklılıkları

Replica A yeni value'yu almışken Replica B eski value'da kalabilir. Random read routing kullanıcıya farklı sonuçlar gösterebilir. Session consistency bunu azaltabilir. Replication lag metriği convergence süresini görünür yapar. Business risk bu window üzerinden değerlendirilmelidir.

Convergence

Convergence update trafiği durduğunda replica'ların aynı logical state'e ulaşmasıdır. Conflict resolution deterministic olmalıdır. Read repair veya anti-entropy divergent replicas'ı düzeltebilir. Event consumer sisteminde replay ve reconciliation benzer rol üstlenir. Convergence garantisi bulunmayan sistemde eventual consistency ifadesi anlamını kaybeder.

Eventual Ne Kadar Sürede Gerçekleşir?

Teorik eventual model kesin süre vermek zorunda değildir. Production uygulaması için bu cevap yetersizdir. “Projection yüzde 99,9 oranında 5 saniye içinde güncellenir” gibi ölçülebilir hedef gerekir. Consumer lag ve replication lag bu hedefi takip eder. Süre aşıldığında alarm ve recovery mekanizması çalışmalıdır.

Eventual Consistency Ne Zaman Uygundur?

Stale data kısa süre kullanıcı veya business üzerinde kritik hata oluşturmuyorsa eventual consistency güçlü ölçek avantajı sağlayabilir. Read-heavy global sistemler local replica üzerinden daha düşük latency alabilir. Write coordination azalır. Buna rağmen read-your-writes veya causal guarantee gibi client-centric özellikler eklenebilir. Eventual seçimi “consistency önemsiz” anlamına gelmez.

Sosyal Akışlar

Yeni post bütün follower feed'lerinde aynı milisaniyede görünmek zorunda olmayabilir. Fan-out background consumer ile yapılabilir. User kendi post'unu hemen görmelidir. Feed projection kısa süre lag yaşayabilir. Missing event reconciliation ile düzeltilmelidir.

Görüntülenme Sayıları

View counter her request'te global strongly consistent transaction gerektirmeyebilir. Local counters birleştirilebilir. Kullanıcı ekranda birkaç saniye eski toplam görebilir. Analytics doğruluğu daha sonra aggregate edilebilir. Fraud-sensitive metriklerde ayrı authoritative event log tutulabilir.

Öneriler

Recommendation model output'u saniyeler veya dakikalar eski kalabilir. Kullanıcı yine geçerli ürünler görüyorsa business risk düşüktür. Model refresh background yapılabilir. Inventory veya permission gibi kritik filtreler serving anında ayrıca doğrulanabilir. Böylece suggestion data eventual kalırken safety constraints strong olabilir.

Ürün Kataloğu

Ürün açıklaması region replicas arasında kısa süre farklı olabilir. Fiyat ve stok daha sıkı policy isteyebilir. Catalog content event-driven projection ile dağıtılabilir. Checkout authoritative pricing ve inventory kontrolü yapar. Aynı entity'nin bütün field'ları tek consistency modeline mahkum değildir.

Analytics

Dashboard çoğu zaman birkaç saniye veya dakika lag'i kabul eder. Event stream warehouse'a asenkron akar. Business decision için snapshot timestamp gösterilebilir. Financial close gibi özel raporlar reconciliation sonrası kesinleştirilebilir. Real-time görünüm ile audited görünüm ayrı ürünler olabilir.

Eventual Consistency “Tutarlılık Yok” Anlamına mı Gelir?

Hayır, eventual consistency kuralsızlık anlamına gelmez. Sistem convergence, ordering veya session-level garantiler sunabilir. Strong eventual consistency kullanan CRDT modellerinde aynı update set'ini alan replicas deterministik olarak aynı state'e ulaşabilir. User read-your-writes ve monotonic read gibi özelliklerle daha tutarlı deneyim görebilir. Önemli olan sağlanan garantilerin açık isimlerle tanımlanmasıdır.

Convergence Guarantee

Update akışı durduğunda replicas sonunda aynı logical state'e gelmelidir. Bu deterministic merge veya repair mekanizmasıyla sağlanabilir. Conflict sonsuza kadar unresolved kalıyorsa sistem eventual consistency hedefini gerçekleştirmiyor olabilir. Reconciliation convergence'ın operasyonel safety net'idir. Convergence time SLO ile izlenmelidir.

Read-Your-Writes

Kullanıcı kendi write'ını hemen görerek eventual backend'in farkını daha az hisseder. Write sonrası primary routing yapılabilir. Client version token minimum acceptable version belirleyebilir. Local optimistic UI başka seçenektir. Diğer users yine kısa süre stale görebilir.

Monotonic Read

Client daha yeni version gördükten sonra eski replica'ya düşmemelidir. Session pinning bunu azaltır. Version comparison eski response'u reddedebilir. Bu garanti “sayfa yeniledim, veri geriye gitti” sorununu engeller. Global strong consistency gerektirmeden kullanıcı güvenini artırır.

Causal Ordering

Bir event diğerinin nedeni ise bu order korunmalıdır. Comment post'tan önce görünmemelidir. Partition key veya causal metadata kullanılabilir. Independent updates farklı sıralarda işlenebilir. Böylece gereksiz global ordering maliyetinden kaçınılır.

Strong Eventual Consistency

Strong eventual consistency aynı update set'ini alan replicas'ın aynı state'e ulaşmasını ister. CRDT'ler bu hedef için tasarlanmış veri tipleridir. Merge order sonucu değiştirmemelidir. Network partition sırasında local updates kabul edilebilir. Domain'in merge edilebilir olması temel koşuldur.

Read-Your-Writes Consistency

Read-your-writes consistency kullanıcının kendi gerçekleştirdiği write'ı sonraki read'lerinde görmesini garanti etmeye çalışır. Global linearizability kadar pahalı olmayabilir. Multi-region profile veya settings uygulamalarında iyi user experience sağlar. Write metadata client session'a taşınabilir. Reader en az bu version'a ulaşmış replica seçer veya primary'ye yönlenir.

Kullanıcının Kendi Değişikliğini Hemen Görmesi

Profile name değiştirildikten sonra refresh ekranında eski isim görünmemelidir. Backend replica lag olsa bile application yeni value'yu local response'ta gösterebilir. Daha güvenilir çözüm read path'in gerekli version'ı doğrulamasıdır. User'a özel write timestamp veya version token taşınabilir. Bu küçük garanti perceived consistency'yi ciddi biçimde iyileştirir.

Primary Read Sonrası Write

Write primary üzerinde tamamlandıktan sonraki belirli süre read primary'ye yönlendirilebilir. Bu yaklaşım basittir. Primary read load'u geçici olarak artar. Global read traffic hâlâ replicas tarafından karşılanabilir. Session expiry sonrası normal routing'e dönülür.

Session Pinning

Client belirli süre aynı replica veya leader'a yönlendirilir. Replica write'ı gördükten sonra monotonic behavior kolaylaşır. Node failure halinde pinning bozulabilir. Yeni replica seçilirken minimum version kontrolü yapılmalıdır. Sticky routing availability'yi gereksiz azaltmamalıdır.

Consistency Token

Write response'u committed version veya logical timestamp döndürebilir. Sonraki read request bu token'ı taşır. Server gerekli version'a ulaşmamış replica'yı bekletebilir veya başka node'a yönlendirebilir. Böylece client-specific guarantee explicit hale gelir. Token wall clock yerine monoton version kullanırsa clock skew riski azalır.

Eventual Sistemlerde UX İyileştirme

User çoğu zaman global state'ten çok kendi yaptığı değişikliğin görünmesini önemser. Optimistic UI yeni value'yu anında gösterebilir. Backend confirmation sonrası state kesinleştirilir. Conflict oluşursa user bilgilendirilir. Read-your-writes bu deneyimi server tarafında daha güvenli hale getirir.

Causal Consistency Nedir?

Causal consistency sebep-sonuç ilişkisi olan operation'ların bütün observer'lar tarafından doğru sırada görülmesini amaçlar. Bir operation başka bir operation'ın sonucuna dayanıyorsa ikinci operation önce görünmemelidir. Independent concurrent operations farklı order'larda görülebilir. Bu model global total ordering'e göre daha az coordination isteyebilir. Collaborative ve social sistemlerde kullanıcı davranışıyla doğal biçimde örtüşür.

Cause-and-Effect İlişkisi

Kullanıcı önce dosya oluşturur, sonra dosyaya comment ekler. Comment create operation dosyanın varlığına nedensel olarak bağlıdır. Replica comment'i dosyadan önce gösterirse user açısından anlamsız state oluşur. Causal metadata dependency'yi taşır. Consumer dependency karşılanana kadar event'i bekletebilir.

Happens-Before

Happens-before relation bir operation'ın başka operation'dan mantıksal olarak önce geldiğini tanımlar. Aynı process'teki sıra ve message send-receive ilişkileri causal edge oluşturur. Concurrent operation'lar arasında edge bulunmayabilir. Logical clocks bu relation hakkında bilgi taşır. Global wall clock zorunlu değildir.

Lamport Clock

Lamport clock her event'e monoton logical number verir. Causal relation varsa timestamp order bunu yansıtır. Ters yönde büyük timestamp doğrudan causality kanıtı değildir. Tie-breaker ile total ordering üretilebilir. Simple distributed ordering ve debugging için değerlidir.

Vector Clock

Vector clock birden fazla participant'ın logical progress bilgisini taşır. İki version'ın causal mı concurrent mı olduğu daha iyi anlaşılabilir. Metadata node sayısıyla büyüyebilir. Leaderless database conflict detection için tarihsel olarak kullanılmıştır. Domain-specific version vectors daha kontrollü ölçek sağlayabilir.

Sosyal Ağ ve İşbirliği Uygulamaları

Reply'nin parent message'dan önce görünmemesi kullanıcı beklentisidir. Collaborative document changes dependency taşıyabilir. Causal consistency global linearizability olmadan bu ordering'i koruyabilir. Independent users aynı anda farklı alanları değiştirebilir. Merge conflict-free ise latency ve availability avantajı elde edilir.

CAP Teoremi Gerçekte Ne Söyler?

CAP theorem network partition bulunduğunda distributed system'in her request'e available response vermek ile linearizable benzeri güçlü consistency'yi aynı anda garanti edemeyeceğini anlatır. “Üç özellikten herhangi ikisini seç” sloganı bu nedenle eksiktir. Normal durumda partition yokken C ve A arasında aynı zorunlu seçim bulunmaz. Gerçek karar partition yaşandığında hangi operation'ların reddedileceği veya stale/çatışmalı state kabul edilip edilmeyeceğidir. CAP'teki consistency ifadesi ACID consistency ile de aynı kavram değildir.

Consistency

CAP bağlamında consistency her read'in en güncel write'ı görmesi veya hata alması şeklinde güçlü single-copy davranışla ilişkilidir. Bu kullanım business constraint anlamındaki ACID consistency değildir. Partition sırasında iki taraf independent write kabul ederse bu garanti bozulabilir. CP sistem minority tarafında request reddedebilir. Correctness gereksinimi bu kararı haklı çıkarabilir.

Availability

CAP availability her non-failing request'in response almasını ister. Response mutlaka en güncel data olmak zorunda değildir. Partitioned node local state ile cevap verebilir. Sistem availability'yi korurken conflict resolution'ı sonraya bırakabilir. Business operation buna uygun değilse “response vermek” doğru ürün davranışı olmayabilir.

Partition Tolerance

Distributed network'te partition ihtimali tamamen ortadan kaldırılamaz. Bu nedenle P gerçek sistemlerde çoğu zaman seçim değil ortam gerçeğidir. Network links, routers veya region connectivity fail olabilir. System design bu duruma nasıl tepki vereceğini belirler. Tek data center bile network partition'dan muaf değildir.

Network Partition Sırasında C veya A Tercihi

Payment ownership gibi operation consistency seçebilir ve quorum olmayan tarafta request reddedebilir. Social like counter local write kabul edip daha sonra merge ederek availability seçebilir. Aynı application iki farklı davranışı kullanabilir. Karar operation bazında verilmelidir. CAP product design'a doğrudan business trade-off olarak çevrilmelidir.

“Üçünden İkisini Seç” Neden Eksik Bir Açıklamadır?

Partition tolerance dağıtık network'te kaçınılmaz olduğundan üçlü seçim menüsü gibi düşünmek yanlış yönlendirir. Ayrıca partition olmayan normal zamanda hem consistency hem availability sağlanabilir. Asıl teori failure koşulundaki imkansızlık sınırını gösterir. Latency konusu CAP'in merkezinde değildir. Bu eksikliği PACELC günlük operation maliyetini düşünmeye yardımcı olarak tamamlar.

CAP'teki Consistency ile ACID Consistency Farkı

CAP consistency distributed read/write visibility ile ilgilidir. ACID consistency transaction'ın domain ve database constraints'i korumasıdır. Bir sistem CAP açısından eventual olup local ACID transaction'lar sunabilir. Cassandra veya event-driven architecture bunun örneklerini gösterebilir. Terminoloji karışmaması için dokümantasyonda model adı açık yazılmalıdır.

PACELC Teoremi Nedir?

PACELC partition olduğunda availability ile consistency arasındaki kararı, partition yokken ise latency ile consistency arasındaki günlük trade-off'u hatırlatır. Strong cross-region consistency yalnızca failure gününde değil her normal write'ta remote coordination maliyeti ödetebilir. Bu nedenle global sistem tasarımında CAP'ten daha operasyonel bir çerçeve sunar. Sistem partition sırasında C seçip normal zamanda düşük latency için daha zayıf read consistency kullanabilir. Model gerçek ürün gereksinimini tek etiketten daha ayrıntılı düşünmeye yardım eder.

Partition Durumunda Availability vs Consistency

P bölünme durumunu temsil eder. Partition varsa sistem consistency veya availability önceliğini operation bazında belirler. Minority region payment write'ı reddedebilir. Feed service local read sunmaya devam edebilir. Aynı platform farklı data sınıflarında farklı seçimler yapabilir.

Normal Durumda Latency vs Consistency

Network sağlıklı olduğunda da remote acknowledgement beklemek latency getirir. Local read çok hızlıdır ancak global latest value guarantee vermeyebilir. Synchronous multi-region write daha güçlü guarantee sağlar. Kullanıcı latency bütçesi bu bedeli taşıyıp taşımadığını belirler. Global coordination her data için default olmamalıdır.

Cross-Region Coordination Maliyeti

İstanbul ile uzak bir region arasındaki fiziksel RTT belirli alt sınır taşır. Consensus message round'ları bu süreyi transaction path'e ekler. Tail latency network variation nedeniyle daha da artabilir. Home-region routing bunu azaltabilir. Global uniqueness gibi invariant'lar yine cross-region coordination isteyebilir.

Consistency'nin Günlük Latency Bedeli

Strong guarantee yalnızca disaster sırasında çalışan ekstra özellik değildir. Her operation quorum veya leader confirmation bekliyorsa kullanıcı sürekli bu maliyeti öder. Read lease veya follower snapshot bazı read'lerde optimizasyon sağlayabilir. SLO ölçümü consistency seviyesine göre ayrı yapılmalıdır. Business değeri olmayan strong guarantee kaldırılabilir.

CAP ve PACELC Birlikte Nasıl Kullanılır?

CAP failure zamanındaki sınırı açıklar. PACELC normal zaman performansını da karar tablosuna ekler. Önce partition sırasında operation'ın devam edip etmeyeceği belirlenir. Sonra normal durumda kaç remote round-trip kabul edildiği tanımlanır. Bu iki çerçeve birlikte multi-region architecture tartışmasını daha somut hale getirir.

Consistency Modeli Nasıl Seçilir?

Consistency model seçimi teknoloji listesiyle değil failure etkisiyle başlamalıdır. Stale read kullanıcıya yalnızca eski görsel mi gösterir, yoksa yanlış finansal karar mı verdirir sorusu önemlidir. Veri kaybı, availability ve latency hedefleri ayrı değerlendirilmelidir. Cross-region requirement coordination maliyetini değiştirir. Sonuç operation bazlı seçim matrisiyle belgelenmelidir.

Stale Read'in İş Etkisi

Bir ürün başlığının üç saniye eski olması düşük etkili olabilir. Permission revocation'ın üç saniye eski olması güvenlik riski oluşturabilir. Staleness severity data classification'a eklenmelidir. Maximum stale window business owner tarafından onaylanmalıdır. Technical SLO bu sınırı ölçmelidir.

Veri Kaybının İş Etkisi

Like counter'dan birkaç update kaybı ile financial transfer kaybı aynı değildir. Durability requirement replication strategy'yi belirler. Synchronous acknowledgement daha az data-loss window sağlar. Event log ve audit trail recovery'yi kolaylaştırır. Critical mutation için acknowledgement semantics açık olmalıdır.

Availability Gereksinimi

Her operation outage sırasında çalışmak zorunda değildir. Checkout write dururken catalog read devam edebilir. Admin reporting daha düşük availability hedefi taşıyabilir. Priority class failure behavior'ı sadeleştirir. Availability SLO consistency ile birlikte yazılmalıdır.

Latency Gereksinimi

Interactive user operation düşük p99 hedefi ister. Batch reconciliation saniyeler sürebilir. Global consensus interactive path'e pahalı olabilir. Async workflow latency'yi kullanıcı response'undan çıkarabilir. Her step'in deadline'ı ayrı tanımlanmalıdır.

Cross-Region Gereksinimi

Kullanıcılar birden fazla kıtadaysa local read önemli hale gelir. Global write authority tek region'da tutulursa uzak writes yavaşlar. Multi-writer conflict resolution ihtiyacını artırır. Geo-partitioning user veya tenant home region üzerinden denge kurabilir. Disaster failover data freshness requirement ayrıca planlanmalıdır.

Consistency Model Selection Matrix

Her operation için invariant, stale tolerance, durability, availability ve latency sütunları oluşturulabilir. Payment strong ve durable, recommendation eventual ve highly available olarak işaretlenebilir. Profile read-your-writes alabilir. Catalog bounded staleness kullanabilir. Bu matrix architecture kararını “database tercihi” seviyesinden business requirement seviyesine taşır.

Aynı Uygulamada Birden Fazla Consistency Modeli Kullanılabilir mi?

Evet, hatta büyük sistemlerde bu daha sağlıklı yaklaşımdır. Payment ve inventory aynı risk sınıfında değildir. Recommendation veya catalog global strong ordering gerektirmez. User profile kendi değişikliğini hemen göstermeyi isteyebilir. Consistency per operation yaklaşımı gereksiz coordination maliyetini azaltır.

Payment için Strong

Payment duplicate charge ve yanlış status riskine sahiptir. Idempotency ve authoritative transaction kullanılır. External provider state reconciliation ile doğrulanır. Event projections eventual olabilir. Source payment record güçlü korunur.

Inventory için Strong

Final reservation sırasında stock invariant korunmalıdır. Atomic conditional update kullanılır. Catalog display count stale olabilir. Reservation expiration workflow ayrı çalışır. Strong guarantee yalnızca allocation path'te uygulanabilir.

Product Catalog için Eventual

Catalog content region'lara asenkron dağıtılabilir. Update birkaç saniye sonra görünse çoğu durumda kabul edilebilir. CDN ve cache staleness ayrıca bulunabilir. Version timestamp kullanıcı veya operator'a freshness gösterebilir. Critical price check ayrı servis tarafından yapılabilir.

Recommendation için Eventual

Recommendation sonuçları model refresh dönemlerine bağlıdır. Exact real-time state gerekmez. Stale candidate user experience'ı sınırlı etkileyebilir. Deleted veya unavailable item serving sırasında filtrelenebilir. Availability ve latency burada consistency'den daha önemli olabilir.

User Profile için Read-Your-Writes

Kullanıcı adını değiştirdikten sonra yeni adı hemen görmek ister. Diğer region'lar birkaç saniye sonra güncellenebilir. Write response yeni state'i döndürebilir. Session primary'ye pinlenebilir. Böylece global strong consistency maliyetine gerek kalmaz.

Consistency per Operation

Aynı entity içinde bile operation farklı guarantee taşıyabilir. Profile read eventual, password change strong authorization invalidation isteyebilir. Architecture API contract consistency level'ı belirtebilir. Data store seçimi bu operation requirements'ı desteklemelidir. Tek global consistency etiketi gerçek sistemi fazla basitleştirir.

Replication Veri Tutarlılığını Nasıl Etkiler?

Replication availability ve read scaling sağlar fakat replica sayısını artırmak otomatik strong consistency anlamına gelmez. Primary-follower model ordering'i leader üzerinden sadeleştirir. Leaderless model write'ı birden fazla replica'ya dağıtır ve version resolution gerektirir. Synchronous replication write latency'sini yükseltirken stale ve loss window'u azaltabilir. Asynchronous replication düşük latency karşılığında lag üretir.

Primary–Replica

Primary write authority olarak görev yapar. Replicas değişiklikleri primary'den alır. Read replicas stale olabilir. Failover sırasında yeni primary'nin ne kadar güncel olduğu önemlidir. PostgreSQL gibi sistemlerde synchronous standby seçimi loss window'u azaltabilir.

Leader–Follower

Leader-follower aynı temel modeli farklı terminolojiyle ifade eder. Leader operation ordering için merkezi nokta sağlar. Followers read scaling veya failover için kullanılır. Leader failure election gerektirir. Stale leader fencing ile write yapmaktan alıkonmalıdır.

Leaderless Replication

Client veya coordinator write'ı birden fazla replica'ya gönderebilir. Tek permanent leader yoktur. Concurrent version'lar oluşabilir. Read quorum ve repair divergence'ı azaltır. Conflict resolution data modelinin önemli parçasıdır.

Synchronous Replication

Write response verilmeden belirli remote replica acknowledgement beklenir. PostgreSQL güncel belgelerinde quorum tabanlı synchronous standby configuration bu amaçla kullanılabilir. Latency network'e bağlı olarak yükselir. Standby erişilemezse commit bekleyebilir veya policy'ye göre availability etkilenir. Critical durability için değerli olabilir.

Asynchronous Replication

Primary local commit sonrası daha hızlı response verebilir. Follower data'yı sonra alır. Read replica stale kalabilir. Primary kaybında henüz replicated olmayan writes kaybolabilir. Lower latency ve higher write availability karşılığında bu risk kabul edilir.

Replication Lag

Lag primary state ile follower state arasındaki gecikmedir. Byte, log position veya time olarak ölçülebilir. Read-your-writes ve failover correctness üzerinde etkisi vardır. SLO aşılırsa replica read routing durdurulabilir. Lag sürekli izlenmelidir.

Synchronous ve Asynchronous Replication Arasındaki Fark

Temel fark client'ın write success almadan önce replica confirmation beklenip beklenmemesidir. Synchronous model durability ve freshness avantajı sağlar. Asynchronous model latency ve availability açısından daha esnektir. Multi-region network bu farkı daha belirgin hale getirir. İki model aynı sistemde farklı data sınıflarında birlikte kullanılabilir.

Write Acknowledgement

Synchronous write required replicas acknowledgement vermeden tamamlanmaz. Async write primary local commit sonrası dönebilir. Ack semantics documentation'da açık olmalıdır. “Write successful” ifadesinin neyi garanti ettiği bilinmelidir. Client retry buna göre tasarlanır.

Latency

Synchronous replication en yavaş gerekli replica'nın network ve disk süresini bekleyebilir. Async model bu beklemeyi request path'ten çıkarır. Cross-region deployment farkı büyütür. p99 latency özellikle önemlidir. Business durability bu latency bedeliyle birlikte değerlendirilir.

Availability

Synchronous quorum kaybolursa write progress durabilir. Async primary tek başına write kabul etmeye devam edebilir. Bunun karşılığında failover loss riski vardır. Critical operation consistency için availability bilinçli olarak azaltılabilir. Read availability ayrı değerlendirilebilir.

Stale Read

Asynchronous follower eski value döndürebilir. Sync replication her read'in automatically latest olacağı anlamına gelmez, read routing ve apply level önemlidir. PostgreSQL'de acknowledgement seviyesi receipt, flush veya apply davranışına göre değişebilir. Application required guarantee'yi net tanımlamalıdır. Replica health state kullanılarak routing yapılabilir.

Veri Kaybı Penceresi

Primary write follower'a ulaşmadan crash olursa asynchronous model acknowledged write'ı kaybedebilir. Window replication lag ile ilişkilidir. Sync ack required replicas'a ulaştığında risk azalır. Simultaneous failure yine dikkate alınmalıdır. RPO hedefi replication mode seçimini etkiler.

Multi-Region Trade-Off

Remote region sync ack durability sağlar fakat WAN latency ödetir. Async geo-replication local write'ı hızlandırır. Disaster sırasında birkaç saniyelik RPO kabul edilebilir olabilir. Financial ledger için daha güçlü policy seçilebilir. Region topology business riskle uyumlu olmalıdır.

Quorum Nedir?

Quorum replicated data üzerinde belirli sayıda replica acknowledgement kullanarak read ve write güvenilirliğini ayarlama yaklaşımıdır. Cassandra gibi leaderless modellere sahip sistemlerde consistency level operation bazında seçilebilir. N replication factor, W write acknowledgement sayısı ve R read response sayısı olarak düşünülür. R ile W'nin kesişmesi yeni write'ı okuyan en az bir replica bulunma ihtimalini güçlendirir. Ancak basit R + W > N formülü tek başına linearizability garantisi değildir.

Replication Factor N

N verinin kaç replica üzerinde tutulduğunu ifade eder. N büyüdükçe fault tolerance artabilir. Storage ve replication cost da yükselir. Multi-datacenter placement failure domain'leri ayırmalıdır. N tek başına consistency level değildir.

Write Quorum W

Write başarılı sayılmadan kaç replica'nın acknowledgement vermesi gerektiğini gösterir. W yüksekse durability ve read intersection güçlenir. Availability daha fazla node gerektirir. Local quorum WAN latency'sini azaltabilir. Ack'in disk mi memory mi temsil ettiği engine semantics'ine bağlıdır.

Read Quorum R

Read kaç replica'dan state toplayacağını ifade eder. Higher R daha fazla network işi oluşturur. Version reconciliation newest candidate'ı seçebilir. Read repair divergence'ı düzeltebilir. Client latency en yavaş required response'tan etkilenir.

R + W > N

Bu eşitsizlik read ve write replica set'lerinin en az bir node üzerinde kesişmesini amaçlar. Böylece read latest write'a ait bir replica görebilir. Fakat concurrent writes, sloppy quorum ve version ordering ayrıntıları sonucu etkiler. Quorum intersection yalnızca bir yapı taşıdır. Strong model iddiası engine protocol'ünün tamamına bağlıdır.

Quorum Intersection

İki quorum set'in ortak replica taşıması bilgi transferini mümkün kılar. Consensus majority yaklaşımı da intersection özelliğinden faydalanır. Ancak read/write quorum ile consensus aynı mekanizma değildir. Replica response'larının nasıl reconcile edildiği önemlidir. Stale coordinator veya concurrent version problem yaratabilir.

Tunable Consistency

Cassandra operation başına ONE, QUORUM veya ALL gibi seviyeler seçmeye imkan verir. Güncel Cassandra belgeleri SERIAL ve LOCAL_SERIAL seviyelerini conditional Paxos phase için ayrıca tanımlar. Böylece aynı cluster farklı operation'larda farklı trade-off kullanabilir. Critical write daha güçlü seviyede çalışabilir. Analytics read daha düşük consistency tercih edebilir.

Quorum Her Zaman Strong Consistency Sağlar mı?

Hayır, quorum kelimesini görmek linearizability garantisi bulunduğu anlamına gelmez. Concurrent writes hangi version'ın newest kabul edileceği sorusunu doğurur. Sloppy quorum aynı replica set'in kesişmesini bozabilir. Wall-clock timestamp conflict resolution clock skew'dan etkilenebilir. Strong consistency için protocol'ün write ordering ve read validation davranışı bütünüyle incelenmelidir.

Concurrent Writes

İki client aynı key'e farklı value yazabilir. Her ikisi farklı replica kombinasyonlarından quorum alabilir. Sistem version resolution yapmalıdır. Last-write-wins birini sessizce kaybedebilir. Conditional write daha güçlü semantics sağlayabilir.

Sloppy Quorum

Normal replica unavailable olduğunda geçici başka node'lar write saklayabilir. Availability artar. Ancak classic quorum intersection property zayıflayabilir. Hinted handoff normal owner döndüğünde data taşır. Bu model linearizable read garantisini otomatik vermez.

Version Resolution

Replica'lar farklı value döndürdüğünde coordinator hangisinin geçerli olduğuna karar verir. Timestamp, vector clock veya domain merge kullanılabilir. Yanlış resolution valid update'i kaybedebilir. Deterministic rule convergence sağlar. Business correctness ayrıca değerlendirilmelidir.

Clock Skew

Timestamp tabanlı newest-value seçiminde saat farkı eski write'ı yeni gösterebilir. NTP hatası küçük olsa bile concurrent window'da yeterli olabilir. Logical version daha güvenli olabilir. Client supplied timestamp özellikle risklidir. LWW kullanılacaksa data-loss semantiği bilinmelidir.

Quorum ile Linearizability Arasındaki Fark

Quorum replica response sayısını ifade eden mekanizmadır. Linearizability observable history üzerinde correctness modelidir. Bir sistem quorum kullanıp linearizable olmayabilir. Consensus protocol quorum intersection kullanarak linearizable replicated state machine sağlayabilir. Mekanizma ile garanti birbirinden ayrılmalıdır.

Leaderless Replication'da Veri Nasıl Onarılır?

Leaderless replication farklı replica'ların geçici olarak farklı version taşımasını kabul edebilir. Bu farkların sonsuza kadar kalmaması gerekir. Read repair client read sırasında divergence'ı düzeltebilir. Anti-entropy background karşılaştırmayla eksik version'ları bulur. Hinted handoff geçici node failure sonrası writes'ı asıl replica'ya geri taşır.

Read Repair

Read birden fazla replica'dan farklı version aldığında coordinator newest value'yu belirler. Eski replica güncellenebilir. Bu işlem foreground veya background olabilir. Read latency etkilenebilir. Sadece okunan key'lerin repair edilmesi yeterli coverage sağlamayabilir.

Anti-Entropy

Background süreç replicas arasındaki data ranges'i karşılaştırır. Hash tree veya benzer summary structures fark bulmayı kolaylaştırır. Missing veya divergent data onarılır. Düzenli çalışmazsa cold keys uzun süre inconsistent kalabilir. Repair maintenance planına dahil edilmelidir.

Hinted Handoff

Target replica unavailable olduğunda başka node write için hint saklayabilir. Replica geri döndüğünde hint ile update gönderilir. Availability artar. Uzun outage hint retention'ı aşabilir. Full repair yine gerekebilir.

Background Repair

Scheduled repair bütün keyspace veya token ranges üzerinde çalışır. Büyük cluster'da I/O ve network tüketir. Rolling schedule kullanılabilir. Repair backlog consistency riskini artırır. Monitoring age ve completion rate takip etmelidir.

Replica Divergence Monitoring

Repair yalnızca çalışıyor görünmekle yeterli değildir. Mismatch count veya repair age metriği izlenmelidir. Read repair spike underlying issue gösterebilir. Node replacement sonrası divergence riski artar. SLO maximum unrepaired window tanımlamalıdır.

Consensus Nedir?

Consensus birden fazla node'un failure ve network belirsizliği altında ortak bir karar veya operation ordering üzerinde anlaşmasını sağlayan protocol ailesidir. Leader election, replicated log ve configuration changes temel kullanım alanlarıdır. Majority intersection aynı anda iki farklı committed history oluşmasını engellemeye yardım eder. Consensus data replication ile ilişkili olsa da her replication sistemi consensus kullanmaz. Metadata, lock ownership ve strong write ordering için kritik olabilir.

Neden Consensus Gereklidir?

Bir cluster'da hangi node leader sorusuna tek cevap gerekir. İki leader aynı anda write authority taşırsa split-brain oluşabilir. Consensus majority agreement ile authoritative history belirler. Node crash sonrasında committed entries korunur. Minority partition progress sağlayamayabilir.

Leader Election

Current leader failure olduğunda yeni leader seçilir. Election term veya epoch ile versionlanır. Majority support alan candidate authority kazanır. Eski leader geri döndüğünde yeni term'i görüp step down etmelidir. Fencing stale authority'yi sınırlar.

Replicated Log

Client operations ordered log entries olarak leader tarafından eklenir. Followers log'u kopyalar. Majority üzerinde güvenli hale gelen entries commit edilir. State machine aynı order'da apply eder. Deterministic processing replicas'ın aynı state'e ulaşmasını sağlar.

Majority Agreement

Majority quorum'lar birbirleriyle kesişir. İki farklı majority aynı term içinde tamamen bağımsız olamaz. Bu property committed history'nin korunmasına yardım eder. Node sayısı genellikle tek sayılı seçilir. Daha fazla node fault tolerance artışı yanında latency ve operational cost getirir.

Terms / Epochs

Term veya epoch leadership dönemini monoton numarayla temsil eder. Yeni leader daha yüksek dönem numarası taşır. Eski leader message'ları stale olarak reddedilebilir. Fencing token aynı fikri external resources'a taşır. Wall clock yerine logical authority version kullanılır.

Raft, Paxos ve Zab

Raft, Paxos ve Zab dağıtık agreement ve ordering problemlerini farklı protocol tasarımlarıyla çözen yaklaşımlardır. Hepsini “aynı algoritma” olarak görmek doğru değildir. Raft anlaşılabilir leader-based replicated log modeliyle yaygın olarak öğretilir. Paxos bir consensus ailesidir ve birçok farklı uygulama varyantına sahiptir. Zab ise ZooKeeper'ın primary-backup atomic broadcast ihtiyaçlarına göre tasarlanmıştır.

Raft

Raft replicated state machine için leader-based consensus protocol'üdür. Operation'lar leader üzerinden log'a girer. Terms leader generation'ını belirtir. Majority replication commit kararında kullanılır. Membership ve snapshot gibi konular production implementation'da ayrıca önemlidir.

Leader Election

Follower belirli sürede leader heartbeat almazsa election başlatabilir. Candidate term'i artırır ve votes ister. Majority alan candidate leader olur. Randomized election timeout simultaneous election ihtimalini azaltır. Stale log taşıyan candidate vote kurallarıyla sınırlandırılır.

Log Replication

Leader client command'ını kendi log'una ekler. Append entries mesajıyla followers'a gönderir. Log consistency check follower history'sini leader ile hizalar. Majority replicated entry commit edilebilir. Followers committed index'e kadar state machine apply eder.

Commit Index

Commit index hangi log entry'lerinin güvenli biçimde committed olduğunu belirtir. Leader bu bilgiyi followers'a taşır. Applied state commit index'i takip eder. Uncommitted entries leader değişiminde overwrite edilebilir. Client success semantics yalnızca committed entry üzerine kurulmalıdır.

Paxos

Paxos dağıtık consensus için klasik algoritma ailesidir. Proposer, acceptor ve learner rolleri üzerinden value agreement kurar. Ballot veya proposal number stale proposals'ı ayırır. Multi-Paxos stable leader ile repeated consensus'u daha verimli hale getirir. Conditional write kullanan bazı distributed database'lerde Paxos tabanlı protocol bulunabilir.

Zab

Zab ZooKeeper için atomic broadcast ve crash recovery odaklı protocol'dür. Leader ordered proposals'ı followers'a yayar. Epoch leadership generation'ını temsil eder. ZooKeeper metadata coordination kullanımında güçlü consistency semantics sağlar. Application data store olarak kullanılması genellikle amaç değildir.

Consensus Algoritması Ne Zaman Gerekir?

Cluster leader, distributed configuration veya globally ordered metadata gibi kararlar consensus gerektirebilir. Her application event'i için doğrudan kendi consensus protocol'ünüzü yazmak doğru değildir. Existing database veya coordination service bu problemi çözebilir. Consensus operation latency ve quorum availability maliyeti taşır. Business requirement daha zayıf modelle çözülebiliyorsa daha sade yaklaşım seçilmelidir.

Quorum ile Consensus Arasındaki Fark

Quorum genel olarak belirli sayıda node response'u kullanma tekniğidir. Consensus ise node'ların ortak karar veya ordered history üzerinde anlaşmasını sağlayan protocol problemidir. Consensus protocol'leri quorum intersection kullanabilir. Leaderless read/write quorum ise consensus olmadan çalışabilir. Bu ayrım architecture tartışmalarında “quorum kullanıyoruz, o halde consensus var” gibi yanlış çıkarımları önler.

Replica Read/Write Quorum

Read ve write operation belirli replica sayısından response toplar. Data reconciliation client veya coordinator tarafından yapılır. Permanent leader bulunmayabilir. Tunable consistency mümkündür. Operation ordering global consensus kadar güçlü olmayabilir.

Global Decision

Consensus bir value, leader veya log entry üzerinde tek karar üretmeye çalışır. İki conflicting committed decision oluşmamalıdır. Majority intersection safety sağlar. Minority availability kaybedebilir. Global decision metadata açısından kritik olabilir.

Operation Ordering

Replicated log consensus operation'ları aynı sıra içinde tutar. Read/write quorum yalnızca versions toplayabilir. Concurrent writes resolve edilmeyi bekleyebilir. Ordering guarantee data modeline bağlıdır. Business workflow global ordering istemeyebilir.

Leader Election

Consensus protocols leader election için kullanılabilir. Quorum read/write model permanent leader gerektirmeyebilir. Leader authority term ile korunur. Election failure availability'yi etkiler. Client topology refresh yeni leader'ı öğrenmelidir.

Kullanım Senaryosu Karşılaştırması

Leaderless user-content store tunable quorum ile çalışabilir. Cluster metadata veya distributed lock ownership consensus isteyebilir. Global sequence generation strong authority gerektirir. Recommendation cache quorum bile gerektirmeyebilir. Problem türü mekanizmayı belirlemelidir.

Split-Brain Nedir?

Split-brain network partition sonrası birden fazla tarafın aynı resource üzerinde leader veya write authority olduğunu düşünmesi durumudur. İki taraf da writes kabul ederse histories diverge eder. Network düzeldiğinde hangi state'in doğru olduğu belirsizleşebilir. Quorum ve epochs tek active authority sağlamaya yardım eder. External side effect'lerde fencing stale leader'ın işlem yapmasını engellemek için gereklidir.

Network Partition Sonrası İki Lider

Eski leader network'ten izole olabilir fakat crash olmamıştır. Diğer nodes yeni leader seçebilir. Eski leader client traffic almaya devam ederse iki authority oluşur. Term bilgisi cluster içi message'ları reddedebilir. External database veya storage eski leader'ın term'ini bilmiyorsa fencing gerekir.

Concurrent Writes

İki leader aynı entity'ye farklı value yazabilir. Replicas partition sides üzerinde ayrılır. Merge sonrası conflict resolution gerekir. LWW data loss yaratabilir. Critical invariant için writes minority tarafta durdurulmalıdır.

Replica Divergence

Partition boyunca replica histories farklılaşır. Reconnection tek başına hangi version'ın doğru olduğunu belirlemez. Consensus committed log varsa authoritative branch bulunabilir. Leaderless model merge veya repair uygular. Divergence metric incident sonrası izlenmelidir.

Quorum ile Split-Brain Önleme

Majority required olduğunda iki partition aynı anda majority olamaz. Yalnızca bir taraf progress sağlar. Minority leader write authority kaybetmelidir. Cluster membership doğru tanımlanmalıdır. İki-node setup failure tolerance açısından zayıftır.

Fencing Token

Her leadership veya lease acquisition monoton token üretir. External resource en yüksek token'dan eski request'leri reddeder. Stale process çalışmaya devam etse bile side effect yapamaz. Token storage authoritative olmalıdır. Basit lock ownership string'i ordering sağlamaz.

Epoch / Term

Epoch leader generation'ını versionlar. Her election daha yüksek epoch üretir. Messages eski epoch'tan geliyorsa reddedilir. State transition logs epoch bilgisini taşır. Debugging sırasında hangi leader'ın hangi dönemde çalıştığı anlaşılır.

Distributed Lock Kullanmak Veri Tutarlılığını Sağlar mı?

Distributed lock belirli critical section'a aynı anda tek participant girmesini sağlamaya çalışır. Bu useful bir coordination primitive olsa da bütün veri tutarlılığı problemlerini çözmez. Lease expire olabilir, process pause yaşayabilir ve lock sahibi authority'sini kaybedebilir. External system stale lock holder operation'ını kabul edebilir. Fencing ve idempotency olmadan yalnızca lock'a güvenmek risklidir.

Distributed Mutex

Mutex aynı resource üzerinde concurrent execution'ı sınırlar. Distributed ortamda lock state remote consensus veya storage üzerinde tutulur. Network failure lock owner bilgisini belirsiz hale getirebilir. Critical section kısa tutulmalıdır. Business correctness mümkünse database constraint ile ayrıca korunmalıdır.

Lease

Lease belirli süre geçerli ownership hakkıdır. Holder süre içinde operation yapabilir. Süre bittiğinde başka process ownership alabilir. Clock veya pause sorunları stale holder yaratabilir. Lease renewal fail durumunda process güvenli biçimde durmalıdır.

Lock Expiration

Expiration crashed holder yüzünden sonsuz lock oluşmasını engeller. Çok kısa timeout valid operation sırasında expire olabilir. Çok uzun timeout recovery'yi geciktirir. Work p99 duration temel alınabilir. Dynamic extension owner identity kontrolüyle yapılmalıdır.

Stale Lock Holder

Process uzun GC pause sonrası geri dönebilir. Bu sırada lease expire olmuş ve yeni owner seçilmiş olabilir. Eski process hâlâ lock sahibi olduğunu düşünebilir. Fencing token external store tarafından reject edilmelidir. Application yalnızca local timer'a güvenmemelidir.

Fencing Token

Monoton token her new lease ile artar. Resource en son gördüğü token'dan küçük request'i reddeder. Böylece stale holder side effect yapamaz. Token lock service tarafından güvenli sırada üretilmelidir. Bu pattern distributed file processing ve external writer ownership için değerlidir.

Distributed Lock'ın Çözmediği Problemler

Lock duplicate network delivery'yi ortadan kaldırmaz. External API'nin partial success durumunu çözmez. Message ordering ve reconciliation yine gerekir. Database integrity constraint'in yerini almamalıdır. Lock concurrency azaltan araçtır, end-to-end correctness sistemi değildir.

Optimistic Concurrency Control

Optimistic concurrency control aynı kaydı birden fazla client'ın çoğu zaman conflict olmadan değiştireceğini varsayar. Read sırasında version alınır. Write yalnızca version hâlâ aynıysa kabul edilir. Conflict varsa operation retry veya user merge akışına girer. Low contention workload'larda lock bekleme maliyetini azaltır.

Version Number

Row her update'te artan version taşır. Client version 5'i okur ve update sırasında “version hâlâ 5 ise yaz” koşulu gönderir. Başka writer version 6 yaptıysa update sıfır row etkiler. Conflict görünür hale gelir. Wall clock gerekmez.

Compare-and-Swap

CAS mevcut value beklenen state ile eşleşiyorsa yeni value yazar. Atomic operation concurrency race'i önler. Distributed store linearizable CAS sunuyorsa coordination primitive olarak kullanılabilir. Retry loop bounded olmalıdır. High contention sürekli CAS failure oluşturabilir.

ETag / If-Match

HTTP API resource version ETag ile dönebilir. Client update sırasında If-Match header kullanır. Server resource değişmişse precondition failure verir. Kullanıcı conflict resolution yapabilir. REST API'lerde optimistic concurrency için doğal pattern'dir.

Concurrent Update Detection

İki writer aynı base version'dan başlarsa yalnızca biri başarı alır. Diğeri silent overwrite yapmak yerine conflict görür. Domain farklı field'ları merge edebilir. Bazı operation commutative ise retry yeni state üzerinden yapılabilir. Conflict rate metric contention seviyesini gösterir.

Retry

Conflict sonrası state yeniden okunur. Operation business intent yeni state'e uygulanır. Blind same payload retry stale overwrite yapmamalıdır. Max retry sayısı bounded tutulur. Kullanıcı edit formunda manual merge gerekebilir.

High Contention Trade-Off

Aynı counter'a binlerce concurrent update geliyorsa optimistic retries çok artabilir. Pessimistic lock veya atomic increment daha iyi olabilir. Conflict rate yükseldiğinde CPU ve network israfı oluşur. Sharded counter başka çözüm sunabilir. Data access pattern lock stratejisini belirlemelidir.

Pessimistic Locking

Pessimistic locking conflict ihtimalini baştan kabul eder ve operation öncesi resource üzerinde lock alır. Row lock local database transaction içinde güçlü araçtır. Distributed lock network ve lease riskleri ekler. Lock wait latency ve deadlock ihtimali yaratır. High contention critical section için optimistic retry'dan daha predictable olabilir.

Row Lock

Database SELECT FOR UPDATE benzeri yöntemle row'u transaction boyunca kilitleyebilir. Diğer writer bekler veya error alır. Local ACID transaction içinde semantics güçlüdür. Lock süresi kısa tutulmalıdır. External API call lock içindeyken yapılmamalıdır.

Distributed Lock

Birden fazla service process aynı external resource için lock kullanabilir. Lock service yüksek availability ve strong semantics istemelidir. Lease expiration stale owner riski getirir. Fencing eklenmelidir. Database constraint mümkünse final safety guard olarak kalmalıdır.

Lock Wait

Resource meşgulse request bekler. Queue uzunluğu latency'yi artırır. Timeout dead request'lerin sonsuza kadar beklemesini engeller. Priority inversion düşünülebilir. Monitoring wait duration ve timeout rate takip etmelidir.

Deadlock

Transaction A resource X'i, B resource Y'yi tutup birbirini bekleyebilir. Database deadlock detector transaction'lardan birini abort edebilir. Consistent lock ordering riski azaltır. Distributed locks'ta detection daha zor olabilir. Multi-resource lock sayısı minimum tutulmalıdır.

Throughput Etkisi

Lock aynı resource üzerinde parallelism'i sınırlar. Critical section uzadıkça throughput düşer. Read/write separation yardımcı olabilir. Sharding contention'ı dağıtabilir. Correctness için gerekli serialization bilinçli biçimde uygulanmalıdır.

Optimistic vs Pessimistic Karar Matrisi

Low conflict ve read-heavy workload optimistic model için uygundur. High contention ve short critical operation pessimistic lock ile daha iyi çalışabilir. Conflict çözümü pahalıysa önceden lock almak değerlidir. User edits gibi uzun interactions lock altında tutulmamalıdır. Gerçek contention metrics seçim için kullanılmalıdır.

Dağıtık Transaction Nedir?

Dağıtık transaction tek business operation'ın birden fazla bağımsız transactional resource üzerinde değişiklik yapmasıdır. Local ACID transaction tek database içinde kolay atomicity sağlar. Database-per-service mimarisinde payment, order ve inventory ayrı store'larda olabilir. Her step bağımsız failure yaşayabilir. Bu nedenle global atomicity için 2PC veya Saga gibi farklı modeller değerlendirilir.

Tek ACID Transaction'ın Sınırları

Local transaction yalnızca aynı transaction manager'ın kontrol ettiği resource'ları güvenilir biçimde kapsar. Remote HTTP service doğal olarak aynı database transaction'a katılmaz. Connection açık tutarak external call beklemek lock ve timeout riski yaratır. Business workflow daha uzun süreli olabilir. Local atomicity ile distributed process lifecycle ayrılmalıdır.

Database-per-Service

Her service kendi schema ve data ownership'ini taşır. Independent deployment ve scaling kolaylaşır. Cross-service join ve transaction zorlaşır. Event veya API ile integration gerekir. Consistency boundary service decomposition ile yakından ilişkilidir.

Bir Business İşleminin Birden Fazla Servisi Güncellemesi

Order create inventory reserve ve payment authorize adımları isteyebilir. Üçü tek database transaction içinde değildir. İlk ikisi başarılı üçüncü başarısız olabilir. Workflow partial state'i yönetmelidir. Compensation veya retry business semantics'e göre uygulanır.

Partial Failure Problemi

Distributed operation'ın bazı adımları başarı, bazıları hata alabilir. Network timeout operation sonucunu belirsiz bırakabilir. Blind rollback mümkün olmayabilir. Durable workflow state hangi step'in tamamlandığını tutmalıdır. Reconciliation uzun süreli belirsizlikleri bulmalıdır.

Two-Phase Commit (2PC) Nasıl Çalışır?

2PC coordinator'ın birden fazla transactional participant arasında atomic commit kararı vermesini sağlayan klasik protocol'dür. İlk phase participants commit'e hazır olup olmadığını bildirir. Hepsi hazırsa coordinator commit kararı yayınlar. Biri başarısızsa abort yapılır. Coordinator veya communication failure bazı participant'ların prepared state'te beklemesine neden olabilir.

Coordinator

Coordinator global transaction'ın durumunu yönetir. Participants listesini bilir. Prepare responses toplar. Final commit veya abort kararını kaydeder. Coordinator durability failure recovery için önemlidir.

Prepare Phase

Participant local changes'i yapar ancak final commit etmez. Commit edebileceğini durable biçimde garanti etmeye hazırlanır. Locks tutulabilir. Coordinator'a yes veya no response döner. Long prepare resource contention yaratır.

Commit Phase

Bütün participants ready ise coordinator commit gönderir. Participant local transaction'ı kesinleştirir. Ack coordinator'a döner. Message kaybı varsa coordinator retry yapabilir. Commit decision durable olduğu için recovery tekrar uygulayabilir.

Abort

Bir participant prepare reddederse global transaction abort edilir. Hazırlanmış participants rollback yapar. Locks serbest bırakılır. Client failure sonucu error görür. External irreversible side effects 2PC participant olmuyorsa ayrı yönetilmelidir.

Coordinator Failure

Coordinator prepare sonrası crash edebilir. Participants final kararı bilmeden prepared durumda kalabilir. Recovery log coordinator state'ini yeniden yükler. Bazı protocol geliştirmeleri blocking riskini azaltmayı hedefler. Availability etkisi önemli tasarım maliyetidir.

Blocking Riski

Prepared transaction resources lock altında tutabilir. Final decision gelmezse progress durur. Network partition bu süreyi uzatabilir. High throughput microservice workload'unda problem büyür. Bu nedenle 2PC her distributed workflow için varsayılan çözüm yapılmamalıdır.

2PC Ne Zaman Kullanılmalı?

2PC güçlü global atomicity gerçekten zorunlu olduğunda ve bütün participants protocol'ü güvenilir biçimde desteklediğinde değerlendirilebilir. Financial infrastructure veya tightly controlled enterprise resources buna aday olabilir. Latency ve availability bedeli kabul edilmelidir. Long-running business process için uygun değildir. Harici SaaS API gibi XA participant olmayan sistemlerle kullanımı sınırlıdır.

Güçlü Atomicity Gereksinimi

Partial commit hiçbir şekilde kabul edilemiyorsa 2PC değerli olabilir. İşlem kısa ve resource sayısı sınırlı olmalıdır. Prepared locks business throughput'u bozmamalıdır. Failure recovery test edilmelidir. Audit final decision'ı gösterebilmelidir.

Katılımcı Sistem Desteği

Database veya resource manager prepare/commit protocol'ünü desteklemelidir. HTTP endpoint doğal participant değildir. Driver ve transaction manager compatibility önemlidir. Cloud managed services kısıtlı destek sunabilir. Destek yoksa Saga veya outbox daha doğal olur.

Latency ve Availability Trade-Off

İki phase ekstra network round-trip getirir. Coordinator ve participants erişilebilir olmalıdır. Partition sırasında progress durabilir. Locks tail latency oluşturabilir. SLO bu maliyetleri karşılayabilmelidir.

Microservice Mimarisinde Sınırlamalar

Independent service deployment global transaction manager dependency'siyle bağlanabilir. Long business workflow lock tutamaz. External provider participation sorunludur. Operational debugging zorlaşır. Saga çoğu long-running microservice workflow'da daha uyumlu olabilir.

Saga Pattern Nedir?

Saga bir business transaction'ı bağımsız local transaction adımlarına böler. Her başarılı adım bir sonraki operation'ı tetikler. Hata olduğunda forward recovery veya compensating transaction uygulanır. Bütün sistem tek anda atomik görünmez. Ama workflow sonunda business açısından kabul edilen consistent state'e ulaşmayı hedefler.

Local Transactions

Her service yalnızca kendi database'i üzerinde ACID transaction yürütür. Global lock tutulmaz. Step tamamlanınca event veya orchestrator state ilerler. Failure başka service transaction'ını rollback etmez. Compensation gerektiğinde ayrı local transaction çalışır.

Forward Recovery

Bazı failure'larda rollback yerine operation'ın tamamlanması tercih edilir. Temporary payment timeout retry edilebilir. Inventory reserve zaten başarılıdır. Workflow retry policy ile ileri gider. Business deadline aşılırsa compensation seçilebilir.

Backward Recovery

İleri devam mümkün değilse önceki business effects telafi edilir. Reserved stock release edilir. Authorized payment void veya refund edilir. Compensation original transaction'ın fiziksel rollback'i değildir. Yeni business event oluşturur.

Compensating Transactions

Her reversible step için semantic compensation tanımlanır. E-posta gönderme gibi operation geri alınamaz. Bunun yerine correction email gönderilebilir. Refund payment history'de yeni transaction'dır. Compensation idempotent olmalıdır.

Eventual Business Consistency

Saga sırasında ara state'ler gözlemlenebilir. Workflow tamamlandığında invariant yeniden sağlanır. Bu süre consistency SLO ile sınırlandırılmalıdır. Stuck Saga monitoring gerektirir. Reconciliation beklenen terminal state'e ulaşmayan işlemleri bulur.

Saga Choreography

Choreography modelinde merkezi orchestrator olmadan services event'lere tepki vererek Saga'yı ilerletir. OrderCreated event inventory reservation başlatabilir. InventoryReserved payment service'i tetikleyebilir. Küçük workflow'larda coupling düşük görünür. Step sayısı arttıkça event dependency graph'ı anlamak zorlaşabilir.

Event-Driven Akış

Her service ilgilendiği domain event'i consume eder. Local transaction yapar. Sonraki event'i yayınlar. Outbox delivery güvenilirliğini artırır. Consumer idempotent olmalıdır.

Merkezi Orchestrator Olmaması

Workflow state tek service'te toplanmaz. Services bağımsız event contract'larına bağlıdır. Tek orchestration bottleneck yoktur. Buna karşılık bütün process'i tek yerde görmek zorlaşır. Distributed tracing daha önemli hale gelir.

Avantajları

Loose coupling küçük Saga'larda basit olabilir. Services kendi domain event'lerini sahiplenir. Central workflow code azalır. Event infrastructure zaten varsa integration doğal görünür. Independent deployment desteklenir.

Event Bağımlılıklarının Karmaşıklaşması

Beşten fazla step olduğunda hangi event'in kimi tetiklediğini takip etmek zorlaşabilir. Circular dependencies oluşabilir. Compensation chain görünürlüğü düşer. Schema change birçok consumer'ı etkiler. Workflow graph dokümantasyonu zorunlu hale gelir.

Hangi Durumlarda Kullanılmalı?

Az step'li ve doğal domain events ile ilerleyen process'lerde uygundur. Complex branching veya long timeout management varsa orchestration daha okunabilir olabilir. Team event-driven architecture konusunda deneyimli olmalıdır. Observability güçlü kurulmalıdır. Choreography yalnızca “merkezi servis istemiyoruz” gerekçesiyle seçilmemelidir.

Saga Orchestration

Orchestration modelinde merkezi workflow component hangi step'in sırada olduğunu yönetir. Services'e command gönderir ve sonuçlarını bekler. Retry, timeout ve compensation decision aynı state machine içinde görünür hale gelir. Complex workflow'larda debugging kolaylaşabilir. Orchestrator domain logic'in tamamını kendine çekip god service'e dönüşmemelidir.

Merkezi Orchestrator

Orchestrator business process state'ini bilir. Inventory reserve command gönderir. Sonuç gelince payment step'e geçer. Failure durumunda compensation başlatır. Local entity logic ilgili service'te kalmalıdır.

Workflow State

Her Saga instance durable state taşır. Current step ve completed steps kaydedilir. Process crash sonrası kaldığı yerden devam eder. Saga ID correlation sağlar. State retention audit requirement'a göre ayarlanır.

Retry

Transient error belirli backoff ile tekrar denenebilir. Retry operation idempotent olmalıdır. Permanent business rejection ayrı status'tur. Sonsuz retry stuck Saga üretir. Maximum attempts sonrası compensation veya manual review gerekir.

Compensation

Failure sonrası hangi completed steps'in ters business action alacağı state'ten bilinir. Compensation order çoğu zaman reverse olabilir. Bazı action'lar parallel yapılabilir. Compensation da failure yaşayabilir. Retry ve manual escalation gerekir.

Timeout

External service response sonsuza kadar beklenmemelidir. Business timeout ile technical request timeout farklıdır. Payment sonucu birkaç dakika pending kalabilir. Timeout sonrası query-status veya compensation yapılabilir. Deadline workflow state içinde durable tutulmalıdır.

Choreography vs Orchestration

Küçük doğal event chain choreography ile sade olabilir. Branching ve long-running workflow orchestration ile daha görünür hale gelir. İki model birlikte de kullanılabilir. Kritik karar observability ve ownership'tir. Mimari moda göre değil process yapısına göre seçim yapılmalıdır.

Compensating Transaction Gerçek Rollback midir?

Hayır, compensation çoğu zaman geçmiş operation'ı yok etmez. Yeni bir business operation ile etkisini dengelemeye çalışır. Payment refund original charge kaydını silmez. Gönderilmiş e-posta geri alınamaz. Bu nedenle Saga atomic transaction ile aynı isolation ve rollback semantics'ini sunmaz.

Refund ile Payment Rollback Farkı

Database rollback uncommitted transaction'ı hiç olmamış gibi geri alabilir. Refund ise charge tamamlandıktan sonra yeni financial transaction yaratır. Kullanıcı statement'ta ikisini de görebilir. Fee veya exchange-rate farkı olabilir. Compensation business semantics'i dikkatle tanımlamalıdır.

Gönderilmiş E-posta

E-posta alıcının mailbox'ına ulaştıktan sonra gerçek anlamda rollback edilemez. Hatalı mesaj için correction gönderilebilir. Notification step process sonunda geciktirilebilir. Side effect timing Saga design'ını etkiler. Irreversible actions mümkün olduğunca final aşamalara konulabilir.

Kargoya Verilmiş Sipariş

Paket carrier'a teslim edilmişse “shipment create” kolayca geri alınamaz. Return process gerekir. Compensation fiziksel dünyada yeni süreçtir. Daha erken reservation state kullanmak risk azaltır. Business workflow digital transaction'dan daha uzun olabilir.

Harici API Side Effect'i

External API request timeout verdiğinde result bilinmeyebilir. Tekrar çağrı duplicate side effect yaratabilir. Idempotency key veya status query endpoint gerekir. Provider compensation API sunmayabilir. Reconciliation third-party state'i local records ile karşılaştırmalıdır.

Semantic Compensation

Compensation teknik inverse command değil iş açısından dengeleme işlemidir. Reservation release, refund ve cancellation farklı semantics taşır. Audit trail original ve compensating actions'ı korur. User communication gerekebilir. Domain experts compensation rule tanımına katılmalıdır.

Saga Isolation Problemleri

Saga local transactions arasında uzun süre açık kaldığı için ara state başka process'ler tarafından görülebilir. Bu durum klasik database isolation seviyelerinden farklı business anomalies oluşturur. Lost update veya dirty business read yaşanabilir. Reservation ve semantic lock ara state'in başka workflow tarafından tüketilmesini engeller. Version check concurrent Saga'ların birbirini ezmesini azaltır.

Saga Çalışırken Ara Durumların Görünmesi

Order “payment_pending” durumunda diğer service tarafından görülebilir. Bu state geçici ama valid olmalıdır. Downstream yalnızca terminal status bekliyorsa filtrelemelidir. UI pending süreci açık gösterebilir. Ara state'i tamamen gizlemek global transaction gerektirebilir.

Lost Update

İki Saga aynı entity'yi farklı base version üzerinden güncelleyebilir. Son write önceki business change'i ezebilir. Version condition conflict'i ortaya çıkarır. Retry current state üzerinden yapılır. Domain conflict manual review isteyebilir.

Dirty Business Read

Database transaction committed olsa bile business process henüz tamamlanmamış olabilir. Başka workflow ara state'i final kabul ederse hata oluşur. Status veya reservation flag semantic visibility sağlar. Read models yalnızca eligible state'leri göstermelidir. Business isolation application level'da tanımlanır.

Semantic Lock

Entity “reserved_for_order_123” gibi state taşıyabilir. Başka Saga resource'u kullanamaz. Bu database mutex'ten farklıdır. Lock business state olduğu için restart sonrası kaybolmaz. Timeout ve release process gerekir.

Reservation Pattern

Resource doğrudan tüketmek yerine belirli süre reserve edilir. Payment tamamlanırsa confirm edilir. Failure olursa release edilir. Expired reservation cleanup job tarafından kaldırılır. Overselling riski güçlü reservation update ile engellenir.

Version Check

Her Saga step expected entity version taşır. State beklenenden farklıysa operation fail eder. Orchestrator conflict policy uygular. Blind compensation güncel başka user's update'ini bozmamalıdır. Version metadata event'lere de eklenebilir.

Dual Write Problemi Nedir?

Dual write application'ın aynı business operation için database ve message broker gibi iki bağımsız sisteme ayrı writes yapmasıdır. İki operation tek local transaction içinde atomik değilse biri başarılı diğeri başarısız olabilir. Retry duplicate event üretebilir. Sıralamayı ters çevirmek problemi çözmez. Transactional outbox bu gap'i database transaction sınırı içinde kapatmak için kullanılan temel pattern'lerden biridir.

Database Başarılı, Event Başarısız

Order database'e kaydedilir. Broker publish network error verir. Inventory service OrderCreated event'ini hiç görmez. Database gerçek state ile event-driven projections ayrışır. Manual retry veya outbox olmadığında inconsistency kalıcı olabilir.

Event Başarılı, Database Başarısız

Event önce gönderilir ve downstream processing başlar. Sonra database transaction rollback olur. Consumer aslında var olmayan order için stock reserve edebilir. Compensating event gerekebilir. Bu sıra da güvenli atomicity sağlamaz.

Distributed Transaction Kullanmanın Maliyeti

Database ve broker aynı 2PC protocol'e katılabiliyorsa atomicity mümkün olabilir. Ancak operational coupling ve latency artar. Cloud broker veya service bunu desteklemeyebilir. Long failure state blocking yaratabilir. Outbox local transaction ile daha esnek alternatif sunar.

Veri Tutarsızlığının Oluşması

Source database ve downstream projections farklı business reality taşımaya başlar. Kullanıcı farklı ekranlarda farklı sonuç görür. Event replay eksik event'i bilmeden yapamaz. Reconciliation farkı sonradan bulabilir. En iyi yaklaşım inconsistency yaratma penceresini baştan kapatmaktır.

Transactional Outbox Pattern

Transactional outbox business data değişikliği ile yayınlanacak event kaydını aynı local database transaction içinde yazar. Böylece business write varsa event intent de kalıcıdır. Ayrı relay outbox entries'i broker'a yayınlar. Broker duplicate event alabilir. Consumer idempotent tasarlanmalıdır.

Business Table + Outbox Table

Order row ve outbox event aynı transaction içinde insert edilir. İkisinden biri başarısızsa ikisi de rollback olur. Event payload minimum gerekli bilgi taşır. Aggregate ID ve event type tutulur. Sequence version ordering için faydalıdır.

Aynı Local Transaction

Outbox'ın gücü database atomicity'sinden gelir. Separate broker publish transaction içinde yapılmaz. Commit sonrası event intent kesinlikle vardır. Database bu state'in source of truth'udur. Relay daha sonra tekrar deneyebilir.

Event Relay

Relay unpublished rows'u bulur. Broker'a gönderir. Publish başarılı olduğunda status update veya position advance yapar. Crash publish ile mark arasında olursa duplicate oluşabilir. Consumer idempotency bu nedenle zorunludur.

Message Broker

Broker event'i downstream consumers'a dağıtır. Kafka veya başka messaging altyapısı kullanılabilir. Outbox broker semantics'inden bağımsız pattern'dir. Partition key ordering ihtiyacına göre seçilir. Retention replay planını destekler.

Outbox Status

Polling model published flag taşıyabilir. Çok büyük table'da status index gerekir. Alternatif CDC log position üzerinden publish edilir. Failed entries retry metadata tutabilir. Poison event manual review queue'suna gidebilir.

Cleanup ve Retention

Published outbox rows sonsuza kadar birikmemelidir. Audit requirement'a göre retention belirlenir. Batch cleanup production I/O'yu kontrol etmelidir. Partitioned outbox eski data'yı kolay drop etmeyi sağlayabilir. Cleanup event delivery doğrulandıktan sonra yapılmalıdır.

Transactional Outbox CDC ile Nasıl Uygulanır?

CDC yaklaşımında ayrı polling query yerine database transaction log değişiklikleri okunur. Outbox insert commit olduğunda connector bunu event stream'e aktarır. Bu yöntem application polling yükünü azaltabilir. Debezium gibi CDC araçları bu entegrasyon modelinde yaygın kullanılır. Connector lag ve schema evolution consistency SLO'nun parçası haline gelir.

Transaction Log

Database committed changes'i WAL, binlog veya benzer transaction log içinde kaydeder. CDC connector bu source'u takip eder. Rollback olmuş changes yayınlanmamalıdır. Log position durable progress için kullanılır. Retention connector outage süresini karşılamalıdır.

Change Data Capture

CDC row changes'i event haline getirir. Outbox table yalnızca intended domain events taşır. Bütün database row changes'ini domain event saymak doğru değildir. Connector filtering outbox schema'sına odaklanabilir. Operational lag monitoring zorunludur.

Debezium

Debezium farklı database transaction logs için connector ekosistemi sunar. Outbox Event Router gibi yaklaşımlar event publication'ı standartlaştırabilir. Connector restart sonrası log position'dan devam eder. Duplicate ihtimali consumer tarafında yine düşünülmelidir. Schema ve connector upgrades staging ortamında test edilmelidir.

Broker'a Event Publication

CDC connector committed outbox row'u broker topic'ine taşır. Aggregate ID partition key olabilir. Event headers correlation metadata taşıyabilir. Publish latency source commit sonrası projection lag oluşturur. SLO bu süreyi ölçmelidir.

Polling Publisher ile CDC Karşılaştırması

Polling uygulaması daha basit altyapıyla başlayabilir. Yüksek frekansta database query overhead oluşturabilir. CDC transaction log üzerinden daha doğal stream üretir. Operational connector yönetimi eklenir. Ölçek ve platform yetkinliğine göre seçim yapılmalıdır.

Inbox Pattern Nedir?

Inbox pattern consumer'ın daha önce işlediği message ID'lerini durable biçimde kaydederek duplicate processing'i önlemesine yardım eder. Message processing ile inbox mark aynı local transaction içinde yapılabilir. Consumer crash edip message tekrar geldiğinde ID kontrol edilir. External side effect için ek idempotency gerekebilir. Inbox ve outbox birlikte service-to-service reliable messaging temelini güçlendirir.

Message ID

Her logical event global veya producer-scope unique ID taşır. Retry aynı ID'yi korumalıdır. Yeni business event yeni ID alır. ID domain identity ile aynı olmak zorunda değildir. Debugging ve tracing için correlation sağlar.

Processed Message Store

Consumer processed IDs tablosu tutabilir. Unique constraint duplicate insert'i engeller. Retention message redelivery window'dan uzun olmalıdır. Çok yüksek volume'da storage büyür. Partition veya compact representation kullanılabilir.

Duplicate Detection

Message geldiğinde ID daha önce processed mi kontrol edilir. Varsa business action atlanır. Response veya ack normal şekilde verilir. Race condition unique constraint ile korunur. Read-then-write tek başına concurrent duplicates'ta yeterli değildir.

Consumer Transaction

Inbox insert ve business database update aynı transaction'da yapılır. İkisi birlikte commit olur. Crash sonrası duplicate message business change'i tekrar etmez. Broker acknowledgement transaction dışında kalabilir. Redelivery güvenli hale gelir.

Inbox + Outbox Birlikte Kullanımı

Service incoming event'i inbox ile deduplicate eder. Business state'i update eder. Aynı transaction'da kendi outbox event'ini yazar. Böylece local atomic chain kurulur. End-to-end network delivery yine at-least-once olabilir fakat side effects duplicate-safe hale gelir.

Idempotency Veri Tutarlılığı İçin Neden Kritiktir?

Distributed system'de retry kaçınılmaz olduğu için aynı logical operation birden fazla kez gelebilir. Idempotent processing tekrarların final state'i değiştirmemesini hedefler. Payment, order create ve event consumer için özellikle önemlidir. Unique constraint veya processed-message table basit ve güvenilir primitives sunar. “Broker exactly once sağlıyor” varsayımı external side effect'lerde idempotency ihtiyacını ortadan kaldırmaz.

Aynı İsteğin Birden Fazla Kez Gelmesi

User double-click yapabilir. Gateway timeout sonrası mobile client retry edebilir. Proxy aynı request'i tekrar gönderebilir. Backend operation ID üzerinden aynı logical intent'i tanımalıdır. Duplicate create yeni entity üretmemelidir.

Retry Sonrası Duplicate İşlem

İlk request database commit eder fakat response kaybolur. Client aynı request'i tekrarlar. Backend “daha önce başarılı” sonucu döndürebilmelidir. Operation result idempotency record'da saklanabilir. Aynı key farklı payload ile gelirse reject edilmelidir.

Idempotency Key

Client veya server business operation için stable key üretir. Payment request retries aynı key'i kullanır. Database unique constraint yalnızca bir record kabul eder. Stored response tekrar döndürülebilir. Key retention business retry window'a göre seçilir.

Unique Constraint

Database constraint concurrency-safe duplicate prevention sağlar. İki application node aynı key'i aynı anda insert etse yalnızca biri başarır. Application duplicate violation'ı expected path olarak işler. External side effect constraint'ten önce yapılmamalıdır. Local transaction ordering önemlidir.

Processed Message ID

Event consumer message ID'yi durable table'a kaydeder. Duplicate delivery ID üzerinden fark edilir. Business update aynı transaction içinde yapılır. Retention broker replay window'a göre ayarlanır. ID collision mümkün olmayacak şekilde tasarlanmalıdır.

Idempotent Consumer

Consumer duplicate event'i güvenli biçimde ignore veya merge eder. Operation naturally idempotent olabilir. “Set status=paid” tekrar uygulanabilirken “balance -= 100” tekrar uygulandığında hata oluşabilir. Mutation semantics buna göre seçilmelidir. Counter events unique ID ile deduplicate edilebilir.

Exactly-Once Delivery Gerçekte Ne Anlama Gelir?

Exactly-once ifadesi çoğu zaman scope belirtilmeden fazla güçlü anlaşılır. Broker belirli transaction boundary içinde duplicate production'ı önleyebilir. Kafka'nın güncel belgelerinde idempotent producer varsayılan olarak etkin ve transactional ID kullanıldığında transactional delivery özellikleri devreye girebilir. Buna rağmen consumer'ın harici database veya payment API üzerinde yaptığı side effect broker transaction'ının doğal sınırının dışında olabilir. End-to-end correctness için destination transaction veya idempotent side effect tasarımı gerekir.

At-Most-Once

Message en fazla bir kez işlenir. Retry yapılmazsa bazı messages kaybolabilir. Duplicate risk düşüktür. Critical financial workflows için data loss kabul edilemeyebilir. Logging telemetry gibi bazı use case'lerde uygun olabilir.

At-Least-Once

Message kaybolmaması için retry edilir. Duplicate delivery mümkündür. Consumer idempotent olmalıdır. Birçok messaging sistemi bu modeli doğal olarak sunar. Correctness duplicate-safe application design ile tamamlanır.

Broker-Level Exactly-Once

Kafka transactions producer records ve consumer offsets gibi Kafka içindeki state'i atomic şekilde ilişkilendirebilir. Consumer read_committed ile aborted transaction records'ı görmez. Producer transactional ID kullanır. Bu guarantee broker ecosystem sınırında çok değerlidir. Harici sistem side effect'i ayrı coordination ister.

End-to-End Side Effect

Consumer message alıp external payment API çağırıyorsa broker bu API'nin state'ini transaction'a otomatik dahil etmez. API timeout sonucu belirsiz olabilir. Idempotency key gerekir. Database write aynı transaction boundary'de değilse outbox veya inbox kullanılabilir. End-to-end exactly-once business semantics application tarafından tasarlanmalıdır.

Duplicate-Safe Tasarımın Önemi

Network retry'ları tamamen ortadan kaldırmak mümkün değildir. Duplicate-safe design belirsizlikleri yönetilebilir hale getirir. Message ID, operation ID ve unique constraints cheap safety mechanisms'dir. Reconciliation kalan gap'leri bulur. Exactly-once sloganı yerine “hangi side effect kaç kez olabilir?” sorusu sorulmalıdır.

Event Ordering Nasıl Korunur?

Event ordering global yerine çoğu zaman entity veya aggregate bazında gereklidir. Aynı order'ın Created ve Cancelled event'leri doğru sırada işlenmelidir. Aggregate ID partition key olarak kullanılırsa broker aynı partition içinde ordering sağlayabilir. Sequence number consumer'ın stale event'i fark etmesine yardım eder. Global ordering throughput ve availability maliyetini gereksiz artırabilir.

Aggregate ID

Event hangi entity'nin state'ini değiştirdiğini belirtir. Same aggregate events aynı ordering domain içindedir. Global event order gereksizdir. Partition key aggregate ID olabilir. Hot aggregate single partition bottleneck oluşturabilir.

Partition Key

Broker event'leri key üzerinden partition'a atar. Same key aynı partition'da kalırsa order daha kolay korunur. Partition count horizontal throughput sağlar. Repartition migration dikkat gerektirir. Producer ordering settings ayrıca doğrulanmalıdır.

Sequence Number

Aggregate version her committed event'te artar. Consumer expected next version ile karşılaştırır. Gap varsa missing event beklenebilir veya replay istenir. Daha düşük version duplicate/stale olarak ignore edilir. Out-of-order handling deterministic olur.

Per-Key Ordering

Yalnızca aynı business key event'leri sıraya ihtiyaç duyar. Different users bağımsız parallel işlenebilir. Throughput yükselir. Global coordination azalır. Business invariants key boundary ile uyumlu olmalıdır.

Global Ordering Maliyeti

Bütün events tek sequence içinde zorlanırsa single bottleneck oluşabilir. Cross-region coordination gerekir. Availability düşebilir. Çoğu business process total global order istemez. Audit timestamp global order yerine causal veya domain ordering kullanabilir.

Out-of-Order Event Handling

Consumer version gap gördüğünde event'i buffer edebilir. Missing event belirli sürede gelmezse reconciliation tetiklenir. Stale event discard edilebilir. Business merge gerekiyorsa domain rule kullanılır. Silent apply en riskli davranıştır.

Event Schema Evolution Tutarlılığı Nasıl Etkiler?

Producer ve consumer aynı anda deploy edilmediği için event schema zaman içinde uyumlu gelişmelidir. Yeni producer eski consumer'ın anlayamadığı mandatory field semantics'i dayatırsa processing durabilir. Backward ve forward compatibility deployment bağımsızlığı sağlar. Schema registry format kurallarını kontrol edebilir. Versioned event contract business meaning değişikliklerinde ayrıca kullanılabilir.

Yeni Producer ve Eski Consumer

Rolling deploy sırasında bu kombinasyon normaldir. Yeni field optional olmalıdır. Eski consumer unknown field'ı ignore edebilir. Existing field meaning değiştirilmemelidir. Breaking change yeni event version isteyebilir.

Backward Compatibility

Yeni consumer eski event'leri okuyabilmelidir. Replay veya long retention bunu gerekli kılar. Default values dikkatle seçilir. Historical semantics korunmalıdır. Test fixtures eski schema versions içermelidir.

Forward Compatibility

Eski consumer yeni event'i anlamaya devam edebilmelidir. Unknown optional fields tolere edilir. Enum extension risklidir. Consumer unknown values için safe behavior belirler. Strict parser production outage yaratabilir.

Schema Registry

Registry schema versions ve compatibility policy tutabilir. Producer incompatible schema publish etmeden önce validation alır. Consumer schema ID üzerinden deserialize eder. Registry availability dependency olarak planlanır. Business semantic compatibility yine insan review'u gerektirir.

Versioned Events

Büyük semantic değişiklik yeni event type veya version oluşturabilir. Eski ve yeni consumers geçiş süresinde birlikte çalışır. Translator veya dual publish geçici kullanılabilir. Deprecation deadline belirlenir. Event contract lifecycle dokümante edilir.

Event Sourcing ile Veri Tutarlılığı

Event sourcing current state yerine domain değişikliklerinin append-only event log'unu source of truth olarak kullanır. State geçmiş events replay edilerek üretilebilir. Bu güçlü audit avantajı sağlar. Projection'lar eventual olabilir ve yeniden oluşturulabilir. Event order, schema evolution ve irreversible history yönetimi ciddi disiplin gerektirir.

Event Log as Source of Truth

Authoritative record current row değil events dizisidir. Her state change yeni event olarak eklenir. History modify edilmez. Correction yeni event ile yapılır. Audit reasoning kolaylaşır.

Append-Only Events

Event geçmişi immutable kabul edilir. Delete yerine compensating event yazılır. Storage retention domain requirement'a bağlıdır. PII deletion yasal gereksinimleri özel tasarım ister. Event integrity hash veya access controls ile korunabilir.

State Replay

Aggregate state events sırayla apply edilerek yeniden oluşturulur. Çok uzun history startup'ı yavaşlatabilir. Snapshot kullanılır. Replay deterministic code ister. Event schema migration dikkat gerektirir.

Snapshot

Belirli version'daki aggregate state snapshot olarak saklanır. Replay snapshot sonrasındaki events'ten başlar. Snapshot cache gibidir ve events'ten yeniden üretilebilir. Version ile doğrulanır. Eski snapshot schema migration gerektirebilir.

Projection

Read-friendly database events consume ederek view üretir. Projection lag eventual consistency yaratır. Rebuild source event log'dan yapılabilir. Consumer idempotent olmalıdır. Projection version migration dual build ile yapılabilir.

Event Ordering

Aggregate events strict sequence taşır. Concurrent commands expected version check kullanır. Conflict oluşursa command retry veya reject edilir. Global event ordering gerekmeyebilir. Stream partition aggregate ID'ye göre yapılabilir.

CQRS ve Eventual Consistency

CQRS command ve query modellerini ayırır. Write model business invariant'ları korur. Read model farklı storage üzerinde projection olarak üretilebilir. Projection asynchronous ise kullanıcı write sonrası kısa süre eski read görebilir. Read-your-writes çözümleri UX'i iyileştirir.

Command Model

Command state change intent'ini taşır. Domain validation ve invariant checks burada yapılır. Successful command events üretir. Write storage query ihtiyaçlarından bağımsız optimize edilir. Stronger consistency yalnızca command boundary'de uygulanabilir.

Read Model

Read model UI query'leri için denormalized olabilir. Multiple source events'ten oluşturulur. Query latency düşer. Source of truth olmayabilir. Rebuild edilebilir olmalıdır.

Projection

Event consumer read tables'ı günceller. Duplicate events idempotent işlenir. Ordering version ile korunur. Error poison queue'ya alınabilir. Lag metric freshness'i gösterir.

Projection Lag

Write commit ile read model update arasındaki süredir. Normal durumda birkaç yüz milisaniye olabilir. Backlog sırasında artar. User stale data görür. Maximum lag SLO tanımlanmalıdır.

Kullanıcıya Stale Read Gösterimi

UI pending state gösterebilir. “Değişiklik kaydedildi, güncelleniyor” mesajı belirsizliği açıklar. Local optimistic state kullanılabilir. Server version mismatch daha sonra reconcile edilir. Critical operation final state için authoritative endpoint sunabilir.

Read-Your-Writes Çözümleri

Command response updated object'i döndürebilir. Session local state tutabilir. Read query required version token taşıyabilir. Projection version'a yetişene kadar write model fallback okunabilir. Global strong query model gerekmeyebilir.

Conflict Detection Nasıl Yapılır?

Conflict iki concurrent operation birbirinin değişikliklerinden habersiz aynı logical state'i güncellediğinde oluşur. Detect edilmezse lost update meydana gelebilir. Version number basit ve etkilidir. Vector clock concurrent branches'i ayırabilir. Domain-specific conflict detection hangi alanların gerçekten birbirini etkilediğini daha doğru belirler.

Version Number

Her state update monoton version artırır. Client expected version gönderir. Eşleşmiyorsa conflict vardır. Database conditional update atomik çalışır. Basit CRUD concurrency için güçlü pattern'dir.

Vector Clock

Birden fazla writer branch'inin causal ilişkisini takip eder. Version A B'nin ancestor'ı mı yoksa concurrent mı anlaşılır. Metadata büyüyebilir. Leaderless replicated data için uygundur. User-facing merge logic gerekebilir.

Logical Timestamp

Lamport counter operation ordering'i physical clock'tan bağımsız temsil eder. Causal relation varsa ordering korunur. Tie-breaker total order üretir. Conflict existence ile latest ordering ayrı kavramlardır. Logical timestamp data loss riskini azaltabilir.

Compare-and-Swap

Expected current value üzerinden atomic write yapılır. State değiştiyse update reddedilir. Retry fresh value ile yapılır. Hot resource contention oluşturabilir. Simple counters için dedicated atomic operation daha iyi olabilir.

Domain Conflict Detection

İki user profile update farklı field'ları değiştiriyorsa merge edilebilir. Aynı seat reservation merge edilemez. Domain conflict yalnız technical row version'dan daha anlamlı olabilir. Change-set field listesi kullanılabilir. Business rule automatic ve manual resolution'ı belirler.

Conflict Resolution Stratejileri

Conflict detect edildikten sonra hangi state'in korunacağı açık rule ile belirlenmelidir. Last-write-wins basittir fakat data loss riski taşır. First-write-wins reservation gibi use case'lerde anlamlı olabilir. Manual resolution değerli user edits için uygundur. CRDT merge edilebilir data types'ta automatic convergence sağlar.

Last-Write-Wins

En yeni kabul edilen write diğerlerini ezer. Timestamp veya logical version kullanılır. Basit ve deterministic'tir. Concurrent valid update sessizce kaybolabilir. Business value düşük data için kabul edilebilir.

First-Write-Wins

İlk successful claimant resource'u kazanır. Unique username veya seat reservation buna benzer. Sonraki writes conflict error alır. Atomic conditional insert kullanılır. User alternatif seçim yapar.

Manual Resolution

İki document edit merge edilemiyorsa user'a conflict gösterilebilir. Her version korunur. Operator veya user doğru state'i seçer. Yavaş fakat data-loss riskini azaltır. High-value content için uygundur.

Domain-Specific Merge

Shopping cart farklı item additions union olarak merge edilebilir. Quantity concurrent update özel rule isteyebilir. Profile independent fields merge edilebilir. Domain semantics generic timestamp'ten daha güvenlidir. Merge deterministic olmalıdır.

CRDT

CRDT data type concurrent updates'in conflict-free merge edilmesi için matematiksel properties kullanır. Merge order final state'i değiştirmez. Network partition sırasında local updates kabul edilebilir. Same update set replicas'ı aynı state'e taşır. Her domain CRDT olarak modellenemez.

Last-Write-Wins Neden Risklidir?

LWW implementation basittir fakat iki valid concurrent update'ten birini sessizce silebilir. Wall-clock timestamp kullanımı clock skew problemine açıktır. Client saati yanlışsa daha eski write geleceğin timestamp'iyle diğer updates'i uzun süre ezebilir. Data loss user'a görünmeden gerçekleşebilir. Bu nedenle LWW yalnız business açısından kaybı kabul edilebilir state'te kullanılmalıdır.

Wall Clock Dependence

Timestamp physical clock'tan geliyorsa node synchronization'a güvenilir. NTP drift tamamen sıfır değildir. Mobile client timestamp daha da güvenilmezdir. Server-side monotonic logical sequence tercih edilebilir. Time yalnız audit metadata olarak tutulabilir.

Clock Skew

Node A saati 500 ms ileride olabilir. Gerçekte önce yapılan write timestamp'te sonra görünebilir. Concurrent window içinde yanlış winner seçilir. Conflict kaybolur. Hybrid logical clocks bazı sistemlerde denge sağlayabilir.

Concurrent Writes

İki write birbirinin varlığını bilmiyorsa ikisi de valid intent olabilir. LWW birini loser ilan eder. Kullanıcı yaptığı değişikliği kaybedebilir. Vector clock concurrent state'i görünür yapabilir. Domain merge daha güvenli olabilir.

Sessiz Veri Kaybı

LWW conflict error üretmeyebilir. Metrics conflict olduğunu bile bilmeyebilir. Audit trail yoksa kayıp fark edilmez. High-value data için bu kabul edilemez. Conflict detection explicit yapılmalıdır.

Logical Clock Alternatifleri

Version counter monoton order sağlayabilir. Lamport clock causal ordering'e yardımcı olur. Vector clock concurrency'yi ayırır. Consensus log global order oluşturabilir. Seçim consistency requirement ve scale'e göre yapılır.

CRDT Nedir?

CRDT concurrent updates'in coordination olmadan birleştirilebildiği data structures ailesidir. Tasarımda operations veya states commutative, associative ve idempotent benzeri özelliklerden faydalanır. Replicas aynı update set'ini aldığında aynı state'e ulaşabilir. Bu strong eventual consistency için önemli temel sağlar. Counter, set veya register gibi belirli domain state'leri için uygundur.

Strong Eventual Consistency

Replicas aynı updates'i aldığında final state birebir aynı olur. Merge order sonucu değiştirmez. Network partition local operation'ı durdurmak zorunda değildir. Connectivity geri gelince updates exchange edilir. Convergence deterministic olur.

Conflict-Free Merge

Merge central arbitrator istemez. Data type semantics conflict'i matematiksel olarak çözer. Generic JSON object otomatik CRDT değildir. Delete ve add semantics özel tasarım ister. Metadata storage cost oluşabilir.

G-Counter

Grow-only counter yalnız artar. Her replica kendi component counter'ını increment eder. Merge component-wise maximum kullanır. Total bütün components toplamıdır. Decrement gerekiyorsa PN-counter gerekir.

PN-Counter

Positive ve negative grow-only counters birlikte tutulur. Value positives toplamı eksi negatives toplamıdır. Concurrent increment ve decrement merge edilebilir. Metadata replica components taşır. Membership changes dikkat gerektirir.

OR-Set

Observed-remove set add operations'a unique tag verir. Remove yalnız gördüğü adds'i kaldırır. Concurrent unseen add korunabilir. Böylece add-remove conflict deterministic çözülür. Metadata tombstone management ister.

LWW Register

Register tek value tutar ve conflict winner timestamp/order ile seçilir. CRDT convergence sağlar ancak business data loss riskini kaldırmaz. LWW register merge deterministic olduğu için strong eventual consistency olabilir. Saat semantics dikkat gerektirir. Critical edits için manual merge daha iyi olabilir.

CRDT Ne Zaman Kullanılmalı?

Offline-first collaborative state veya counters için değerlidir. Domain operation'ları doğal merge edilebilir olmalıdır. Global uniqueness veya seat reservation CRDT ile kolay çözülmez. Metadata ve debugging maliyeti dikkate alınmalıdır. Coordination avoidance business correctness'e uygunsa tercih edilmelidir.

Multi-Region Sistemlerde Veri Tutarlılığı

Multi-region mimaride consistency latency'nin fiziksel sınırlarıyla doğrudan karşılaşır. Single-writer region ordering'i sadeleştirir. Multi-writer local latency'yi düşürür fakat conflict çözümü ister. Home-region ve geo-partitioning tenant veya user state'ini bölgelere sahiplenebilir. Global invariant gereken operation cross-region consensus bedeli ödeyebilir.

Single-Writer Region

Bütün writes authoritative region'a gider. Conflict ihtimali düşer. Uzak user write WAN RTT yaşar. Read replicas local olabilir. Region failure promotion planı gerekir.

Multi-Writer

Her region local writes kabul eder. User latency düşer. Aynı key concurrent update alabilir. Conflict resolution zorunlu hale gelir. Global uniqueness expensive coordination ister.

Home Region

Her user veya tenant bir authoritative region'a atanır. Kendi state writes o region'a gider. Diğer regions read replicas taşıyabilir. Tenant move controlled migration gerektirir. Traffic locality latency'yi azaltır.

Geo-Partitioning

Data geography veya tenant üzerinden partition edilir. Her partition local strong consistency kullanabilir. Cross-partition transaction az tutulur. Global query aggregation eventual olabilir. Regulatory data residency requirement da desteklenebilir.

Cross-Region Consensus

Global metadata veya unique allocation için consensus gerekebilir. Majority birden fazla region'da dağıtılır. Region failure tolerance placement'e bağlıdır. WAN latency write commit'e eklenir. Critical operation sayısı sınırlı tutulmalıdır.

Latency–Consistency Trade-Off

Local read en hızlıdır fakat stale olabilir. Leader read WAN request ister. Bounded staleness orta çözüm sunabilir. Application operation bazında seçenek kullanabilir. PACELC bu günlük trade-off'u hatırlatır.

Bounded Staleness Nedir?

Bounded staleness eventual consistency'nin ne kadar eski data sunabileceğine üst sınır ekler. Bound zaman veya version farkı olarak tanımlanabilir. Reader “en fazla 5 saniye eski” gibi garanti alabilir. Global strong consistency'den daha düşük coordination ile kontrollü freshness sağlanabilir. Analytics ve geo-distributed read workload'larında yararlı ara modeldir.

Maximum Staleness Window

Replica belirlenen süreden daha gerideyse read için kullanılmaz. Başka replica seçilir veya primary'ye gidilir. Availability düşebilir. Window business tolerance'a göre seçilir. Lag monitoring enforcement'ı destekler.

Eventual Consistency'den Farkı

Plain eventual model convergence için kesin deadline vermeyebilir. Bounded model explicit freshness limit taşır. Application behavior daha öngörülebilir olur. Bound karşılanamazsa error veya stronger route gerekir. SLO ürün contract'ına dönüşebilir.

Time-Based Bound

Replica last-applied timestamp üzerinden lag hesaplanır. Saat synchronization gereksinimi vardır. Server-generated commit time kullanılabilir. Reader threshold aşılırsa reject edilir. Clock skew safety margin gerektirebilir.

Version-Based Bound

Primary commit sequence ile replica sequence karşılaştırılır. “En fazla 100 operations geride” gibi bound olabilir. Wall-clock dependency azalır. Traffic volume değiştikçe operation count'un time anlamı değişir. Business freshness için time bound daha anlaşılır olabilir.

Analytics ve Global Read Senaryoları

Dashboard birkaç dakika stale data kabul edebilir. Region-local replica düşük latency sunar. Lag threshold aşılırsa UI timestamp gösterebilir. Financial final report authoritative snapshot kullanır. Read class'ları farklı consistency levels taşıyabilir.

Cache Kullanırken Veri Tutarlılığı

Cache source database'den ayrı state kopyası oluşturduğu için consistency problemi getirir. Cache-aside stale window TTL ve invalidation'a bağlıdır. Write-through fresh read'i iyileştirirken dual-write riskini artırabilir. Write-behind source-of-truth rolünü daha hassas hale getirir. Cache invalidation correctness planının açık parçası olmalıdır.

Cache-Aside

Read önce cache'e gider. Miss database'den populate edilir. Database update sonrası cache delete yapılır. Concurrent read stale value'yu tekrar yazabilir. Version veya short TTL riski sınırlar.

Write-Through

Database update ile cache update aynı workflow'da yapılır. Read-after-write freshness daha yüksektir. İki system atomic değilse failure gap oluşur. Database source of truth olmalıdır. Cache update retry idempotent tasarlanmalıdır.

Write-Behind

Write önce cache veya queue'ya gelir. Database daha sonra asenkron güncellenir. Throughput artabilir. Cache kaybı data loss riskini büyütür. Durable queue ve reconciliation gerekir.

Cache Invalidation

Mutation cache value'yu outdated yapar. Explicit delete basit pattern'dir. Event-driven invalidation cross-service cache'leri temizler. TTL kaçırılan event'e safety net olur. Cache bust version deployment'ta kullanılabilir.

Stale Cache

Database version ilerlemiş cache geride kalmıştır. User eski state görür. Staleness bazı data için kabul edilebilir. Security veya price data risklidir. Maximum cache age SLO tanımlanmalıdır.

Database + Cache Dual Write Problemi

Database commit olur cache update fail olabilir. Ters sırada cache yeni value alıp database rollback olabilir. Delete-after-commit daha sade semantics sunar. Event veya CDC cache invalidate edebilir. Cache correctness source database'den türetilmelidir.

Search Index ile Database Nasıl Tutarlı Tutulur?

Search index çoğu sistemde database'in asenkron projection'ıdır. Database source of truth olarak kalır. CDC veya outbox changes'i indexing pipeline'a taşır. Indexing lag user'ın yeni veriyi aramada hemen bulamamasına neden olabilir. Reindex mekanizması projection'ın tamamen yeniden oluşturulabilmesini sağlamalıdır.

Database Source of Truth

Canonical entity database'de tutulur. Search document tekrar üretilebilir. Search update failure business transaction'ı rollback ettirmeyebilir. Index data correction database'den yapılır. Search cluster'a direct business write sınırlanmalıdır.

Asynchronous Indexing

Database commit sonrası event queue'ya gider. Index consumer document update yapar. User kısa süre stale search görür. Consumer retry gerekir. Poison document dead-letter workflow'a alınabilir.

CDC

Transaction log changes indexing pipeline'a aktarılabilir. Manual dual write azalır. Delete events de yakalanmalıdır. Schema mapping versionlanır. Connector lag freshness SLO'ya bağlanır.

Indexing Lag

Commit ile search visibility arasındaki süredir. Normal ve p99 değerleri izlenir. Backlog büyürse alert verilir. User-facing UI “indexing” status gösterebilir. Critical direct lookup database'den yapılabilir.

Delete Propagation

Database delete search index'te de uygulanmalıdır. Missing delete privacy riski yaratabilir. Tombstone event kullanılabilir. Hard-delete compliance için verification job gerekir. Retrying delete idempotent olmalıdır.

Full Reindex

Search projection corrupted veya schema değişmiş olabilir. Yeni index database snapshot'tan oluşturulur. Live changes concurrently stream edilir. Cutover alias veya version ile yapılır. Rebuild source-of-truth modelinin değerini gösterir.

Consistency SLO Nasıl Tanımlanır?

Consistency soyut mimari terim olmaktan çıkıp ölçülebilir hedeflere bağlanmalıdır. Maximum replication lag ve projection lag ayrı izlenir. Outbox backlog event publication gecikmesini gösterir. Stale read window kullanıcı etkisini ifade eder. Business invariant violation rate en güçlü outcome metric'lerinden biridir.

Maximum Replication Lag

Replica primary'den ne kadar geride kalabilir sorusuna limit konur. Time veya log position ile ölçülür. Threshold aşılırsa replica read pool'dan çıkarılabilir. Failover eligibility etkilenebilir. Region bazında farklı hedef olabilir.

Maximum Projection Lag

CQRS veya search projection commit'ten kaç saniye sonra güncellenmelidir. p95 ve p99 izlenir. Backlog consumer capacity sorununu gösterir. User experience SLO ile ilişkilendirilir. Critical projection daha yüksek priority alabilir.

Maximum Outbox Delay

Business transaction ile broker publication arasındaki süre ölçülür. Relay crash bunu uzatabilir. Oldest unpublished row alarm üretir. Normal traffic altında küçük kalmalıdır. Delay growing trend capacity ihtiyacını gösterir.

Maximum Stale Read Window

Reader en fazla ne kadar eski state görebilir tanımlanır. Data class'a göre değişir. Profile saniyeler, analytics dakikalar olabilir. Violation synthetic probe ile ölçülebilir. Business owner hedefi onaylamalıdır.

Reconciliation SLO

Inconsistency oluşursa ne kadar sürede bulunup düzeltilmesi gerektiği tanımlanır. Financial data daha kısa hedef ister. Batch daily reconciliation düşük risk data için yeterli olabilir. Automatic repair success rate izlenir. Manual queue age ayrıca takip edilir.

Business Invariant Violation Rate

Duplicate payment veya negative stock gibi gerçek correctness errors ölçülür. Hedef çoğu kritik invariant için sıfıra yakın olmalıdır. Telemetry privacy-safe şekilde event üretir. Incident her violation'da root cause analizi isteyebilir. Technical lag metrics sonuç metric'iyle ilişkilendirilir.

Veri Tutarlılığı Nasıl Gözlemlenir?

Consistency problemi yalnız error log ile görünmez. Replica lag, consumer lag ve outbox backlog erken sinyal verir. Saga duration ve compensation rate business workflow health'ini gösterir. Duplicate event ve conflict rate messaging/concurrency sorunlarını açığa çıkarır. Reconciliation failure gerçek state farklarını doğrudan gösterir.

Replication Lag

Primary ve followers arasındaki progress farkıdır. Spikes network veya disk problemine işaret edebilir. Stale read riskini artırır. Failover RPO etkilenir. Dashboard node ve region bazında göstermelidir.

Consumer Lag

Event consumer broker'ın gerisinde kaldığında projection stale olur. Partition bazında maksimum lag önemlidir. Hot partition average metriği gizleyebilir. Autoscaling lag'e göre tetiklenebilir. Poison event tek partition'ı durdurmamalıdır.

Outbox Backlog

Unpublished outbox row sayısı ve oldest age izlenir. Relay failure hızlı fark edilir. Database storage büyümesi önlenir. Sudden spike broker outage gösterebilir. Recovery publication rate backlog'u eritmelidir.

Saga Duration

Business process'in start'tan terminal state'e süresi ölçülür. Long tail stuck workflow gösterebilir. Step-level span root cause'u bulur. Business timeout ayrı metrik olmalıdır. User pending experience bu süreyle ilişkilidir.

Compensation Rate

Çok sık compensation normal flow'da sorun olduğunu gösterebilir. Payment failure veya inventory contention olabilir. Rate business segment bazında incelenir. Compensation'ın kendisi başarısız olabilir. Failed compensation critical alert üretir.

Duplicate Event Rate

Inbox duplicate count broker retry davranışını görünür yapar. Ani artış producer retry veya consumer ack sorununa işaret edebilir. Idempotency sayesinde correctness bozulmasa bile infrastructure maliyeti yükselir. Event type bazında ölçülmelidir. Duplicate suppression success izlenir.

Conflict Rate

Optimistic concurrency reject veya CRDT concurrent branch sayısı contention sinyalidir. High rate data modelin yanlış partition'landığını gösterebilir. User retry deneyimi etkilenir. Hot entity'ler bulunur. Pessimistic alternative değerlendirilebilir.

Reconciliation Failure

Source ve target arasında fark bulunması consistency gap'ini doğrudan kanıtlar. Count ve financial amount gibi severity metrics tutulur. Automatic repair başarısızsa manual escalation yapılır. Trend release correlation sağlar. Zero-difference hedefleri data class'a göre belirlenir.

Distributed Tracing Tutarlılık Sorunlarını Nasıl Bulur?

Distributed trace tek business transaction'ın service ve message sınırları boyunca nasıl ilerlediğini gösterir. Trace ID synchronous calls için ortak bağ sağlar. Correlation ve Saga ID long-running async workflow'u ilişkilendirir. Message ID duplicate delivery'yi tanımayı kolaylaştırır. Timeline hangi step'in önce veya sonra gerçekleştiğini gözlemlemeye yardım eder.

Trace ID

HTTP request boyunca ortak identifier taşınır. Database ve broker spans aynı trace'e bağlanabilir. Async process için trace continuation uygulanabilir. Sampling consistency incidents için yeterli coverage sağlamalıdır. Sensitive business IDs doğrudan trace ID yapılmamalıdır.

Correlation ID

Birden fazla request aynı business flow'a ait olabilir. Correlation ID bunları birleştirir. User support order timeline'ını takip edebilir. ID event headers içinde taşınır. Logging system bunu indexler.

Saga ID

Her Saga instance unique ID taşır. Orchestrator state ve events bu ID'yi kullanır. Compensation chain aynı context'te görünür. Reconciliation stuck Saga'yı ID ile bulur. Business transaction timeline kolaylaşır.

Message ID

Her event unique identity taşır. Producer publish attempt'leri aynı ID'yi korur. Consumer duplicate detection yapar. Trace'de aynı message'ın tekrar işlendiği görülebilir. ID log retention boyunca searchable tutulur.

Causal Chain

Parent event ID child event metadata'da bulunabilir. Böylece “bu event neden oluştu?” sorusu cevaplanır. Event-driven choreography debugging kolaylaşır. Causal chain global ordering gerektirmez. Root business command'a kadar iz sürülebilir.

Business Transaction Timeline

Order created, stock reserved, payment authorized ve shipment requested zamanları birlikte görünür. Out-of-order veya uzun gap açıkça fark edilir. Wall clock yalnız gözlem amaçlı kullanılır. Correctness protocol version metadata ile doğrulanır. Incident analizi çok daha hızlı olur.

Reconciliation Job Nedir?

Reconciliation farklı sistemlerin aynı business reality'yi temsil edip etmediğini düzenli karşılaştıran süreçtir. Distributed systems'de bütün failure'ların realtime engellenemeyeceği kabul edilir. Missing event, duplicate record veya orphan state sonradan bulunabilir. Critical financial sistemlerde reconciliation ana correctness katmanlarından biridir. Automatic repair güvenli değilse human review gerekir.

Source vs Target Karşılaştırması

Authoritative database count veya IDs projection ile karşılaştırılır. Difference report üretilir. Large datasets incremental hash veya partition-based compare kullanabilir. Full scan maliyeti yönetilir. Source of truth net olmalıdır.

Orphan Record

Target sistemde source karşılığı olmayan record orphan'dır. Event order veya failed delete sebep olabilir. Automatic deletion riskli olabilir. Audit history incelenir. Business owner repair rule belirler.

Missing Event

Database state ilerlemiş fakat downstream event yoktur. Outbox gap veya connector issue olabilir. Event yeniden üretilebilir. Duplicate-safe consumer gereklidir. Root cause tekrarını önlemek için relay incelenir.

Duplicate Record

Retry aynı business operation'ı iki entity olarak oluşturmuş olabilir. Unique constraint eksikliği root cause'dur. Merge veya cancel gerekebilir. Financial impact hesaplanır. Idempotency key coverage artırılır.

Financial Reconciliation

Internal ledger payment provider settlement ile karşılaştırılır. Amount ve transaction IDs eşleştirilir. Missing veya duplicate payment investigation'a alınır. Daily ve intraday checks kullanılabilir. Difference sıfır değilse close yapılmayabilir.

Automatic Repair

Source authoritative ve repair deterministic ise target yeniden yazılabilir. Search index document buna uygundur. Financial state automatic mutation daha riskli olabilir. Repair event audit edilir. Rate limit target sistemi korur.

Manual Escalation

Ambiguous conflict human decision isteyebilir. Case bütün evidence ve trace bilgisiyle queue'ya düşer. Operator correction action seçer. Audit log tutulur. SLA reconciliation SLO'ya bağlıdır.

Veri Tutarlılığı Nasıl Test Edilir?

Happy-path integration test consistency garantisini kanıtlamaz. Concurrent writes, duplicate messages ve out-of-order delivery kontrollü biçimde üretilmelidir. Node failure ve partition sırasında invariant'lar doğrulanmalıdır. Clock skew timestamp-based conflict logic'i test eder. Test başarı kriteri yalnız service up olması değil business rule'ların korunmasıdır.

Business Invariant Testleri

Random operation sonrası stok negatif olmamalıdır. Duplicate payment count sıfır olmalıdır. Unique seat iki owner taşımamalıdır. Assertions database ve projections üzerinde çalışır. Failure injection sırasında da aynı invariant korunmalıdır.

Concurrent Write Testleri

Yüz request aynı resource'u update eder. Lost update veya oversell aranır. Optimistic conflict count beklenen davranış olabilir. Final state mathematical expectation ile karşılaştırılır. Test gerçek database isolation kullanmalıdır.

Duplicate Delivery

Aynı message iki veya daha fazla kez consumer'a gönderilir. Business side effect yalnız bir kez uygulanmalıdır. Inbox duplicate count artar. Consumer ack normal tamamlanır. External API mock idempotency doğrular.

Out-of-Order Event

Version 3 event'i version 2'den önce gönderilir. Consumer state'i yanlış geriye taşımamalıdır. Buffer veya reject policy çalışır. Missing version recovery test edilir. Metrics gap'i göstermelidir.

Retry

Network timeout intentionally oluşturulur. Operation aslında commit olmuş olabilir. Client retry same idempotency key ile gelir. Duplicate entity oluşmamalıdır. Final response deterministic olmalıdır.

Node Failure

Primary veya consumer process kill edilir. Recovery yeni node üzerinde devam eder. Committed state kaybolmamalıdır gereken modelde. In-flight ambiguity test edilir. Retry behavior gözlemlenir.

Network Partition

Cluster nodes iki gruba ayrılır. Strong system minority writes reddetmelidir. Available system conflicts beklenen şekilde merge etmelidir. Healing sonrası convergence ölçülür. Split-brain guard doğrulanır.

Clock Skew

Node saatleri kontrollü olarak ileri ve geri kaydırılır. LWW behavior incelenir. Lease expiry correctness test edilir. Logical version etkilenmemelidir. Monitoring clock drift alarmı doğrulanır.

Jepsen-Style Consistency Testing

Jepsen tarzı testler distributed storage'ın failure altındaki operation history'sini kaydedip iddia edilen consistency modeline uyup uymadığını analiz eder. Sadece throughput benchmark değildir. Process kill, network partition ve clock disturbance gibi faults kontrollü uygulanır. Operation invocation ve completion history tutulur. Sonra linearizability veya transactional model checker history'nin legal olup olmadığını değerlendirir.

Operation History

Her operation start ve completion event'i kaydedilir. Input ve observed output tutulur. Concurrent structure bu history'den çıkarılır. Timeout incomplete operation olarak ele alınır. Checker bütün olası legal order'ları değerlendirir.

Fault Injection

Failure random veya scheduled uygulanır. Network, process ve disk problem scenarios bulunabilir. Test workload failure boyunca devam eder. Recovery sonrası convergence gözlenir. Fault timeline history ile korele edilir.

Process Kill

Leader veya replica aniden durdurulur. In-flight writes ambiguity yaratır. Election behavior gözlenir. Client retries operation ID ile kaydedilir. Safety ve liveness ayrı değerlendirilir.

Network Partition

Nodes belirli topology ile birbirinden ayrılır. Majority/minority behavior görülür. Split-brain write kabulü aranır. Partition healing sonrası state compare edilir. Availability kararları ölçülür.

Clock Distortion

Physical time dependent systems clock shifts altında test edilir. Lease ve LWW bugs bulunabilir. Logical-clock systems daha dayanıklı olmalıdır. TLS veya certificate side effects test ortamında dikkate alınır. Clock test kontrollü yapılır.

Linearizability Checking

Checker observed operations için real-time consistent sequential explanation arar. Bulamazsa violation vardır. Small histories exact checking daha kolaydır. Workload register veya CAS gibi operation types seçebilir. Failure altında hidden bugs ortaya çıkabilir.

Serializability Checking

Transactional history dependency graph üzerinden analiz edilebilir. Cycles anomaly gösterebilir. Real-time constraint eklenirse strict serializable kontrolü yapılır. Test workload multi-object transactions içermelidir. Isolation claim production configuration ile aynı olmalıdır.

Property-Based Testing ile Business Invariant'ları Test Etmek

Property-based testing tek tek örnek senaryo yazmak yerine rastgele operation dizileri üretir. Her sequence sonunda invariant kontrol edilir. Concurrent request kombinasyonları insanın düşünmediği edge case'leri bulabilir. Failure bulunduğunda shrinking minimum tekrar üretilebilir örneği arar. CI pipeline düzenli correctness regression testi çalıştırabilir.

Random Operation Sequences

Create, reserve, cancel ve retry operations rastgele sırada üretilir. Inputs domain constraints içinde çeşitlenir. Long sequence hidden state bug'larını ortaya çıkarabilir. Seed failure tekrarını sağlar. Coverage business scenarios ile dengelenmelidir.

Concurrent Requests

Operations parallel workers üzerinden gönderilir. Timing random delay ile değiştirilir. Race windows büyütülür. Final state expected invariant ile karşılaştırılır. Database gerçek isolation setting kullanılır.

Invariant Assertions

Stock sıfır altına inmez. Payment operation ID unique kalır. Ledger sum balance eder. Saga terminal state valid kombinasyonda olur. Assertion implementation source state'i doğru okumalıdır.

Shrinking Failed Cases

Property framework failure sequence'i küçültmeye çalışır. Yüz operation yerine beş adımlı minimal reproduction bulunabilir. Debugging kolaylaşır. Seed ve output CI artifact olarak saklanır. Regression test haline getirilir.

CI Pipeline Entegrasyonu

Kısa deterministic suites her commit çalışabilir. Uzun concurrency fuzz nightly yapılabilir. Failure seed repository'ye eklenir. Environment production database version'ına yakın tutulur. Flaky test olarak görmezden gelinmemelidir.

Chaos Engineering ve Veri Tutarlılığı

Chaos engineering sistemin failure altındaki correctness ve recovery davranışını kontrollü biçimde doğrular. Yalnız availability testi yapılmamalıdır. Replica durdurulduğunda acknowledged writes korunuyor mu sorulmalıdır. Broker kesildiğinde outbox backlog güvenli büyüyor mu kontrol edilmelidir. Duplicate ve reordered event tests business consistency'nin gerçekten dayanıklı olduğunu gösterir.

Replica'yı Durdurmak

Synchronous quorum write availability etkilenebilir. Async replica lag infinite hale gelir. Failover başka replica'ya yapılabilir. Committed data compare edilir. Recovery sonrası catch-up süresi ölçülür.

Broker'ı Kesmek

Application database transaction'ları devam edebilir. Outbox rows birikir. Direct dual-write kullanılan sistem event kaybı yaşayabilir. Broker recovery sonrası backlog yayınlanır. Consumer idempotency duplicates'i güvenli işler.

Network Latency Eklemek

Cross-service timeout behavior gözlenir. Consensus p99 yükselir. Retry storm oluşup oluşmadığı kontrol edilir. Saga timeout policy çalışır. User SLO impact ölçülür.

Event Duplicate Etmek

Broker veya test proxy aynı event'i tekrar gönderir. Consumer business change'i tekrar etmemelidir. Inbox metric duplicate'i sayar. External call idempotency test edilir. Compensation duplicate-safe olmalıdır.

Event Sırasını Bozmak

Version 5 önce, 4 sonra gönderilir. Consumer stale event'i uygulamamalıdır. Gap recovery mekanizması çalışır. Projection eventually doğru state'e gelir. Alert unexpected reorder rate'i gösterebilir.

Consistency Recovery'yi Ölçmek

Fault kaldırıldıktan sonra sistem ne kadar sürede converged olur ölçülür. Replication ve consumer backlog normalize olmalıdır. Reconciliation zero difference vermelidir. Stuck Saga kalmamalıdır. Bu süre recovery SLO olarak kaydedilir.

Consistency Incident Runbook

Consistency incident sırasında ilk hedef rastgele data düzeltmek değil ihlal edilen invariant'ı ve yayılma alanını anlamaktır. Event akışını durdurmak bazı durumlarda yeni yanlış state'i engeller. Outbox veya consumer replay yapılmadan duplicate-safe olduğundan emin olunmalıdır. Reconciliation authoritative fark listesini üretir. Düzeltme sonrası invariant'lar yeniden doğrulanmalıdır.

Hangi Invariant Bozuldu?

Incident “data farklı” gibi genel ifade yerine net rule ile tanımlanmalıdır. Duplicate payment mı oluştu, missing order mı var belirlenir. Severity business impact'ten çıkarılır. Detection timestamp kaydedilir. Daha geniş scan aynı violation'ın başka instances'ını arar.

Hangi Servisler Etkilendi?

Source database ve projections inventory çıkarılır. Search, cache ve analytics stale olabilir. Consumer groups kontrol edilir. Shared event contract impact belirlenir. User-facing surfaces listelenir.

Event Akışı Durmalı mı?

Bug yeni corrupt events üretmeye devam ediyorsa producer durdurulabilir. Tam broker shutdown gereksiz olabilir. Affected event type pause edilir. Backlog retention yeterli olmalıdır. Correct fix sonrası controlled resume yapılır.

Outbox/Consumer Replay

Missing publication outbox'tan yeniden gönderilebilir. Consumer offset geri alınabilir. Duplicate-safe processing doğrulanmalıdır. External side effects replay dışında tutulabilir. Replay rate downstream capacity'yi aşmamalıdır.

Reconciliation

Authoritative source ile target compare edilir. Exact affected records listesi çıkarılır. Repair plan buna göre oluşturulur. Financial totals ayrıca doğrulanır. Difference sıfıra gelene kadar incident kapanmamalıdır.

Compensation

Yanlış business effect yeni action ile dengelenir. Refund veya reservation release gerekebilir. User notification planlanır. Compensation idempotent çalışır. Legal veya audit record korunur.

Veri Düzeltme

Direct SQL update son çare olarak controlled script ile yapılmalıdır. Source-of-truth semantics korunur. Audit log oluşturulur. Script dry-run output verir. Repair application invariants'ını bypass etmemelidir.

Incident Sonrası Doğrulama

Reconciliation tekrar çalıştırılır. Lag metrics normale döner. Invariant property tests eklenir. Root cause'a uygun alert oluşturulur. Runbook öğrenilenlerle güncellenir.

Açık Kaynak ve İşbirliği Ekosistemi

Dağıtık consistency konuları açık kaynak projelerde gerçek implementation örnekleriyle görülebilir. Apache Kafka event ordering ve transactional processing alanında, Apache Cassandra tunable consistency ve leaderless replication alanında önemli örnekler sunar. PostgreSQL synchronous replication ve transactional consistency için güçlü bir temel oluşturur. etcd ve ZooKeeper coordination ile consensus tabanlı metadata sorunlarında kullanılır. Debezium, Temporal ve Jepsen gibi projeler CDC, durable workflow ve fault altında correctness doğrulaması için yararlı öğrenme alanları sağlar.

Apache Kafka

Kafka partition ordering ve replicated log modeliyle event-driven architecture'ın temel projelerinden biridir. Modern producer idempotence duplicate producer retries riskini azaltır. Transactions Kafka records ve offsets arasında stronger processing semantics sağlayabilir. External side effect yine application coordination ister. Event key ve partition tasarımı consistency behavior'ını etkiler.

Apache Cassandra

Cassandra leaderless replication ve tunable consistency seviyeleriyle farklı trade-off'ları gözlemlemek için güçlü örnektir. ONE, QUORUM ve ALL operation behavior'ını değiştirir. Conditional updates SERIAL veya LOCAL_SERIAL phase üzerinden Paxos kullanabilir. Repair ve replication management convergence için önemlidir. Data model partition-first düşünülmelidir.

PostgreSQL

PostgreSQL local ACID transactions ve güçlü isolation seçenekleri sunar. Streaming replication synchronous veya asynchronous kullanılabilir. Quorum synchronous standby configuration farklı durability hedeflerini destekler. Logical decoding CDC architecture'larına temel olabilir. Microservice source-of-truth database olarak sık kullanılır.

etcd

etcd distributed key-value coordination store olarak güçlü consistency kullanım alanlarına sahiptir. Raft replicated log üzerinden ordering sağlar. Configuration, leader metadata ve service coordination için uygundur. Büyük application data store olarak her workload'a uygun değildir. Lease ve watch semantics cluster control plane tasarımlarında değerlidir.

ZooKeeper

ZooKeeper distributed coordination ve metadata management için tasarlanmıştır. Zab protocol leader ordering ve replicated state sağlar. Ephemeral nodes membership use case'lerinde kullanılır. Session semantics application design'ını etkiler. Bulk business data storage için tercih edilmez.

Debezium

Debezium transaction log tabanlı CDC için açık kaynak connector ekosistemidir. Database changes event streams'e taşınabilir. Transactional outbox pattern ile birlikte dual-write riskini azaltır. Connector lag consistency SLO'ya dahil edilmelidir. Schema evolution controlled yönetilmelidir.

Temporal

Temporal durable workflow state ve retry orchestration için kullanılan açık kaynak workflow platformlarından biridir. Long-running process state application memory'ye bağlı kalmaz. Activities retry ve timeout policy taşıyabilir. Saga compensation workflow code içinde açık tanımlanabilir. Platform kullanılsa bile business idempotency requirement devam eder.

Jepsen

Jepsen distributed systems correctness iddialarını fault injection altında test etmeye odaklanan açık kaynak ekosistemdir. Operation histories consistency model checkers ile analiz edilir. Network partition ve process failure gibi faults uygulanabilir. Linearizability ve serializability kavramlarını pratik biçimde anlamaya yardım eder. Benchmark hızından çok safety davranışını inceler.

Open Source Fault-Injection Araçları

Network proxy, container chaos ve process management araçları failures simüle edebilir. Latency, packet loss ve connection reset uygulanabilir. Kubernetes chaos tooling pod ve network disruptions oluşturabilir. Tool seçimi invariant testlerinden daha önemli değildir. Fault test sonucunda business correctness assertion çalışmalıdır.

Community Tarafından Consistency Doğrulaması

Açık issue ve reproducible testler distributed database davranışlarını daha görünür kılar. Academic papers ile implementation bug reports birlikte incelenebilir. Version upgrade sırasında geçmiş consistency incident'ları faydalı bağlam sağlar. Topluluk projeleri üzerinde ortak test geliştirmek güçlü öğrenme yoludur. Diyarbakır Yazılım Topluluğu tarafından paylaşılan çalışma ve proje yaklaşımını incelemek için https://www.diyarbakiryazilim.com.tr/projects adresi kullanılabilir.

Kurumsal Veri Tutarlılığı İçin Adım Adım Yol Haritası

Kurumsal veri tutarlılığı çalışması database veya broker ürününü değiştirmekle başlamamalıdır. Önce business invariant'lar listelenir ve hangi boundary içinde korunabilecekleri belirlenir. Her veri sınıfına gerekli minimum consistency modeli atanır. Dual write, retries ve event ordering gibi riskler pattern'lerle kontrol altına alınır. Son adım observability ve failure testing ile guarantees'in gerçekten production koşullarında çalıştığını doğrulamaktır.

1. Business Invariant'ları Belirleyin

Domain workshop ile asla bozulmaması gereken rules yazılır. Financial, inventory ve identity kuralları ayrılır. Her invariant violation business impact taşır. Owner atanır. Test assertion oluşturulur.

2. Consistency Boundary'leri Çizin

Invariant hangi entities'i kapsıyor belirlenir. Aynı database içinde tutulabilecek state gruplanır. Service decomposition gözden geçirilir. Cross-boundary dependencies listelenir. Gereksiz distributed transaction azaltılır.

3. Her Veri İçin Consistency Modelini Belirleyin

Strong, read-your-writes, bounded veya eventual seçenekleri değerlendirilir. Staleness tolerance yazılır. User experience expectation eklenir. Read ve write farklı model taşıyabilir. Matrix architecture document'a eklenir.

4. Replication Modelini Seçin

Leader-based veya leaderless ihtiyaç değerlendirilir. Synchronous ack durability hedefinden türetilir. Multi-region latency hesaplanır. Replica reads consistency contract'a uygun yönlendirilir. Lag SLO oluşturulur.

5. Distributed Transaction Gereksinimini Azaltın

Service boundaries business capability ile yeniden kontrol edilir. Same-invariant data mümkünse aynı local transaction'da tutulur. External calls transaction lock içinde yapılmaz. Reservation kullanılır. Workflow async steps'e bölünür.

6. Gerekirse Saga Tasarlayın

Local transaction steps listelenir. Failure policy her step için yazılır. Forward retry ve compensation ayrılır. Orchestration veya choreography seçilir. Saga timeout ve terminal states belirlenir.

7. Dual Write İçin Outbox Kullanın

Business data ile event intent aynı transaction'da kaydedilir. Relay veya CDC publication yapar. Event ID ve aggregate version eklenir. Outbox backlog izlenir. Cleanup policy tanımlanır.

8. Consumer'ları Idempotent Yapın

Message ID duplicate detection sağlanır. Inbox veya unique constraints kullanılır. External side effects idempotency key alır. Retry bounded olur. Duplicate tests CI'a eklenir.

9. Event Ordering Kuralını Tanımlayın

Global ordering gerekip gerekmediği sorgulanır. Aggregate ID partition key yapılabilir. Sequence number event'e eklenir. Gap handling tanımlanır. Out-of-order tests uygulanır.

10. Conflict Resolution Politikası Oluşturun

Hangi data merge edilebilir belirlenir. LWW yalnız düşük-risk alanlarda kullanılır. Manual conflict workflow gerekirse tasarlanır. CRDT uygun data types için değerlendirilir. Audit kaybolan branch'i koruyabilir.

11. Reconciliation Job'ları Ekleyin

Source ve projections düzenli karşılaştırılır. Financial state external provider ile eşleştirilir. Missing events repair edilir. Manual queue oluşturulur. Reconciliation SLO tanımlanır.

12. Consistency SLO'ları Tanımlayın

Replication lag limiti yazılır. Projection freshness hedefi belirlenir. Outbox age threshold eklenir. Business invariant violation rate izlenir. Alert owner atanır.

13. Observability Kurun

Trace ID ve message ID standardı uygulanır. Saga timeline dashboard hazırlanır. Lag ve backlog metrics eklenir. Conflict ve duplicate rate izlenir. Data correction actions audit edilir.

14. Network Partition ve Duplicate Event Testleri Yapın

Chaos ortamı gerçek dependencies'i içerir. Network split senaryosu uygulanır. Duplicate ve reordered events oluşturulur. Invariants her aşamada kontrol edilir. Recovery convergence süresi ölçülür.

15. Production Consistency Drill'leri Gerçekleştirin

Planlı düşük-risk drills runbook'u sınar. Replica failure veya consumer pause kontrollü yapılır. On-call ekip dashboard ve repair workflow kullanır. Sonuçlar review edilir. Kurumsal dağıtık sistem ve veri tutarlılığı mimarisi danışmanlığı süreçlerinde bu tür doğrulamalar teorik tasarımı gerçek operasyon yetkinliğine dönüştürür.

En Sık Yapılan Veri Tutarlılığı Hataları

Consistency hatalarının önemli kısmı teknoloji eksikliğinden değil kavramların fazla basitleştirilmesinden doğar. CAP sloganı veya “Kafka exactly once” ifadesi business correctness'in yerine konabilir. Replication var diye stale read riski unutulabilir. Saga compensation klasik rollback sanılabilir. En güvenli yaklaşım guarantees'i explicit yazmak ve failure altında doğrulamaktır.

CAP'i “Üçünden İkisini Seç” Diye Ezberlemek

Partition olmadığı durumda teori böyle bir sürekli seçim dayatmaz. P distributed network için failure gerçeğidir. Karar partition sırasında C veya A davranışıdır. Latency boyutu PACELC ile düşünülür. Slogan yerine operation semantics konuşulmalıdır.

Bütün Veriler İçin Strong Consistency İstemek

Global coordination her read ve write'ı yavaşlatabilir. Recommendation veya analytics buna ihtiyaç duymaz. Availability gereksiz azalabilir. Data classes ayrılmalıdır. Strong yalnız business invariant gereken yerde kullanılmalıdır.

Bütün Veriler İçin Eventual Consistency Kullanmak

Payment ve seat allocation sonradan merge edilemeyebilir. User iki başarı response'u aldıktan sonra biri geri alınmak zorunda kalır. Business güven kaybı oluşur. Critical state stronger coordination ister. Eventual moda dönüşmemelidir.

Database Transaction'ını Mikroservisler Arasında Uzatmaya Çalışmak

Transaction açıkken remote HTTP call yapmak lock süresini büyütür. Service outage local database resources'ı tutar. Timeout rollback semantics'i belirsiz hale gelir. Local transaction kısa tutulmalıdır. Cross-service process Saga ile yönetilebilir.

Database + Broker Dual Write Yapmak

İki ayrı write atomik değildir. Sıra değiştirmek failure gap'i ortadan kaldırmaz. Outbox pattern daha güvenilir intent publication sağlar. Consumer idempotent kalır. Direct dual write yalnız controlled semantics ile kullanılmalıdır.

Consumer'ları Idempotent Tasarlamamak

At-least-once broker duplicate event gönderebilir. Network error bunu normal hale getirir. Consumer duplicate ödeme veya stock decrement yapmamalıdır. Message IDs kullanılmalıdır. Duplicate tests mandatory olmalıdır.

Exactly-Once'a Körü Körüne Güvenmek

Broker transactional guarantee scope'u sınırlıdır. External database veya API aynı transaction'a dahil olmayabilir. Application-level retries yeni duplicates yaratabilir. End-to-end idempotency gerekir. Guarantee'nin sınırı documentation'da açık yazılmalıdır.

Event Ordering'i Varsaymak

Parallel producers veya partitions ordering'i değiştirebilir. Retry de event'i geç getirebilir. Aggregate sequence number kullanılmalıdır. Consumer stale event'i fark etmelidir. Global ordering gereksiz maliyet yaratır.

Last-Write-Wins'i Her Conflict'te Kullanmak

LWW valid user update'i sessizce silebilir. Timestamp clock skew taşır. Critical state için unacceptable olabilir. Domain merge veya conflict error daha güvenlidir. LWW yalnız loss-tolerant data'da kullanılmalıdır.

Wall Clock ile Conflict Çözmek

Distributed clocks tam senkron değildir. Client time güvenilir olmayabilir. Future timestamp persistent winner olabilir. Logical version tercih edilmelidir. Physical time audit amaçlı saklanabilir.

Replication'ı Consistency Garantisi Sanmak

Replica olması availability ve durability sağlar. Asynchronous replica stale olabilir. Leaderless replica conflicting versions taşıyabilir. Read consistency ayrıca belirlenmelidir. Protocol semantics incelenmelidir.

Saga Compensation'ı Gerçek Transaction Rollback Sanmak

Refund charge'ı tarihten silmez. Email geri alınamaz. Intermediate state görünür olabilir. Compensation yeni business operation'dır. Isolation ayrıca tasarlanmalıdır.

Reconciliation Mekanizması Kurmamak

Distributed failure hiçbir zaman sıfır değildir. Missing event veya unknown external result kalabilir. Reconciliation final safety net sağlar. Financial systems için kritik önemdedir. Repair path düzenli test edilmelidir.

Replication/Consumer Lag İzlememek

Eventual consistency window ölçülmezse user staleness bilinmez. Lag artışı capacity sorunu olabilir. Failover data loss riskini büyütür. SLO ve alerts gerekir. Average yerine worst partition izlenmelidir.

Consistency Garantilerini Failure Altında Test Etmemek

Normal network'te bütün sistemler tutarlı görünebilir. Gerçek bugs partition ve retry sırasında çıkar. Chaos ve Jepsen-style tests gerekir. Business invariants sürekli assert edilmelidir. Production drills operasyon hazırlığını doğrular.

Sık Sorulan Sorular

Dağıtık sistemlerde consistency konusunda en sık karıştırılan konular güçlü garanti, eventual yaklaşım, CAP, quorum ve distributed transaction modelleridir. Bir database veya broker özelliğinin adını bilmek tek başına doğru business behavior sağlamaz. Her modelin hangi failure durumunda ne garanti ettiğini anlamak gerekir. Microservice tasarımında outbox, idempotency ve reconciliation birlikte düşünülmelidir. Aşağıdaki cevaplar temel karar noktalarını kısa fakat uygulamaya dönük biçimde özetler.

Dağıtık sistemlerde veri tutarlılığı nedir?

Dağıtık sistemlerde veri tutarlılığı aynı logical state'in farklı replicas ve services tarafından hangi sıra ve freshness ile görüldüğünü tanımlar. Strong model yeni write'ı daha hızlı ve kesin görünür kılabilir. Eventual model geçici farklılığı kabul eder. Session ve causal modeller arada farklı guarantees sunar. Seçim business invariant ve staleness riskine göre yapılmalıdır.

Strong consistency nedir?

Strong consistency genel kullanımda successful write sonrası yeni read'in güncel state'i görmesini hedefler. Daha teknik requirement için linearizability gibi net model isimleri kullanılmalıdır. Coordination ve network round-trip gerekir. Partition sırasında availability azalabilir. Payment veya reservation gibi critical operations için uygun olabilir.

Eventual consistency nedir?

Eventual consistency replicas'ın kısa süre farklı version taşımasına izin verir. Yeni update gelmezse sonunda aynı state'e yakınsamaları beklenir. Convergence süresi ayrıca SLO ile sınırlandırılmalıdır. Read-your-writes kullanıcı deneyimini iyileştirebilir. Catalog ve analytics gibi alanlarda sık kullanılır.

Strong ve eventual consistency arasındaki fark nedir?

Strong yaklaşım visibility için daha fazla coordination kullanır. Eventual model write/read latency ve availability avantajı için geçici staleness kabul eder. Strong daha pahalı olsa da bazı invariant'ları korumak için gereklidir. Eventual consistency tutarsızlığın kalıcı olması anlamına gelmez. Aynı application iki modeli birlikte kullanabilir.

Linearizability nedir?

Linearizability operation'ların atomik bir noktada gerçekleşmiş gibi ve gerçek zaman sırasına uyumlu görünmesini ister. Önce biten operation daha sonra başlayan operation'dan logical olarak sonra gelemez. Single-object consistency için güçlü modeldir. Network partition sırasında total availability ile birlikte sağlanamaz. Distributed locks ve metadata gibi alanlarda değerlidir.

Serializability ile linearizability arasındaki fark nedir?

Serializability multi-object transactions'ın bir serial order ile açıklanmasını ister. Real-time order zorunlu değildir. Linearizability real-time constraint taşır ve object operation'larına odaklanır. Strict serializability ikisini birleştirir. Hangi guarantee gerektiği business transaction scope'una bağlıdır.

CAP teoremi ne söyler?

Network partition sırasında distributed system hem strong single-copy consistency hem de bütün requests için availability garanti edemez. Partition tolerance gerçek network'te kaçınılmazdır. Bu nedenle “üçünden iki seç” ifadesi eksik kalır. Operation bazında failure behavior seçilmelidir. Normal zamanda latency trade-off'u PACELC ile ayrıca düşünülür.

PACELC nedir?

PACELC partition sırasında availability-consistency seçimini, partition yokken latency-consistency dengesini hatırlatır. Global synchronous writes normal zamanda da WAN latency'si ödetir. Local eventual reads daha hızlı olabilir. Architecture her operation için günlük cost'u değerlendirmelidir. CAP ile birlikte kullanıldığında multi-region kararları daha anlaşılır olur.

Quorum nedir?

Quorum belirli sayıda replica response'una dayanarak operation tamamlamaktır. N replication factor, W writes ve R reads için düşünülebilir. Intersection newest state'e erişme ihtimalini güçlendirir. Ancak quorum tek başına linearizability garantisi değildir. Protocol conflict ve ordering semantics'i ayrıca önemlidir.

Raft ile Paxos arasındaki fark nedir?

İkisi de consensus problemine çözüm ailesi sunar. Raft leader election ve replicated log'u eğitim açısından daha ayrık parçalarla tanımlar. Paxos daha genel consensus framework'ü ve birçok varyantı bulunan klasik yaklaşımdır. Modern implementation'lar Multi-Paxos benzeri stable leader optimizasyonları kullanabilir. Product choice çoğu zaman uygulamanın doğrudan algoritmayı seçmesinden değil kullandığı storage veya coordination service'ten gelir.

Saga pattern nedir?

Saga distributed business operation'ı local transactions dizisine böler. Her step bağımsız commit edilir. Failure durumunda retry veya compensating transaction çalışır. Global ACID rollback sağlamaz. Long-running microservice workflow'larda 2PC yerine daha availability-friendly yaklaşım olabilir.

Transactional Outbox nedir?

Business database change ile yayınlanacak event intent aynı local transaction'da yazılır. Böylece database başarılı event kayıp dual-write gap'i kapanır. Relay veya CDC event'i broker'a taşır. Duplicate publication mümkün olabilir. Consumer idempotent tasarlanır.

Dual write problemi nedir?

Application database ve broker gibi iki bağımsız sisteme ayrı write yaptığında partial failure oluşabilir. Biri başarılı diğeri başarısız olabilir. İşlem sırasını değiştirmek sorunu ortadan kaldırmaz. Outbox local atomicity kullanır. 2PC desteklenen özel durumda başka seçenek olabilir.

Idempotency neden gereklidir?

Retry aynı logical operation'ı birden fazla kez getirebilir. Idempotency duplicate side effect'i önler. Operation ID, message ID ve unique constraint kullanılabilir. External payment API mümkünse idempotency key almalıdır. At-least-once messaging güvenli hale gelir.

Exactly-once gerçekten mümkün müdür?

Exactly-once ancak scope açık tanımlandığında anlamlıdır. Kafka gibi platformlar kendi transaction boundary'lerinde güçlü processing semantics sağlayabilir. Harici database veya API side effect'i otomatik olarak aynı guarantee'ye dahil değildir. Destination transaction veya idempotency gerekir. End-to-end business exactly-once çoğu zaman duplicate-safe design ile sağlanır.

CRDT nedir?

CRDT concurrent updates'in coordination olmadan deterministic merge edilebildiği data structures ailesidir. Replicas aynı update set'ini aldığında aynı state'e ulaşabilir. Counter ve set gibi türler doğal adaydır. Global uniqueness için uygun değildir. Metadata ve domain semantics dikkate alınmalıdır.

Eventual consistency nasıl test edilir?

Replica veya projection lag ölçülmelidir. Duplicate ve reordered events oluşturulmalıdır. Network partition sonrası convergence doğrulanmalıdır. Read-your-writes gibi ek guarantees ayrıca test edilir. Reconciliation source ve target'ın sonunda aynı state'e ulaştığını kontrol eder.

Mikroservislerde veri tutarlılığı nasıl sağlanır?

Önce consistency boundary ve business invariant belirlenir. Local ACID transaction mümkün olduğunca service içinde kullanılır. Cross-service workflow için Saga, outbox ve idempotent consumers uygulanabilir. Event ordering ve retries açıkça tasarlanır. Reconciliation ve observability kalan failure gap'lerini yönetir.

Dağıtık sistemlerde veri tutarlılığı (Data Consistency) nasıl sağlanır?

Dağıtık sistemlerde veri tutarlılığı business invariant'ları tanımlayarak, operation bazında doğru consistency modelini seçerek ve failure davranışını açık biçimde tasarlayarak sağlanır. Replication tek başına yeterli değildir, çünkü stale replica, concurrent write ve message duplication gibi durumlar ayrıca yönetilmelidir. Local transaction, optimistic concurrency, quorum, consensus, Saga, outbox ve reconciliation farklı problemlere hizmet eden araçlardır. Observability replication lag, event backlog ve business invariant violation gibi metrikleri takip etmelidir. Dağıtık Sistemlerde Veri Tutarlılığını (Data Consistency) Sağlamak için en güvenilir yaklaşım guarantees'i yalnız dokümante etmek değil partition, retry ve node failure altında test etmektir.

Strong Consistency ile Eventual Consistency arasındaki fark nedir ve hangi durumda hangisi tercih edilmelidir?

Strong consistency yeni write'ın görünür olması için daha fazla coordination kullanır ve payment, inventory allocation veya unique reservation gibi kritik işlemlerde anlamlıdır. Eventual consistency replicas'ın geçici olarak farklı olmasına izin verir ve catalog, social feed, recommendation veya analytics gibi stale read'in düşük risk taşıdığı alanlarda daha ölçeklenebilir olabilir. Strong model latency ve partition availability bedeli getirir. Eventual model ise staleness ve conflict management sorumluluğu ekler. Doğru seçim veri türü değil operation'ın business invariant ve kullanıcı etkisi üzerinden verilmelidir.

CAP Teoremi dağıtık sistemlerde veri tutarlılığı ve erişilebilirlik kararlarını nasıl etkiler?

CAP partition sırasında bütün nodes'a available response vermek ile strong consistency'yi aynı anda garanti etmenin sınırını gösterir. Kritik write operation quorum kaybedildiğinde reddedilebilir ve consistency korunabilir. Düşük riskli feed read local stale data döndürerek availability'yi koruyabilir. Teorem normal zamanda latency maliyetini açıklamadığı için PACELC ile birlikte değerlendirmek daha kullanışlıdır. Böylece sistem genelinde tek CP veya AP etiketi kullanmak yerine operation bazında failure policy tanımlanabilir.

Saga, Transactional Outbox, Event Sourcing ve quorum gibi yöntemler mikroservislerde veri tutarlılığını nasıl sağlar?

Saga uzun business transaction'ı local steps ve compensation üzerinden yönetir, ancak klasik global rollback sağlamaz. Transactional Outbox database değişikliği ile event intent'i aynı local transaction'da yazar ve dual-write gap'ini azaltır. Event Sourcing authoritative history'yi append-only event log olarak tutup projections'ın yeniden oluşturulmasına imkan verir. Quorum replicated storage üzerinde read ve write response set'lerini kontrol eder, fakat tek başına her zaman linearizability garantisi oluşturmaz. Bu araçlar birbirinin alternatifi değil, farklı consistency sorunlarında birlikte kullanılabilen katmanlardır.

Dağıtık sistemlerde veri tutarlılığı ve mikroservis mimarisi konusunda yakınımda danışmanlık veya eğitim nerede bulabilirim?

Dağıtık sistem ve mikroservis danışmanlığı yakınımda şeklinde araştırma yaparken yalnız teknoloji kurulumu değil business invariant, failure modeling, event delivery, reconciliation ve consistency testlerini birlikte ele alan bir yaklaşım aramak faydalıdır. Diyarbakır Yazılım Topluluğu hakkında bilgi için https://www.diyarbakiryazilim.com.tr/about adresi incelenebilir. Veri taşıma sırasında consistency ve kesintisiz geçiş konularıyla ilişkili teknik içerik için https://www.diyarbakiryazilim.com.tr/posts/veritabani-tasima-migration-sureclerinde-sifir-kesinti-taktikleri adresinden devam edilebilir. Kurumsal dağıtık sistem ve veri tutarlılığı mimarisi danışmanlığı değerlendirilirken network partition, duplicate event, replay ve reconciliation testlerinin gerçek kapsamda bulunması önemlidir. Eğitim tarafında ise Saga, outbox, idempotency ve Jepsen-style fault senaryolarını uygulamalı görmek teorik consistency bilgisini production kararlarına dönüştürür.

Sonuç: Dağıtık Sistemlerde Veri Tutarlılığı Nasıl Sürdürülebilir Hale Getirilir?

Dağıtık sistemlerde doğru consistency tasarımı bütün veriyi en güçlü modele zorlamak değil, her business operation için gerekli minimum güvenceyi açık biçimde seçmektir. Payment, stock ve identity daha güçlü coordination isterken catalog, analytics veya recommendation daha gevşek modellerle daha düşük latency ve yüksek availability sağlayabilir. Saga, transactional outbox, idempotency, consensus ve reconciliation doğru problemde kullanıldığında birbirini tamamlayan araçlara dönüşür. Dağıtık Sistemlerde Veri Tutarlılığını (Data Consistency) Sağlamak yalnız mimari diyagram çizmekle bitmez, guarantees'in duplicate delivery, node crash, retry ve network partition altında düzenli olarak doğrulanmasını gerektirir. Dağıtık sistemler, mikroservisler ve backend mimarileri üzerine proje ve topluluk çalışmalarını incelemek için https://www.diyarbakiryazilim.com.tr/projects adresini ziyaret edebilirsiniz.