1. GİRİŞ

Dağıtık sistemler günümüzün bulut tabanlı uygulamalarının, mikroservis ekosistemlerinin, büyük veri platformlarının ve gerçek zamanlı hizmetlerin temelini oluşturur. İnternet ölçeğinde çalışan sistemler tek bir makinede çalıştırılamaz; bu nedenle iş yükleri birden fazla fiziksel veya sanal düğüme dağıtılır. Doğru tasarlanmış dağıtık mimari yüksek erişilebilirlik, yatay ölçeklenebilirlik ve performans sağlar; ancak aynı zamanda koordinasyon, tutarlılık, gecikme ve hata durumlarıyla başa çıkma gibi zorlu problemleri beraberinde getirir.

Bu konu neden bugün önemli?

• Bulut, edge computing ve mikroservislerin benimsenmesi dağıtık sistem tasarımını merkezi bir mühendislik yeteneği haline getirdi.
• Gerçek zamanlı analitik, IoT, finansal sistemler ve büyük ölçekli web hizmetleri dağıtık sistemlerin sağlamlığına doğrudan bağımlıdır.
• AI ve ML iş yüklerinin dağıtık olarak eğitilip servis edilmesi, veri tutarlılığı ve veri aktarım modelleri konusunda güçlü altyapı gerektirir.

Kimler için önemli?

• Yazılım mimarları ve teknik liderler
• Platform mühendisleri, SRE ve DevOps ekipleri
• Backend geliştiriciler ve veri mühendisleri

Hangi problemleri çözüyor?

• Tekrarlanabilir hata senaryolarında hizmet sürekliliği sağlama
• Kullanıcı trafiğini yatay ölçekleyerek performansı koruma
• Veri çoğaltma, koordinasyon ve işlem devamlılığı konularında sorumluluk paylaşma

2. KAVRAMSAL TEMELLER

2.1 Temel tanımlar

Dağıtık Sistem (Distributed System)

Farklı fiziksel veya sanal makinelerde çalışıp birbirleriyle haberleşen bileşenlerin birleşimi; tek bir mantıksal sistem gibi davranır.

Node / Düğüm

Ağ üzerindeki tek bir çalışma birimi — sunucu, konteyner veya edge cihazı olabilir.

Replication (Çoğaltma)

Verinin birden fazla node üzerinde tutulması; dayanıklılık ve yüksek erişilebilirlik sağlar.

Sharding

Verinin yatay bölünmesi; her shard farklı node üzerinde saklanır ve paralel işlem sağlar.

Consensus (Konsensüs)

Dağıtık düğümlerin ortak bir karar vermesini sağlayan algoritma sınıfı (Paxos, Raft).

CAP Teoremi

Consistency, Availability ve Partition‑tolerance arasında aynı anda üçünün tam garantisi mümkün değildir; tasarım trade‑off'larını belirler.

2.2 Temel bileşenler ve terminoloji

• Leader / Follower modelleri — lider seçim, yazma/okuma yönlendirme
• Quorum — bir işlemin kabulü için gerekli minimum onay sayısı
• Clock ve zamanlama: Lamport logical clocks, vector clocks, NTP
• Idempotency, retry, timeout ve backoff stratejileri

3. NASIL ÇALIŞIR? — TEKNİK MİMARİ

3.1 Sistem mimarisi yaklaşımları

Dağıtık sistemlerde mimari seçimler uygulamanın gereksinimlerine göre değişir. Yaygın yaklaşımlar arasında master‑slave (leader/follower), peer‑to‑peer ve event‑driven modeller bulunur. Mimarinin önemli karar noktaları: veri çoğaltma stratejisi, liderlik belirleme yöntemi, state management ve iletişim protokolleridir (gRPC, HTTP/REST, messaging).

3.2 Veri akışı ve çoğaltma

Çoğaltma senaryolarında iki ana yaklaşım vardır: synchronous replication (yazma işlemi tüm replikalara yayılır ve onay beklenir) ve asynchronous replication (yazma lokal olarak onaylanır, replikalara daha sonra iletilir). Synchronous, tutarlılığı artırırken gecikmeyi yükseltir; asynchronous ise düşük gecikme ama eventual consistency getirir.

3.3 Konsensüs ve lider seçimi

Dağıtık sistemlerin kararlı bir şekilde çalışması için düğümler arası ortak karar şarttır: kim lider olacak, hangi verinin commit kabul edildiği gibi. Raft ve Paxos en bilinen konsensüs algoritmalarıdır. Raft daha anlaşılır bir protokol sunar; genelde lider election, log replication ve güvenilirlik garantileri için tercih edilir.

3.4 Zamanlama ve sıra (ordering)

Dağıtık sistemlerde global bir gerçek zamanlı sıra olmaması bir zorluktur. Lamport saatleri ve vector clock'lar olayların kısmi sıralamalarını sağlar; bu, çakışan güncellemelere veya merge senaryolarına karar vermede kullanılır.

3.5 Hata modelleri ve tolerans

Donanım arızaları, network bölünmeleri (partition), gecikmeler ve yazılım hataları sık karşılaşılan durumlar. Fault tolerance için replikasyon, retry, circuit breaker, bulkhead ve fallback desenleri kullanılır. Byzantine faults (kötü niyetli düğümler) özel çözümler (PBFT gibi) gerektirir; çoğu uygulama için crash‑fail modeli yeterlidir.

4. GERÇEK DÜNYA KULLANIMLARI

Netflix — Ölçekleme ve resiliency

Netflix, dünya çapında milyarlarca istekle çalışırken, dağıtık sistem tasarımını resiliency ve ölçeklenebilirlik etrafında kurmuştur. Service mesh, circuit breakers (Hystrix örnekleri geçmişte) ve veri çoğaltma stratejileriyle başarısızlıkları izole ederler.

Uber — Gerçek zamanlı veri ve routing

Uber konum, talep ve fiyatlandırma hesaplamalarını düşük gecikme ile dağıtık sistemler üzerinde çalıştırır. Event‑driven altyapı ve stream processing platformları dispatch kararlarında kritik rol oynar.

Amazon — Ownership ve veri tutarlılığı

Amazon, servis sahibi ekip modelini (two‑pizza team) ve güçlü otomasyon ile dağıtık veri platformlarını yönetir. Veri tutarlılığı gerektiren işlemlerde dikkatli transaction stratejileri ve retry mekanizmaları uygulanır.

OpenAI / ML platformları

Model eğitim ve dağıtım pipeline'ları genellikle dağıtık veri işlem hattı ve dağıtık depolama üzerinde çalışır. Büyük modellerin dağıtık eğitimindeki koordinasyon, parametre server veya all‑reduce gibi iletişim desenleri içerir.

Stripe / Fintech

Finansal uygulamalarda tutarlılık, idempotency ve auditability gereklidir. Stripe benzeri şirketler, ödeme süreçlerinde saga, compensating transaction ve sıkı test stratejileri uygular.

5. AVANTAJLAR VE SINIRLAMALAR

Avantajlar

• Yüksek erişilebilirlik: Düğümler arası çoğaltma hizmet kesintilerini azaltır.
• Yatay ölçeklenebilirlik: Trafik arttıkça yeni düğümler eklenerek kapasite artırılabilir.
• Coğrafi dağıtım: Latency optimizasyonu ve lokasyon bazlı hizmet sunma imkanı.

Sınırlamalar

• Karmaşıklık: Koordinasyon, gözlemlenebilirlik ve test mekanizmaları gerektirir.
• Tutarlılık/Performans trade‑off'ları: CAP teoremi uyarınca sistem hedefleri belirlenmelidir.
• Operasyon maliyeti: Cluster yönetimi, network maliyetleri ve veri çoğaltma masrafları.

6. ALTERNATİFLER VE KARŞILAŞTIRMA

7. EN İYİ PRATİKLER

Production kullanımı

• Hedeflerinizi net belirleyin: tutarlılık mi, yoksa erişilebilirlik mi öncelikli?
• Fail‑fast ve circuit breaker desenleri uygulayın; bağımlılıklarda graceful degradation planlayın.
• Idempotency token'ları ve deduplication mekanizmalarını tasarıma dahil edin.

Performans optimizasyonu

• Network topology'yi göz önünde bulundurun: latency‑sensitive path'leri co‑locate edin.
• Sharding ve partition stratejilerini iş yüküne göre belirleyin; hot‑key analizleri yapın.
• Cache stratejilerini edge ve servis seviyesinde akıllıca kullanın; cache invalidation politikalarını belirginleştirin.

Güvenlik

• İletişimi TLS ile şifreleyin; mutual TLS (mTLS) iç servislerde kimlik doğrulama sağlar.
• Least privilege ilkesiyle erişim kontrollerini uygulayın; secret management kullanın.

Ölçeklenebilirlik ve operasyon

• Observability: dağıtık tracing, metrikler ve yapılandırılmış loglar zorunludur.
• Chaos engineering ile hata senaryolarını düzenli test edin.
• Capacity planning ve otomatik scaling (HPA, autoscaling groups) süreçlerini kurun.

8. SIK YAPILAN HATALAR

• CAP teoremine duyarsız kalmak — yanlış tutarlılık/erişilebilirlik beklentileri kurmak.
• Zaman ve ordering sorunlarını ihmal etmek — timestamp ve clock yönetimi önemlidir.
• Idempotency veya retry stratejisi olmadan at‑least‑once sistemleri kullanmak.
• Gözlemlenebilirlik ve test kapsamını küçümsemek — üretimdeki hataları anlamak zorlaşır.

9. GELECEK TRENDLER

1. Edge ve Fog computing: Veri ve hesaplamanın kullanıcılara daha yakın yürütülmesi ile latency azalacak ve dağıtık karar mekanizmaları artacak.
2. AI‑driven ops: Kapasite planlama, anomaly detection ve otomatik rebalancing AI destekli araçlarla daha öngörülebilir hale gelecek.
3. Data mesh ve domain‑oriented platformlar: Veri ürünlerinin domain takımları tarafından sahibi olunması, dağıtık veri yönetimini kolaylaştıracak.
4. Serverless distributed patterns: FaaS tabanlı dağıtık desenler, operasyonel soyutlama sağlayarak hız kazandıracak.

EK BÖLÜMLER

Sık Sorulan Sorular (FAQ)

1. 1. Dağıtık sistemde tutarlılık ve erişilebilirlik arasında nasıl seçim yapmalıyım?

   İş gereksinimlerinizi analiz edin: finansal işlemler gibi güçlü tutarlılık gerekiyorsa consistency öncelikli tasarım; kullanıcı içeriklerinde read availability daha önemliyse availability‑first tasarım tercih edilebilir.

2. 2. Raft mı Paxos mu seçmeliyim?

   Raft, uygulanması ve anlaşılması daha kolay olduğundan birçok modern projede tercih edilir. Paxos daha akademik ve düşük seviyeli garantiler sunar; çoğu uygulama için Raft yeterlidir.

3. 3. Distributed transaction (2PC) kullanmalı mıyım?

   2PC karmaşıklık ve blokaj riskleri getirir. Mümkünse saga pattern veya eventual consistency yaklaşımları tercih edilmelidir. Kritik atomicity gerekiyorsa 2PC kullanılabilir ama operasyonel maliyeti yüksek olacaktır.

4. 4. Clock sorunlarını nasıl yönetirim?

   NTP ile fiziksel saatleri senkronize edin; uygulama mantığında Lamport veya vector clock gibi logical clock mekanizmalarını kullanın.

5. 5. Rebalancing neden problem oluşturur?

   Partition veya lider değişimleri kısa süreli kesintiye yol açabilir; stateful tüketiciler için state transfer maliyeti vardır. Incremental rebalancing ve state checkpointing bu etkiyi azaltır.

6. 6. Hangi gözlemlenebilirlik araçları kullanılmalı?

   Distributed tracing (Jaeger/Zipkin), metrik toplayıcılar (Prometheus), merkezi log (ELK/Opensearch) kombinasyonu önerilir.

7. 7. Veri çoğaltma için en iyi strateji nedir?

   İş gereksinimine göre synchronous veya asynchronous seçin. Yüksek tutarlılık gerekiyorsa synchronous; performans ve ölçek gerekliyse asynchronous tercih edilebilir.

8. 8. Byzantine faults ile nasıl başa çıkarım?

   Byzantine tolerance gerektiren sistemler için PBFT gibi özel algoritmalar ve ekstra maliyet gereklidir; sadece gerekli kritik durumlarda uygulanmalıdır.

Anahtar Kavramlar

CAP Teoremi

Consistency, Availability ve Partition Tolerance arasında trade‑off olduğunu belirtir.

Quorum

Bir işlemin kabulü için gerekli minimum replica onayı.

Raft

Dağıtık konsensüs için lider tabanlı, anlaşılması görece kolay bir protokol.

Idempotency

Aynı isteğin birden fazla işlendiğinde aynı sonucu üretme garantisi.

Sharding

Verinin yatay olarak bölünmesi; paralel işlem ve ölçek sağlar.

Öğrenme Yol Haritası

1. 0–1 ay: Dağıtık sistem temel kavramları: ağ, latency, replication, sharding, CAP teoremi. Basit dağıtık uygulama yapın.
2. 1–3 ay: Konsensüs algoritmaları (Raft, Paxos) ve practical uygulamalarını öğrenin; mini cluster kurarak lider election ve replikasyonı deneyin.
3. 3–6 ay: Event driven ve stream processing (Kafka gibi), saga pattern, distributed transactions ve idempotency stratejileri üzerinde çalışın.
4. 6–12 ay: Production ops: clustering, monitoring, chaos engineering, capacity planning ve DR prova yöntemlerini uygulayın.