Veritabanı Mimarisinde Ölçeklenebilirlik: Sharding ve Replication

Bir veritabanı ilk günlerde tek sunucuda oldukça rahat çalışabilir, ancak trafik, veri hacmi ve ekip sayısı büyüdükçe aynı tasarım farklı sınırlarla karşılaşır. CPU doygunluğu, artan sorgu gecikmesi, connection pool beklemeleri ve depolama sınırları genellikle bu değişimin ilk işaretleridir. Veritabanı Mimarisinde Ölçeklenebilirlik: Sharding ve Replication konusu tam olarak bu noktada yalnızca daha güçlü sunucu seçmeyi değil, veriyi nasıl dağıttığımızı, nerede kopyaladığımızı ve hata anında hangi garantileri koruduğumuzu ele alır. On yılı aşkın backend ve veri altyapısı çalışmalarında gördüğüm en önemli nokta, sharding kararının çoğu zaman teknik olarak mümkün olduğu andan çok daha sonra gerekli hale gelmesidir. Bu rehberde veritabanında sharding ve replication nasıl uygulanır, ölçeklenebilir veritabanı mimarisi nasıl tasarlanır ve yüksek trafikli sistemlerde horizontal sharding read replica ve failover stratejileri nasıl birlikte düşünülmelidir sorularını adım adım ele alacağım.

Veritabanı Ölçeklenebilirliği Nedir?

Veritabanı ölçeklenebilirliği sistem büyüdükçe daha fazla sorgu, daha fazla veri ve daha fazla bağlantıyı kabul edilebilir performansla yönetebilme yeteneğidir. Ölçeklenebilirlik yalnızca saniyedeki sorgu sayısını artırmak anlamına gelmez. Depolama kapasitesi, bağlantı sayısı, write throughput ve hata anındaki davranış da aynı tasarımın parçalarıdır. İyi bir ölçekleme planı bugünkü yükü taşırken gelecekteki büyüme için de güvenli kapasite bırakır. Bu nedenle mimari kararlar tek bir benchmark rakamından çok access pattern ve business gereksinimleri üzerinden verilmelidir.

Database Scalability Ne Anlama Gelir?

Database scalability, veri sistemi üzerindeki yük arttığında kapasitenin kontrollü biçimde büyütülebilmesini ifade eder. Bu büyüme daha güçlü donanım, daha fazla replica veya verinin birden fazla shard'a dağıtılmasıyla sağlanabilir. Her yöntemin maliyeti ve operasyon modeli farklıdır. Bazı sistemlerde read trafiği asıl sınır olurken bazı sistemlerde write veya storage limiti daha erken ortaya çıkar. Bu yüzden ölçeklenebilirlik tek bir teknik değil, darboğazı doğru yerde çözme yaklaşımıdır.

Read Throughput

Read throughput sistemin belirli sürede kaç okuma sorgusunu kabul edilebilir gecikmeyle tamamlayabildiğini gösterir. Read ağırlıklı uygulamalarda replica eklemek ve cache kullanmak önemli kapasite artışı sağlayabilir. Bununla birlikte replica lag nedeniyle her sorgunun replica'ya yönlendirilmesi doğru değildir. Permission, bakiye veya yeni kaydedilmiş profil gibi tutarlılık duyarlı veriler farklı routing gerektirebilir. Read kapasitesi artırılırken veri tazeliği beklentisi mutlaka birlikte değerlendirilmelidir.

Write Throughput

Write throughput insert, update ve delete gibi değişikliklerin saniyede ne kadar işlenebildiğini ifade eder. Single-leader mimaride tüm yazımlar primary node üzerinden geçtiği için bir noktada primary kapasitesi sınıra ulaşabilir. Replica eklemek bu write ceiling'i doğrudan artırmaz. Gerçek write scaling gerektiğinde veri farklı shard'lara dağıtılabilir veya farklı write leadership modelleri kullanılabilir. Ancak bu noktaya gelmeden önce sorgu, indeks ve transaction maliyetleri optimize edilmelidir.

Veri Kapasitesi

Veri kapasitesi tek node'un güvenli biçimde tutabileceği toplam dataset miktarıyla ilişkilidir. Disk kapasitesi tek başına yeterli gösterge değildir çünkü indeksler, WAL veya binlog, temporary space ve backup gereksinimleri ek alan tüketir. Büyük dataset sorgu planı ve maintenance sürelerini de uzatabilir. Tek node artık hem veri hem operasyon açısından sürdürülebilir değilse partitioning veya sharding değerlendirilebilir. Kapasite planı yalnızca bugün kullanılan alana değil büyüme hızına göre yapılmalıdır.

Connection Kapasitesi

Her veritabanı bağlantısı sunucu üzerinde memory ve işlem kaynağı tüketir. Uygulama replica sayısı arttıkça toplam connection sayısı beklenenden hızlı büyüyebilir. Connection pooling bu nedenle ölçekleme merdiveninin erken adımlarından biridir. Sharded sistemde her uygulama instance'ı her shard için ayrı pool açarsa connection explosion daha da ciddi hale gelir. Proxy tabanlı pooling ve shard-aware routing bu problemi azaltabilir.

Availability ve Scalability Arasındaki Fark

Availability sistemin arıza anında erişilebilir kalmasıyla, scalability ise artan yükü taşıyabilmesiyle ilgilidir. Replication çoğu zaman availability ve read scaling sağlar, ancak tek primary write sınırını ortadan kaldırmaz. Sharding write ve storage kapasitesini artırabilir fakat tek başına high availability sağlamaz. Production sistemlerinde her shard'ın kendi replication topolojisine sahip olması bu nedenle yaygındır. İki kavram birbirini desteklese de aynı problem olarak görülmemelidir.

Veritabanının Ölçekleme İhtiyacı Olduğu Nasıl Anlaşılır?

Veritabanını ölçekleme kararı yalnızca kullanıcı sayısının artmasına bakılarak verilmemelidir. CPU, memory, disk I/O, connection bekleme süreleri ve query latency birlikte izlenmelidir. Darboğazın yanlış teşhis edilmesi gereksiz sharding gibi pahalı bir mimari karara götürebilir. Ben üretim sistemlerinde önce trendleri, ardından peak saat davranışını ve son olarak failure headroom'u incelerim. Böylece sorun kapasite mi, sorgu tasarımı mı yoksa uygulama kaynaklı mı daha net görülür.

CPU Saturation

Database CPU'su uzun süre yüksek seviyede kalıyorsa sorgu çalıştırma kapasitesi sınırına yaklaşılmış olabilir. Önce en pahalı query'ler ve execution plan'ları incelenmelidir. Yanlış indeks veya gereksiz full scan CPU kullanımını artırabilir. Sorun optimize edildikten sonra hâlâ devam ediyorsa vertical scale veya workload dağıtımı düşünülebilir. CPU grafiğine tek başına bakıp shard sayısını artırmak doğru yaklaşım değildir.

Memory Pressure

Database memory index cache, buffer cache, connection state ve query execution için kullanılır. Working set memory'ye sığmadığında disk erişimi artabilir ve sorgu gecikmeleri büyüyebilir. Çok fazla connection da memory pressure oluşturabilir. Memory kullanımının neden yükseldiği görülmeden yalnızca instance boyutunu büyütmek sorunu erteler. Cache hit ratio ve query behavior birlikte incelenmelidir.

Disk I/O Saturation

Disk I/O saturation özellikle scan, checkpoint, compaction veya yoğun write workload altında belirgin hale gelir. IOPS ve throughput sınırına ulaşıldığında CPU boş görünse bile query latency yükselebilir. Yanlış indeks tasarımı veya büyük temporary sort işlemleri I/O baskısını artırabilir. Daha hızlı storage geçici çözüm sağlayabilir. Dataset ve workload büyümeye devam ediyorsa dağıtım stratejisi gerekebilir.

Connection Pool Exhaustion

Uygulama pool'undaki tüm bağlantılar meşgulse yeni request'ler veritabanına ulaşmadan beklemeye başlar. Bu durum bazen database'in değil uygulama concurrency'sinin problemidir. Uzun transaction ve yavaş query bağlantıları gereksiz süre tutabilir. Pool boyutunu sınırsız artırmak database'i daha fazla yük altında bırakabilir. Önce query süresi, transaction kapsamı ve application concurrency birlikte incelenmelidir.

Query Latency Artışı

Query latency artışı kapasite sorununun en görünür belirtilerinden biridir. Ortalama değer yerine p95 ve p99 seviyeleri daha anlamlı olabilir. Sadece belirli query pattern'leri yavaşlıyorsa genel scaling yerine hedefli optimizasyon gerekir. Tüm sorgular load arttıkça yavaşlıyorsa kaynak saturation daha olasıdır. Latency trendi deployment ve veri büyümesiyle ilişkilendirilmelidir.

Storage Limitleri

Tek node depolama kapasitesine yaklaşıyorsa yalnızca data dosyaları değil operasyonel headroom da düşünülmelidir. Index build, vacuum, compaction veya temporary query alanı ek disk gerektirebilir. Backup ve restore süreleri dataset büyüdükçe uzar. Storage limiti sürekli yaklaşan sistemlerde partition veya shard stratejisi erkenden planlanmalıdır. Son yüzde beş kapasiteye kalana kadar beklemek migration riskini artırır.

Write QPS Limiti

Write QPS single-primary mimarilerde önemli ölçek sınırıdır. Primary CPU, lock, disk flush veya transaction log throughput'u tıkanabilir. Read replica eklemek bu sorunu çözmez. Write işlemleri gerçekten optimize edilmiş ve tek node sınırına ulaşılmışsa horizontal sharding gündeme gelir. Burada shard key seçimi gelecekteki kapasitenin temel belirleyicisidir.

Database Scaling Ladder Nasıl Olmalıdır?

Sağlıklı database scaling genellikle kolay ve düşük riskli adımlardan daha dağıtık çözümlere doğru ilerlemelidir. Sorgu ve indeks problemi çözülmeden sharding yapmak aynı verimsiz sorguyu daha fazla node'a dağıtmaktan başka bir şey olmayabilir. Connection pooling ve cache çoğu sistemde önemli kapasite kazancı sağlar. Read replica ve partitioning belirli workload'larda sharding ihtiyacını yıllarca erteleyebilir. Sharding ancak write veya dataset sınırı gerçekten kanıtlandığında masaya gelmelidir.

1. Query Optimizasyonu

İlk adım en pahalı ve en sık çalışan sorguları belirlemektir. Execution plan, scan miktarı ve filtreleme davranışı incelenmelidir. Gereksiz kolon, gereksiz join veya uygulamada yapılabilecek tekrar sorgular azaltılabilir. Query optimizasyonu bazen yeni donanımdan çok daha büyük kazanım sağlar. Üstelik dağıtık mimariye geçildiğinde de bu kazanım korunur.

2. Index Optimizasyonu

Doğru indeks sorguların büyük tablo üzerinde gereksiz tarama yapmasını önler. Ancak her indeks write maliyetini ve storage kullanımını artırır. Bu nedenle yalnızca okuma hızına bakarak indeks eklemek doğru değildir. Composite index sırası gerçek access pattern'e göre seçilmelidir. Kullanılmayan indeksler periyodik olarak tespit edilmelidir.

3. Connection Pooling

Connection pooling uygulamanın her request için yeni database connection açmasını önler. Bağlantılar tekrar kullanıldığı için handshake ve memory maliyeti azalır. Pool boyutu database kapasitesiyle uyumlu olmalıdır. Çok sayıda app replica olduğunda toplam connection hesabı yapılmalıdır. Proxy-based pooling büyük fleet ortamında ek avantaj sağlayabilir.

4. Caching

Sık okunan ve nadiren değişen verileri cache üzerinden sunmak database read yükünü azaltabilir. Cache her sorguya eklenmemelidir. Invalidation, stale data ve permission gibi riskler değerlendirilmelidir. Cache miss davranışı database'i anlık aşırı yüke sürüklememelidir. Cache veri modelinin yerine geçen source of truth olarak kullanılmamalıdır.

5. Vertical Scaling

Vertical scaling daha fazla CPU, memory veya daha hızlı storage eklemektir. Operasyonel olarak çoğu zaman horizontal dağıtımdan daha basittir. Özellikle orta ölçekli sistemlerde yıllarca yeterli olabilir. Ancak fiziksel ve ekonomik bir üst sınırı vardır. Bu limite yaklaşmadan önce gelecekteki migration planı hazırlanmalıdır.

6. Read Replicas

Read replica okuma trafiğini primary üzerinden alarak read throughput'u artırabilir. Reporting ve analytics sorguları ayrı replica'ya yönlendirilebilir. Replication lag nedeniyle her read replica için aynı consistency beklentisi kullanılamaz. Read-after-write ihtiyacı olan sorgular primary'de kalabilir. Replica sayısı arttıkça failover ve lag monitoring daha önemli hale gelir.

7. Table Partitioning

Table partitioning büyük tabloyu aynı database sistemi içinde mantıksal parçalara ayırır. Tarih veya belirli anahtar üzerinden partition oluşturulabilir. Partition pruning sorgunun yalnızca ilgili parçaları taramasını sağlar. Maintenance işlemleri partition bazında daha kolay hale gelebilir. Ancak tüm write trafiği hâlâ aynı database instance kapasitesi içinde kalabilir.

8. Sharding

Sharding dataset'i birden fazla bağımsız database node veya grup arasında yatay olarak dağıtır. Her shard verinin yalnızca bir bölümünü taşır. Write ve storage kapasitesi böylece birden fazla primary arasında bölünebilir. Bunun bedeli query routing, cross-shard işlem ve operasyon yükünün büyümesidir. Bu nedenle sharding güçlü ama pahalı bir ölçekleme aracıdır.

Sharding Neden Son Adımlardan Biri Olmalıdır?

Sharding uygulama, operasyon, backup, schema migration ve transaction modelini önemli ölçüde değiştirir. Yanlış shard key uzun vadede hot shard ve cross-shard query sorunları yaratabilir. Resharding kendi başına ciddi migration sürecidir. Daha basit yöntemlerle kapasite artırılabiliyorsa bunlar genellikle önce uygulanmalıdır. Sharding geri dönüşü zor olan mimari karar olduğu için gerçek ihtiyaca dayanmalıdır.

Vertical Scaling ile Horizontal Scaling Arasındaki Fark

Vertical scaling tek makinenin kaynaklarını büyütürken horizontal scaling yükü birden fazla node'a dağıtır. Scale up operasyonel olarak daha basit olabilir fakat bir donanım tavanına sahiptir. Scale out teorik olarak daha geniş kapasite sunar ancak routing, consistency ve failure yönetimini zorlaştırır. Veritabanı Mimarisinde Ölçeklenebilirlik: Sharding ve Replication planında iki yaklaşım rakip değil, farklı büyüme aşamalarının araçlarıdır. Doğru zamanlama toplam sistem maliyetini ciddi biçimde etkiler.

Scale Up

Scale up daha güçlü CPU, daha fazla RAM veya daha hızlı disk kullanmak anlamına gelir. Uygulama kodunda büyük değişiklik gerektirmeden kapasite artırabilir. Managed database platformlarında instance boyutunu yükseltmek oldukça kolay olabilir. Ancak büyük instance'ların maliyeti doğrusal artmayabilir. Ayrıca bakım veya arıza anında tek node'un etkisi büyür.

Scale Out

Scale out birden fazla node ekleyerek yükü dağıtır. Read replica read trafiğini, sharding ise dataset ve write trafiğini yatay dağıtabilir. Sistem birden fazla hata alanına bölünebilir. Buna karşılık topology discovery ve routing daha önemli hale gelir. Application ve operations ekiplerinin distributed systems davranışını iyi anlaması gerekir.

Hardware Ceiling

Her database engine ve cloud platformunda tek instance için pratik kaynak sınırı vardır. En büyük instance bile belirli write veya I/O yükünden sonra yetersiz kalabilir. Ayrıca en üst sınıfa gelmeden ekonomik tavan oluşabilir. Daha büyük makine başına maliyet hızla yükseliyorsa horizontal plan daha mantıklı olabilir. Ceiling yalnızca vendor katalog değerinden değil gerçek benchmark sonuçlarından belirlenmelidir.

Operasyonel Karmaşıklık

Tek node yapısında backup, migration ve monitoring daha doğrudan yönetilebilir. Horizontal yapıda shard map, replica topology, rebalancing ve failover gibi ek bileşenler devreye girer. Hata senaryoları da daha fazla kombinasyon üretir. Bu ek operasyon yükü ekip kapasitesine dahil edilmelidir. Teknik olarak ölçeklenen ama işletilemeyen sistem başarılı sayılmaz.

Maliyet

Daha büyük tek instance ile çok sayıda küçük node arasında maliyet karşılaştırması yalnızca compute üzerinden yapılmamalıdır. Replica, backup, network, monitoring ve mühendislik zamanı toplam maliyetin parçasıdır. Sharding çoğu zaman daha fazla node ve daha fazla operasyon aracı gerektirir. Managed dağıtık database bu işlerin bir bölümünü azaltabilir fakat farklı maliyetler ekleyebilir. Toplam sahip olma maliyeti gerçek trafik projeksiyonu üzerinden hesaplanmalıdır.

Hangi Noktada Horizontal Scaling Gerekir?

Tek node query ve indeks optimizasyonundan sonra hâlâ write, storage veya availability hedeflerini karşılayamıyorsa horizontal seçenekler değerlendirilir. Read problemi için replica çoğu zaman yeterlidir. Write veya dataset tek node'a sığmıyorsa sharding daha anlamlı hale gelir. Region ve data residency ihtiyaçları da yatay dağıtımı gerektirebilir. Karar performans metriği ve business requirement ile belgelenmelidir.

Partitioning Nedir?

Partitioning büyük tabloyu belirli kurala göre daha küçük mantıksal parçalara ayırır. Bu parçalar aynı database instance veya cluster içinde yönetilebilir. Amaç sorgu pruning, maintenance ve data lifecycle yönetimini kolaylaştırmaktır. Partitioning tek başına sharding değildir çünkü veriler ayrı bağımsız database primary'lerine dağılmayabilir. Yine de doğru kullanıldığında sharding ihtiyacını önemli ölçüde geciktirebilir.

Table Partitioning

Table partitioning tek logical table'ın birden fazla fiziksel partition olarak saklanmasını sağlar. Uygulama çoğu zaman tabloyu tek isim üzerinden sorgulamaya devam eder. Database optimizer ilgili partition'ları seçebilir. Büyük archive ve time-series tablolarında maintenance kolaylaşır. Partition anahtarının sorgularda kullanılmaması avantajı azaltır.

Range Partitioning

Range partitioning değer aralıklarına göre parçalama yapar. Tarih bazlı aylık veya yıllık partition bunun yaygın örneğidir. Zaman aralığı sorguları belirli partition'lara yönlendirilebilir. En yeni partition'a aşırı write gelmesi hot range oluşturabilir. Gelecekteki partition'ların otomatik oluşturulması operasyon planına dahil edilmelidir.

Hash Partitioning

Hash partitioning anahtarın hash sonucuna göre veriyi partition'lara dağıtır. Bu yaklaşım genellikle daha dengeli veri dağılımı sağlar. Belirli range sorguları için locality avantajı düşüktür. Partition sayısı ve hash algoritması gelecekteki değişikliklere göre düşünülmelidir. Hot key tek bir hash bucket üzerinde yine yoğunluk oluşturabilir.

List Partitioning

List partitioning belirli değer kümelerini farklı partition'lara yönlendirir. Bölge, tenant grubu veya ürün kategorisi gibi alanlarda kullanılabilir. Cardinality düşükse partition sayısı kontrol altında kalır. Dengesiz trafik bazı partition'ların çok daha yoğun olmasına yol açabilir. Liste değişikliklerinin operasyon süreci baştan belirlenmelidir.

Partition Pruning

Partition pruning optimizer'ın sorguyla ilgisiz partition'ları taramamasını sağlar. Bu davranış büyük tabloda I/O miktarını ciddi biçimde azaltabilir. Sorgu partition key üzerinden filtre içermiyorsa pruning gerçekleşmeyebilir. Function wrapping veya type dönüşümü bazen optimizer davranışını etkileyebilir. Execution plan ile pruning'in gerçekten çalıştığı doğrulanmalıdır.

Partitioning Ne Zaman Yeterlidir?

Dataset büyük olsa da tek instance write kapasitesi yeterliyse partitioning uzun süre yeterli olabilir. Özellikle zaman bazlı arşivleme ve maintenance ihtiyaçlarında güçlü sonuç verir. Read sorguları doğru partition'lara düşüyorsa performans belirgin şekilde iyileşebilir. Storage fiziksel olarak tek node sınırına yaklaşmıyorsa sharding gerekmeyebilir. Dağıtık mimari yalnızca tablo büyük olduğu için seçilmemelidir.

Partitioning ile Sharding Arasındaki Fark

Partitioning ve sharding veriyi parçalara böldüğü için birbirine benzer görünür. Temel fark çoğu kullanımda partition'ın aynı database sistemi içindeki veri organizasyonu, shard'ın ise farklı database node'larına dağıtım olmasıdır. Sharding query routing ve cross-node işlem gereksinimi oluşturabilir. Partitioning database optimizer tarafından daha şeffaf yönetilebilir. Bu fark operasyon maliyeti ve consistency modelini önemli ölçüde değiştirir.

Aynı Database Instance İçindeki Partition

Partition'lar çoğu zaman aynı database engine ve instance kaynaklarını paylaşır. CPU, memory ve disk throughput ortak kapasite sınırı altında kalabilir. Database transaction modeli partition'lar arasında doğal biçimde çalışmaya devam eder. Query planner tüm partition bilgisine sahiptir. Bu nedenle uygulama tarafındaki değişiklik sharding'e göre daha az olabilir.

Farklı Database Node'larındaki Shard

Shard'lar verinin farklı database node'larında tutulduğu fiziksel dağıtımı ifade eder. Her shard kendi primary ve replica grubuna sahip olabilir. Bir query'nin hangi shard'a gideceğini router belirler. Multi-shard query network üzerinden fan-out yapabilir. Transaction ve unique constraint modelleri bu nedenle daha zor hale gelir.

Logical vs Physical Distribution

Partitioning daha çok logical ve storage-level veri organizasyonu olarak düşünülebilir. Sharding ise kapasiteyi farklı failure domain ve compute kaynaklarına fiziksel olarak yayar. Bu ayrım write scaling açısından önemlidir. Tek instance partitioning write CPU sınırını ortadan kaldırmaz. Sharding doğru dağılımla birden fazla primary üzerinde write kapasitesi sağlar.

Query Routing

Partitioned tabloda optimizer query'yi ilgili partition'a kendi yönlendirebilir. Sharded sistemde uygulama, proxy veya database router hangi shard'ın sorumlu olduğunu bulmalıdır. Shard key query'de bulunmuyorsa scatter-gather gerekebilir. Routing metadata yüksek erişilebilir olmalıdır. Yanlış route veri bulunamaması veya ek latency yaratabilir.

Operasyonel Karmaşıklık

Partitioning maintenance sürecini büyütse de tek database yönetimi içinde kalabilir. Sharding backup, restore, schema migration ve monitoring'i shard sayısı kadar çoğaltabilir. Shard map ve resharding ek süreçler getirir. Ekip otomasyon olmadan çok sayıda shard'ı güvenle yönetmekte zorlanabilir. Bu yüzden partitioning yeterliyse daha düşük riskli seçenektir.

Database Replication Nedir?

Database replication aynı verinin birden fazla node üzerinde kopyalanmasını sağlar. Bir node primary olarak yazımları kabul ederken diğerleri replica olarak log akışını uygular. Replication read scaling, high availability ve disaster recovery için kullanılabilir. Ancak tüm dataset'in kopyalanması write kapasitesini otomatik artırmaz. Replication modelini seçerken consistency, latency ve kabul edilebilir veri kaybı birlikte düşünülmelidir.

Verinin Birden Fazla Node'da Kopyalanması

Replication temel olarak aynı logical verinin birden fazla kopyasını oluşturur. Bu kopyalar aynı region veya farklı region'larda tutulabilir. Node'lardan biri kaybedildiğinde başka kopya servis vermeye devam edebilir. Kopyaların ne kadar güncel olduğu replication moduna bağlıdır. Async replication hızlıdır fakat kısa data-loss window oluşturabilir.

Primary

Primary single-leader modelde write işlemlerinin kabul edildiği ana node'dur. Transaction log burada üretilir. Replica'lar bu değişiklikleri takip eder. Primary failure olduğunda uygun replica promotion ile yeni primary olabilir. Uygulamanın yeni primary'yi güvenli biçimde bulması gerekir.

Replica

Replica primary'deki değişiklikleri replication stream üzerinden uygular. Read-only sorgular bazı sistemlerde replica'ya yönlendirilebilir. Replica lag nedeniyle veri primary'den geride olabilir. Reporting gibi stale veri toleranslı işler için uygun olabilir. Failover adayı olarak kullanılıyorsa sağlık ve lag durumu yakından izlenmelidir.

Replication Stream

Replication stream primary üzerindeki değişikliklerin replica'lara aktarılmasını sağlar. Bu akış transaction log veya engine'e özgü değişiklik kaynağından beslenebilir. Network gecikmesi ve replica apply kapasitesi lag oluşturabilir. Büyük transaction replication akışını uzun süre meşgul edebilir. Stream sağlığı production monitoring'in temel parçasıdır.

WAL / Binlog / Oplog

Farklı database engine'leri değişiklik akışını farklı log mekanizmalarıyla temsil eder. PostgreSQL WAL, MySQL binlog ve MongoDB oplog buna bilinen örneklerdir. Replication bu kayıtları kullanarak değişiklikleri diğer node'lara taşır. Log retention replica'nın ne kadar süre geriden gelebileceğini etkiler. Bu alanın dolması veya silinmesi recovery sürecini zorlaştırabilir.

Read Scaling ve High Availability

Replica eklemek read sorgularını birden fazla node'a dağıtabilir. Aynı zamanda primary arızasında promotion için yedek node sağlar. Bu iki hedef aynı topolojide bulunsa da routing ve consistency ihtiyaçları farklıdır. Analytics replica yüksek yük altında failover adayı olarak zayıf kalabilir. Rol bazlı replica planı bu nedenle daha güvenlidir.

Primary-Replica Replication Nasıl Çalışır?

Primary-replica modelinde write işlemi primary üzerinde commit edilir ve değişiklik transaction log'a yazılır. Replica bu log akışını alır ve kendi verisine uygular. Uygulama uygun sorguları replica'dan okuyabilir. Primary arızalanırsa sağlıklı replica promotion ile yeni primary haline gelir. Bu süreçte consistency, failover süresi ve client reconnect davranışı baştan tasarlanmalıdır.

Write → Primary

Single-leader topolojide tüm write istekleri primary'ye gider. Bu yapı conflict modelini basitleştirir. Ancak primary doğal write bottleneck haline gelir. Uygulama yanlışlıkla replica'ya write göndermemelidir. Routing endpoint veya proxy üzerinden merkezi yönetilebilir.

Transaction Log

Committed değişiklikler database transaction log içinde kayıt altına alınır. Replication sistemleri bu log'u değişiklik kaynağı olarak kullanabilir. Büyük write hacmi log üretim hızını artırır. Replica apply rate log üretim hızından düşükse lag büyür. Log storage kapasitesi ayrıca izlenmelidir.

Replica'ya Aktarım

Primary log kayıtlarını replica'lara network üzerinden gönderir. Cross-region replication network latency nedeniyle daha fazla gecikme yaşayabilir. Sync modelde acknowledgement write latency'yi doğrudan etkiler. Async model primary replica beklemeden commit edebilir. Transport kesintisi replica'nın catch-up ihtiyacını büyütür.

Replica Apply

Replica aldığı değişiklikleri kendi storage engine'ine uygular. Apply kapasitesi CPU, disk ve transaction yapısından etkilenir. Büyük batch veya uzun transaction kısa sürede ciddi lag oluşturabilir. Replica yalnızca network nedeniyle geride kalmaz. Apply performansı ayrı metriklerle izlenmelidir.

Read → Replica

Stale veri toleranslı read sorguları replica'ya yönlendirilebilir. Reporting, analytics veya bazı liste sayfaları buna örnektir. Yeni write sonrası hemen okuma gereken akışlar primary'de kalmalıdır. Lag-aware router replica seçimini gerçek güncellik durumuna göre yapabilir. Tüm read trafiğini kör biçimde replica'ya göndermek kullanıcı hatalarına yol açabilir.

Primary Failure → Promotion

Primary erişilemez olduğunda cluster sağlıklı replica'yı yeni primary olarak promote edebilir. Promotion öncesi failure gerçekten doğrulanmalıdır. Network partition sırasında yanlış karar split-brain riski yaratır. Uygulama yeni primary endpoint'ine reconnect etmelidir. Eski primary geri döndüğünde fencing olmadan write kabul etmemelidir.

Replication Hangi Problemleri Çözer?

Replication en güçlü olarak read scaling, high availability ve disaster recovery alanlarında kullanılır. Read-heavy uygulamalarda sorgu yükünü replica'lara dağıtabilir. Reporting ve analytics workload'u primary'den ayrılabilir. Cross-region replica kullanıcıya daha yakın read sunabilir. Bununla birlikte replication tek primary write sınırını çözmediği için doğru problemde kullanılmalıdır.

Read Scaling

Birden fazla replica aynı dataset'in read trafiğini paylaşabilir. Uygulama read-only sorguları replica pool'una yönlendirebilir. Read throughput node sayısıyla belirli ölçüde artabilir. Network ve cache locality sonuçları etkiler. Tutarlılık duyarlı sorgular için primary route korunmalıdır.

High Availability

Primary arızasında replica promotion servis kesintisini azaltabilir. Otomatik failover failure detection ve quorum mekanizması gerektirir. Replica güncelliği yeni primary'nin veri kaybı riskini belirler. Client reconnect süresi toplam RTO'nun parçasıdır. Failover yalnızca kurmakla değil düzenli test etmekle güvenilir hale gelir.

Disaster Recovery

Farklı region veya availability zone'da replica büyük altyapı arızalarına karşı ek koruma sağlar. Ancak replication yanlış delete veya bozuk veriyi de kopyalar. Bu yüzden backup ve PITR ayrıca gereklidir. DR planı promotion, DNS ve application reconnect adımlarını içermelidir. RPO ve RTO business gereksiniminden türetilmelidir.

Reporting

Uzun süren reporting sorguları primary üzerindeki OLTP workload'u etkileyebilir. Ayrı replica bu sorguların yükünü izole eder. Replica hardware'i reporting ihtiyacına göre farklı boyutlandırılabilir. Stale veri toleransı rapor türüne göre belirlenmelidir. Çok ağır sorgular yine analytics warehouse'a taşınabilir.

Analytics Offload

Operational database üzerinde geniş scan yapan analytics sorguları disk ve cache davranışını bozabilir. Replica bu yükü primary'den ayırır. Ancak büyük analytics workload replica lag'i artırabilir. Failover adayı replica ile analytics replica rollerini ayırmak daha güvenlidir. Uzun vadede ayrı warehouse çözümü daha uygun olabilir.

Geographical Read Latency

Kullanıcıya yakın region'da read replica bulundurmak network latency'yi azaltabilir. Bu yaklaşım özellikle global read-heavy uygulamalarda faydalıdır. Write hâlâ merkezi primary'ye gidiyorsa write latency değişmez. Replica lag cross-region mesafe nedeniyle daha yüksek olabilir. Read routing consistency gereksinimiyle birlikte yapılmalıdır.

Replication Hangi Problemleri Çözmez?

Replication bazı kapasite sorunlarını çözerken write ve toplam dataset sınırlarını ortadan kaldırmaz. Tüm write'lar tek primary'den geçiyorsa primary aynı serialization point olarak kalır. Her replica dataset'in tam kopyasını tuttuğu için toplam storage sınırı node başına değişmez. Bu nedenle write ceiling veya tek node storage limiti gerçek problemse sharding gündeme gelir. Database sharding ve replication arasındaki farklar nelerdir sorusunun en önemli cevabı burada ortaya çıkar.

Primary Write Bottleneck

Read replica eklemek write sorgularını başka primary'lere dağıtmaz. Tüm write transaction'ları aynı leader üzerinde işlenmeye devam eder. CPU, lock veya log throughput sınırı değişmez. Write optimizasyonu tükendiyse horizontal sharding değerlendirilebilir. Multi-leader gibi farklı modeller ise conflict yönetimi getirir.

Toplam Dataset Kapasitesi

Replica dataset'in tam kopyasını tuttuğu için tek node'un storage gereksinimi azalmaz. Her node aynı miktarda veriyi barındırmaya devam eder. Dataset tek node sınırına yaklaşıyorsa replica sayısı çözüm değildir. Sharding dataset'i parçalara bölerek node başına veri miktarını azaltabilir. Backup ve restore planı da buna göre değişir.

Tek Write Serialization Point

Single-leader replication write işlemlerini tek noktada sıralar. Bu model consistency açısından anlaşılırdır. Ancak yoğun write workload için kapasite sınırı oluşturur. Sharding her veri bölümüne ayrı primary sağlayarak birden fazla write noktası yaratabilir. İşlem cross-shard olduğunda dağıtık transaction ihtiyacı doğabilir.

Ne Zaman Sharding Gerekmeye Başlar?

Single node write kapasitesi optimize edildiği halde yetmiyorsa sharding güçlü adaydır. Dataset tek node'a güvenli biçimde sığmıyorsa aynı durum geçerlidir. Multi-tenant sistemde birkaç büyük tenant diğerlerini etkiliyorsa shard izolasyonu yararlı olabilir. Data residency veya locality gereksinimi de sharding'i hızlandırabilir. Karar her zaman access pattern analiziyle verilmelidir.

Synchronous Replication Nedir?

Synchronous replication write işleminin belirli replica acknowledgement alınmadan tamamlanmış sayılmamasını sağlar. Bu yaklaşım primary kaybında veri kaybı penceresini küçültür. Bedeli write latency'nin network ve replica performansına daha bağımlı hale gelmesidir. Özellikle cross-region sync replication ciddi gecikme oluşturabilir. Kritik business işlemlerinde durability gereksinimi bu maliyeti gerekçelendirebilir.

Replica Acknowledgement

Primary transaction'ın belirli replica veya replica grubuna ulaştığını doğrulamayı bekleyebilir. Acknowledgement seviyesi database ürününe göre farklı biçimde tanımlanabilir. Daha fazla replica beklemek durability artırırken latency'yi yükseltir. Yavaş replica write yolunu etkileyebilir. Quorum veya minimum ack ayarı bu dengeyi yönetir.

Write Durability

Sync replication committed write'ın birden fazla node üzerinde bulunma olasılığını artırır. Primary kaybı sonrasında yeni leader daha güncel olabilir. Ancak disk flush ve acknowledgement semantiği ayrıntılı incelenmelidir. Her "sync" ayar aynı dayanıklılık garantisini vermez. RPO hedefi ürün dokümantasyonu ve testle doğrulanmalıdır.

Daha Yüksek Write Latency

Write süresi replica network round-trip ve apply davranışından etkilenebilir. Aynı availability zone içindeki sync replica daha düşük gecikme sağlayabilir. Cross-region synchronous path çok daha pahalı olabilir. Kullanıcı latency hedefi durability kararıyla birlikte değerlendirilmelidir. Tüm tablolar için aynı replication politikası zorunlu değildir.

Finansal ve Kritik Veri Senaryoları

Para transferi, sipariş kesinleştirme veya kritik state değişikliklerinde veri kaybı toleransı çok düşük olabilir. Sync replication bu senaryolarda daha güçlü durability sağlayabilir. Yine de transaction mantığı ve idempotency ayrı tasarlanmalıdır. Replica olması application-level double charge sorununu çözmez. Business risk teknik replication ayarına dönüştürülmelidir.

Asynchronous Replication Nedir?

Asynchronous replication primary'nin replica acknowledgement beklemeden write işlemini tamamlamasına izin verir. Bu yaklaşım write latency'yi düşük tutar ve uzak replica'larda daha pratik olabilir. Ancak primary commit sonrası replica'ya ulaşmadan kaybedilirse veri kaybı penceresi oluşabilir. Replica aynı zamanda bir süre stale kalır. Bu nedenle eventual consistency ve RPO beklentisi açık biçimde tanımlanmalıdır.

Primary'nin Hemen Commit Etmesi

Primary local durability koşullarını sağladıktan sonra kullanıcıya başarı dönebilir. Replica'nın aynı anda güncel olması gerekmez. Bu davranış write path'i network gecikmesinden büyük ölçüde ayırır. Özellikle cross-region mimaride düşük latency sağlar. Failover anında son değişikliklerin eksik kalma ihtimali vardır.

Replica'nın Sonradan Catch-Up Yapması

Replica transaction log akışını kendi hızında uygular. Kısa süreli network veya CPU baskısı sonrası geride kalıp daha sonra catch-up yapabilir. Catch-up süresi read freshness ve failover kalitesini etkiler. Çok uzun lag olduğunda replica trafikten çıkarılmalıdır. Apply rate primary log üretim hızından yüksek olmadıkça lag kapanmaz.

Düşük Write Latency

Replica acknowledgement beklenmediği için primary kullanıcıya daha hızlı cevap verebilir. Bu avantaj özellikle uzak region replication'da belirgindir. Ancak düşük latency veri kaybı riskinden bağımsız değildir. Business tarafı hangi riskin kabul edilebilir olduğunu belirlemelidir. Teknik ekip yalnızca performansa göre karar vermemelidir.

Data Loss Window

Primary'de commit edilmiş ama replica'ya ulaşmamış write'lar failure anında kaybolabilir. Bu süre replication lag ve network davranışına bağlıdır. RPO sıfır isteniyorsa async replication tek başına yeterli değildir. Data loss window ölçülmeli ve gözlemlenmelidir. Failover testleri gerçek kayıp ihtimalini anlamaya yardımcı olur.

Eventual Consistency

Replica bir süre primary'den geride kaldığı için okuma eski veri döndürebilir. Sistem sonunda aynı state'e yaklaşır. Bu davranış sosyal feed veya analytics gibi alanlarda kabul edilebilir olabilir. Permission veya finansal state için riskli olabilir. Query bazlı consistency routing uygulanmalıdır.

Semi-Synchronous Replication Nedir?

Semi-synchronous replication sync ve async modeller arasında denge kurmaya çalışır. Primary en az belirli replica acknowledgement bekleyebilir, ancak tüm replica'ların tamamlanmasını şart koşmaz. Böylece durability async modele göre artarken latency tam sync topolojiye göre daha kontrollü kalabilir. Davranış kullanılan database ürününe göre değişir. Gerçek garanti ayar adı üzerinden değil failure testleriyle anlaşılmalıdır.

Sync ve Async Arasında Denge

Bu model write durability ile latency arasında orta nokta sunar. En az bir replica değişikliği aldığında commit güveni artar. Diğer replica'lar async devam edebilir. Yavaş node tüm write yolunu durdurmayabilir. Topoloji business RPO hedefiyle uyumlu seçilmelidir.

Minimum Replica Acknowledgement

Primary belirli sayıda replica acknowledgement şartı koyabilir. Bir replica kaybedilse bile başka node üzerinde güncel kopya bulunabilir. Minimum sayıyı artırmak availability davranışını etkileyebilir. Yeterli replica yoksa write kabul edilip edilmeyeceği politika konusudur. Failure mode önceden test edilmelidir.

Latency vs Durability

Daha güçlü durability genellikle daha fazla coordination gerektirir. Bu coordination network gecikmesini write path'e taşır. Sistem için kabul edilebilir p99 write latency ve data loss budget birlikte tanımlanmalıdır. Tek bir varsayılan ayar tüm business operasyonlarına uymayabilir. Kritik tablo ve düşük riskli tablo farklı strateji kullanabilir.

Single-Leader Replication

Single-leader replication tüm write trafiğinin tek leader üzerinden geçmesini sağlar. Conflict modeli basittir çünkü write sırası merkezi noktada belirlenir. Read replica'lar scale-out read sunabilir. Dezavantaj leader write bottleneck ve failover ihtiyacıdır. PostgreSQL ve MySQL benzeri sistemlerde bu model yaygın biçimde kullanılır.

Tek Write Leader

Tüm write istekleri aynı leader node'a yönlendirilir. Transaction ordering ve unique constraint yönetimi daha doğrudan olur. Uygulama write endpoint'ini açık biçimde bilmelidir. Leader arızasında yeni node seçilene kadar write kesintisi yaşanabilir. Proxy veya managed endpoint discovery'yi sadeleştirebilir.

Basit Conflict Modeli

Birden fazla bağımsız leader olmadığı için concurrent write conflict daha az karmaşık hale gelir. Database normal transaction isolation kurallarıyla state'i yönetebilir. Multi-region local write ihtiyacında bu avantaj azalır. Uzak kullanıcı leader'a network latency öder. Basitlik birçok kurumsal OLTP sisteminde önemli avantajdır.

Write Bottleneck

Leader tüm write'ları işlediği için CPU, disk ve lock kapasitesi doğal sınırdır. Replica sayısını artırmak bu sınırı değiştirmez. Write-heavy workload büyüdüğünde sharding veya farklı leader modeli gerekebilir. Önce transaction ve indeks maliyetleri optimize edilmelidir. Write ceiling gerçek benchmark ile belirlenmelidir.

Failover Gereksinimi

Leader tek aktif write noktası olduğu için failure anında promotion gerekir. Replica güncelliği ve election mekanizması RTO'yu etkiler. Eski leader fencing olmadan geri dönerse split-brain oluşabilir. Client connection pool yeni primary'ye bağlanmalıdır. Failover düzenli chaos test içinde doğrulanmalıdır.

PostgreSQL/MySQL Benzeri Kullanımlar

PostgreSQL streaming replication ve MySQL primary-replica topolojileri bu modele örnek oluşturur. Detaylar engine ve sürüme göre değişir. Read replica, failover ve logical replication seçenekleri farklı davranışlar sunabilir. Managed platformlar discovery ve promotion işlerinin bir bölümünü otomatikleştirebilir. Uygulama yine consistency ve retry davranışını doğru tasarlamalıdır.

Multi-Leader Replication

Multi-leader replication birden fazla node'un write kabul etmesine izin verir. Multi-region uygulamalarda kullanıcıya yakın write latency sağlamak için değerlendirilebilir. Bunun bedeli aynı veriye farklı leader'larda yapılan değişikliklerin conflict oluşturabilmesidir. Conflict resolution business anlamını doğrudan etkiler. Bu nedenle yalnızca latency amacıyla kolayca seçilecek bir model değildir.

Birden Fazla Write Leader

Farklı leader node'lar aynı veri modeline write kabul edebilir. Region bazlı aktif aktif tasarım buna örnek olabilir. Her leader kendi local transaction'ını hızlı tamamlar. Değişiklikler daha sonra diğer leader'lara replike edilir. Aynı entity üzerinde eş zamanlı değişiklik conflict yaratabilir.

Multi-Region Writes

Kullanıcı kendi region'ındaki leader'a write göndererek network latency'yi azaltabilir. Global uygulamalarda kullanıcı deneyimi açısından önemlidir. Ancak cross-region replication gecikmesi farklı leader'ların kısa süre farklı state taşımasına neden olur. Business işlemi conflict toleranslı olmalıdır. Finansal tekil state gibi alanlarda daha güçlü koordinasyon gerekebilir.

Local Write Latency

Local leader write işlemini aynı region içinde tamamlayabilir. Böylece uzak kıta round-trip'i write path'ten çıkar. Kullanıcı p95 latency önemli ölçüde düşebilir. Karşılığında global consistency daha zor hale gelir. Sistem hangi verinin region-local tutulabileceğini ayırmalıdır.

Conflict Resolution

İki leader aynı kaydı farklı değerlerle güncellediğinde çözüm kuralı gerekir. Teknik olarak otomatik bir seçim yapmak business olarak doğru sonucu garanti etmez. Timestamp, merge veya domain-specific kural kullanılabilir. Conflict loglanmalı ve gözlemlenmelidir. Kritik conflict türleri manuel inceleme gerektirebilir.

Last Write Wins

Last Write Wins en yeni olduğu kabul edilen değişikliği tutar. Basit görünse de saat senkronizasyonu ve gerçek business sırası sorun yaratabilir. İki değişiklikten biri sessizce kaybolabilir. Kullanıcı profili gibi bazı alanlarda kabul edilebilir olabilir. Finansal ve envanter işlemlerinde genellikle yeterli değildir.

Merge

Merge iki değişikliğin alan bazında birleştirilmesini amaçlar. Set veya append davranışı bulunan veri modellerinde uygulanabilir. Aynı alan farklı değer aldıysa yine domain kararı gerekebilir. Otomatik merge her veri tipi için güvenli değildir. Conflict örnekleri gerçek workload ile test edilmelidir.

Application-Specific Resolution

Business kuralına özel çözüm çoğu kritik sistemde en doğru sonuç verir. Örneğin stok değişiklikleri son değer yerine operasyon geçmişi üzerinden birleştirilebilir. Bu yaklaşım daha fazla uygulama kodu gerektirir. Conflict event'leri ayrı workflow ile çözülebilir. Veri modeli baştan conflict-aware tasarlanmalıdır.

Leaderless Replication

Leaderless replication read ve write işlemlerini tek leader'a bağlamadan birden fazla replica üzerinden yürütür. Replication factor verinin kaç node'da tutulacağını belirler. Read ve write quorum değerleri consistency davranışını etkiler. Read repair ve anti-entropy mekanizmaları replica farklarını azaltır. Bu model yüksek availability sağlayabilir ancak application consistency beklentisi doğru kurulmalıdır.

Leader Olmadan Read/Write

Client veya coordinator write'ı birden fazla replica'ya gönderebilir. Read işlemi de birden fazla node'dan sonuç alabilir. Tek leader failure noktası yoktur. Node'lardan bazıları erişilemezken operation devam edebilir. Conflict ve version reconciliation daha önemli hale gelir.

Replication Factor

Replication factor her veri parçasının kaç kopya üzerinde tutulacağını ifade eder. N değeri arttıkça storage maliyeti yükselir. Daha fazla replica failure toleransını artırabilir. Region dağılımı da replica placement politikasına dahil edilir. Sadece sayı değil placement önemlidir.

Read Quorum

Read quorum bir read işleminin kaç replica yanıtı bekleyeceğini belirler. Daha yüksek R güncel veriyi görme ihtimalini artırabilir. Aynı zamanda latency ve availability üzerinde maliyet oluşturur. En hızlı replica'dan tek read stale sonuç verebilir. Workload'a göre farklı consistency seviyesi kullanılabilir.

Write Quorum

Write quorum write'ın başarılı sayılması için gereken replica acknowledgement sayısıdır. Daha yüksek W durability ve overlap garantisini güçlendirir. Yeterli replica erişilemiyorsa write başarısız olabilir. Availability ve consistency arasında doğrudan trade-off oluşur. Değerler network partition senaryolarıyla test edilmelidir.

R + W > N

R + W değerinin N'den büyük olması read ve write quorum'larının en az bir replica üzerinde kesişmesini hedefler. Bu ilişki güncel veriyi okuma olasılığını güçlendirir. Yine de versioning ve conflict resolution ayrıntıları önemlidir. Sistem implementasyonunun gerçek consistency davranışı incelenmelidir. Formül tek başına tüm edge case'leri çözmez.

Read Repair

Read sırasında replica'lar arasında farklı sürümler tespit edilirse eski kopya güncellenebilir. Bu mekanizma zamanla tutarlılığı artırır. Read path'e ek çalışma yükü getirebilir. Çok az okunan veriler yalnızca read repair ile uzun süre eski kalabilir. Anti-entropy bu boşluğu tamamlar.

Anti-Entropy

Anti-entropy arka planda replica'lar arasındaki farkları karşılaştırıp düzeltir. Merkle tree benzeri yöntemler kullanılabilir. Bu süreç büyük dataset üzerinde I/O ve network tüketebilir. Maintenance penceresi ve throughput kontrol edilmelidir. Repair health üretim metriği olarak izlenmelidir.

Read Replica Mimarisi

Read replica mimarisi read ve write sorgularını farklı node rollerine ayırır. Write ve consistency duyarlı read primary'ye, ölçeklenebilir stale-tolerant read replica'ya gider. Load balancer birden fazla replica arasında trafik dağıtabilir. Analytics için ayrı replica kullanmak OLTP read kapasitesini korur. Routing politikası lag ve business consistency gereksinimine göre hazırlanmalıdır.

Primary Reads

Yeni write sonrası güncel veri gerektiğinde primary read güvenli seçimdir. Permission veya hesap bakiyesi gibi alanlar da primary üzerinden okunabilir. Tüm read'leri primary'de tutmak replica kapasite avantajını azaltır. Query bazlı routing daha iyi denge sağlar. Application hangi read'in güçlü consistency istediğini bilmelidir.

Replica Reads

Listeleme, geçmiş rapor veya cache'e yakın sorgular replica'dan okunabilir. Replica lag varsa sonuç primary'den birkaç saniye geride olabilir. Kullanıcı deneyimi bunu tolere edebiliyorsa read scaling sağlanır. Lag threshold aşıldığında replica otomatik trafikten çıkarılabilir. Aynı replica'ya analytics yükü bindirmek dikkat gerektirir.

Read/Write Splitting

Read/write splitting write sorgularını primary'ye, uygun read sorgularını replica'lara yönlendirir. Routing uygulama kodu, ORM veya proxy üzerinden yapılabilir. Transaction içindeki read'ler genellikle primary connection'da kalmalıdır. Yanlış sınıflandırılmış read eski state kullanabilir. Testler replication lag altında davranışı doğrulamalıdır.

Replica Load Balancing

Birden fazla replica arasında read trafiği dağıtılabilir. Round-robin en basit yöntemdir. Latency veya lag-aware algoritmalar daha akıllı seçim yapabilir. Region bilgisi kullanıcıya yakın replica'yı seçmeye yardım eder. Load balancer health check stale node'u dışarı çıkarabilmelidir.

Read-Only Analytics Replica

Ağır analytics sorguları için ayrı replica oluşturmak production read workload'u izole eder. Bu replica failover adayı olmak zorunda değildir. Daha büyük CPU veya storage seçilebilir. Uzun sorgular replication apply performansını etkiliyorsa bu durum izlenmelidir. Çok büyük analytics ihtiyacı sonunda ayrı warehouse gerektirebilir.

Read/Write Routing Nasıl Yapılır?

Read/write routing uygulamanın consistency ve performance hedeflerini doğrudan etkiler. Application-level kod en fazla kontrolü sağlarken proxy daha merkezi çözüm sunabilir. Managed database endpoint bazı topology ayrıntılarını gizleyebilir. ORM routing kolaylık sağlar ancak transaction davranışı dikkatle incelenmelidir. Lag-aware kararlar yalnızca static role bilgisine dayanmamalıdır.

Application-Level Routing

Uygulama repository veya data access layer seviyesinde primary ve replica seçebilir. Business context'e göre read-after-write kararı verilebilir. En esnek yaklaşım olsa da kodun farklı yerlerine routing mantığı dağılmamalıdır. Ortak library veya abstraction kullanılabilir. Sharding eklendiğinde aynı katman shard routing ile birleşebilir.

ORM Routing

Bazı ORM araçları read replica ve write primary ayrımını destekler. Bu özellik temel kullanımda geliştirme hızını artırır. Ancak transaction, raw query ve retry davranışı yakından test edilmelidir. ORM'in query'nin consistency ihtiyacını business adına bilmesi mümkün değildir. Kritik sorgular için açık route mekanizması bırakılmalıdır.

Database Proxy

Database proxy connection yönetimi ve read/write routing sağlayabilir. Uygulama daha az topology bilgisi taşır. Proxy kendi HA ve scaling tasarımına ihtiyaç duyar. Query parsing ile routing yapan sistemlerde edge case'ler test edilmelidir. Proxy arızası tüm database erişimini etkilememelidir.

Managed Database Endpoint

Managed platformlar writer ve reader endpoint sunabilir. Failover sırasında writer endpoint yeni primary'ye yönlendirilebilir. Bu kullanım operasyon işini azaltır. DNS cache ve connection pool yeni route'u hemen görmeyebilir. Client reconnect davranışı yine test edilmelidir.

Read Replica Load Balancer

Replica endpoint'leri load balancer arkasında gruplanabilir. Health check yalnızca TCP erişimini değil lag durumunu da değerlendirmelidir. Stale replica kullanıcıya eski state sunabilir. Region ve latency bilgisi seçim algoritmasına eklenebilir. Load balancer kendisi de yüksek erişilebilir tasarlanmalıdır.

Replication Lag Nedir?

Replication lag primary'de commit edilen değişiklik ile replica'nın aynı değişikliği uygulaması arasındaki gecikmedir. Network, I/O, CPU ve uzun transaction bu süreyi artırabilir. Lag sıfır kabul edilerek tasarlanan read replica sistemi kullanıcıya eski veri gösterebilir. Bu yüzden lag sürekli ölçülmeli ve routing kararına dahil edilmelidir. Replication lag yalnızca performans metriği değil consistency risk göstergesidir.

Write'ın Primary'de Commit Edilmesi

Write primary üzerinde başarıyla commit edilir. Kullanıcı bu noktada işlemin tamamlandığını düşünebilir. Async replica aynı değişikliği henüz almamış olabilir. Hemen replica'dan read yapılırsa eski değer dönebilir. Read-after-write tasarımı bu pencereyi yönetir.

Network Delay

Primary ile replica arasındaki network latency log aktarımını geciktirebilir. Cross-region bağlantılarda doğal olarak daha yüksek süre oluşur. Paket kaybı ve kısa kesintiler lag'i büyütebilir. Network düzelince replica catch-up yapar. Link health replication dashboard'a dahil edilmelidir.

Replica Apply Delay

Log replica'ya ulaşmış olsa bile storage engine değişiklikleri henüz uygulamamış olabilir. CPU veya disk saturation apply hızını düşürür. Büyük transaction tek seferde önemli backlog oluşturabilir. Apply rate log üretim hızının altına düşerse lag sürekli büyür. Bu durum replica boyutlandırmasının yetersiz olduğunu gösterebilir.

Long-Running Query Etkisi

Bazı engine ve topolojilerde uzun read sorguları recovery veya apply davranışını etkileyebilir. Analytics sorgusu replica kaynaklarını tüketerek lag'i artırabilir. Bu nedenle ağır reporting replica'sı ayrı tutulabilir. Query timeout ve workload isolation fayda sağlar. Failover adayı replica mümkün olduğunca sağlıklı tutulmalıdır.

I/O Saturation

Replica disk kapasitesi log apply hızının altında kalabilir. Aynı storage üzerinde backup veya ağır read yükü I/O yarışına neden olabilir. Lag bu durumda network iyi olsa bile artar. Disk queue ve latency metrikleri incelenmelidir. Daha hızlı storage veya workload ayrımı gerekebilir.

Replica'nın Primary'den Geri Kalması

Replica geride kaldığında read freshness düşer ve failover kalitesi bozulur. Çok eski replica promotion için risklidir. Maximum lag threshold aşılırsa read trafiğinden çıkarılabilir. Catch-up tamamlandıktan sonra otomatik geri alınabilir. Bu süreç alert ve dashboard üzerinden görünür olmalıdır.

Replication Lag Kullanıcıyı Nasıl Etkiler?

Replication lag teknik metrik gibi görünse de kullanıcı davranışında doğrudan hatalara dönüşebilir. Kullanıcı kaydettiği veriyi tekrar açtığında görmeyebilir. Permission değişikliği geç uygulanırsa güvenlik riski oluşabilir. Sayaç ve finansal durumlarda stale read yanlış karar doğurabilir. Bu nedenle read replica kullanımı endpoint bazında business risk analizi gerektirir.

Stale Read

Stale read replica'nın primary'den eski state döndürmesidir. Birkaç saniyelik fark bazı liste ekranlarında önemsiz olabilir. Aynı fark ödeme durumu için kabul edilemez olabilir. Sistem hangi verinin stale olabileceğini açıkça sınıflandırmalıdır. Consistency tek bir global ayar olmak zorunda değildir.

Kullanıcının Kaydettiği Veriyi Görememesi

Kullanıcı profilini güncelledikten hemen sonra sayfa replica'dan okunursa eski isim görülebilir. Bu durum kullanıcıda işlemin başarısız olduğu algısı yaratır. Sticky primary window basit çözüm sunabilir. Session son write zamanını takip edebilir. Daha gelişmiş sistemler replication position kullanabilir.

Yanlış Sayımlar

Replica üzerinden yapılan count sorgusu son write'ları içermeyebilir. Dashboard veya quota sistemi yanlış değer gösterebilir. Sayaç karar amaçlı kullanılıyorsa primary veya farklı consistency mekanizması gerekebilir. Analytics amaçlı yaklaşık değer toleranslı olabilir. Business semantiği read source'u belirlemelidir.

Eski Permission/State Okuma

Yetki kaldırıldığı halde replica eski permission kaydını tutabilir. Uygulama authorization'ı replica üzerinden yaparsa kısa süreli yetkisiz erişim oluşabilir. Güvenlik duyarlı state primary veya güçlü consistent store üzerinden okunmalıdır. Cache de aynı riski taşıyabilir. Permission sistemi performance uğruna stale hale getirilmemelidir.

Finansal Riskler

Bakiye veya işlem durumu eski okunduğunda kullanıcıya yanlış karar verilebilir. Çift harcama benzeri riskler yalnızca replica lag değil transaction modelinden de etkilenir. Finansal işlemler güçlü consistency ve idempotency gerektirir. Read replica yalnızca risk toleranslı raporlama amaçlı kullanılabilir. Business risk RPO ve consistency tasarımına doğrudan çevrilmelidir.

Read-After-Write Consistency Nasıl Sağlanır?

Read-after-write consistency kullanıcının write işleminden sonra yeni state'i görmesini sağlar. En basit yaklaşım belirli süre primary'den okumaktır. Session routing veya replication position daha hassas çözümler sunabilir. Lag-aware router uygun replica güncelliğine göre seçim yapabilir. Yöntem latency, complexity ve consistency gereksinimine göre seçilmelidir.

Write Sonrası Primary'den Okuma

Write yapan request sonrasındaki read doğrudan primary'ye yönlendirilebilir. Böylece replica catch-up beklenmez. Basit ve güvenilir yöntemdir. Çok uzun süre primary route kullanmak read scaling avantajını azaltabilir. Süre veya session durumu üzerinden sınırlandırılmalıdır.

Sticky Primary Window

Kullanıcı write yaptıktan sonra örneğin birkaç saniye primary'ye sticky hale getirilebilir. Bu süre tipik replication lag değerinden büyük seçilir. Uygulaması kolaydır. Lag nadiren pencereyi aşarsa yine stale read oluşabilir. Dinamik lag bilgisi daha hassas çözüm sağlar.

Session-Based Routing

Kullanıcı session'ı son write zamanını veya state'i taşıyabilir. Router bu bilgiye göre primary veya replica seçer. Birden fazla application instance ortak session store kullanabilir. Stateless token içine hassas routing state koymak dikkat gerektirir. Session süresi gereksiz primary yükü oluşturmamalıdır.

Replication Position Takibi

Write sonrası transaction log position veya benzeri replication marker alınabilir. Read yalnızca bu position'a ulaşmış replica'dan yapılabilir. Bu yöntem zaman tabanlı sticky window'dan daha hassastır. Uygulama ve database driver desteği gerekebilir. Cross-region sistemlerde bekleme süresi uzayabilir.

Lag-Aware Read Routing

Router her replica'nın güncellik durumunu izleyebilir. Belirli lag threshold üzerindeki node read havuzundan çıkarılır. Kullanıcının consistency ihtiyacı daha katıysa yalnızca yeterince güncel replica seçilir. Uygun replica yoksa primary fallback yapılabilir. Routing metriği gözlemlenebilir olmalıdır.

Read-Your-Writes Nedir?

Read-your-writes bir kullanıcının kendi yaptığı değişiklikleri sonraki okumalarında görmesini garanti etmeyi hedefler. Sistem genel olarak eventual consistency kullanırken bu session-level garanti ayrıca sağlanabilir. Kullanıcının son write bilgisi routing kararına dahil edilir. Diğer kullanıcılar kısa süre eski state görebilir. Bu yaklaşım kullanıcı deneyimi ile read scaling arasında iyi denge kurabilir.

Kullanıcının Kendi Write'ını Görmesi

Kullanıcı kaydettiği profil veya ayarı hemen görmek ister. Replica lag bu deneyimi bozabilir. Primary stickiness veya replication marker çözüm sunar. Garanti yalnızca aynı kullanıcı session'ı için uygulanabilir. Bu sayede tüm sistem strong consistency maliyeti taşımaz.

Eventual Consistency ile Birlikte Kullanım

Sistem genel olarak replica'larda eventual consistency kabul edebilir. Buna rağmen write yapan kullanıcıya daha güçlü session guarantee sunulabilir. Diğer read'ler replica'dan devam eder. Bu hybrid model büyük read-heavy uygulamalarda kullanışlıdır. Business state sınıfına göre farklı garanti seviyeleri tanımlanabilir.

User Session Routing

Session son write zamanını veya region bilgisini taşıyabilir. Router belirli süre primary veya uygun replica kullanır. Kullanıcı farklı cihazdan bağlanırsa session garantisi yeniden düşünülmelidir. Account-level marker merkezi store'da tutulabilir. Çözüm ürün deneyimiyle uyumlu seçilmelidir.

Replica Seçimi Nasıl Yapılmalıdır?

Replica seçimi yalnızca yük dağıtma problemi değildir. Latency, lag, connection ve region bilgisi birlikte değerlendirilebilir. Basit round-robin küçük sistemlerde yeterli olabilir. Global veya yüksek trafikli mimaride lag-aware ve region-aware routing daha iyi sonuç verir. Health durumu kötü replica otomatik olarak seçim havuzundan çıkarılmalıdır.

Round-Robin

Round-robin istekleri sırayla replica'lara dağıtır. Basit ve düşük maliyetlidir. Tüm replica'ların benzer kapasite ve lag'e sahip olduğunu varsayar. Bir node yavaşlarsa trafik almaya devam edebilir. Health check ile desteklenmelidir.

Least Connections

Least connections en az aktif bağlantıya sahip replica'yı seçer. Farklı query sürelerinin oluşturduğu yükü kısmen dengeleyebilir. Connection sayısı CPU veya lag durumunu tam temsil etmez. Yine de uzun sorgulu workload'da round-robin'den daha iyi olabilir. Diğer sağlık sinyalleriyle birlikte kullanılmalıdır.

Latency-Based

Router en düşük network veya query latency gösteren replica'yı seçebilir. Global kullanıcılar için region yakınlığı doğal avantaj sağlar. Yalnızca latency'ye bakmak stale replica seçme riskini doğurur. Lag threshold ayrıca uygulanmalıdır. Ölçüm p95 gibi stabil sinyallere dayanmalıdır.

Replication-Lag-Based

Replica lag routing kararının doğrudan girdisi olabilir. En güncel replica preference alabilir. Threshold üzerindeki node tamamen dışarı çıkarılabilir. Ani lag dalgalanması sürekli route değişimine neden olmamalıdır. Hysteresis veya recovery window kullanılabilir.

Region-Aware Routing

Kullanıcıya yakın replica network latency'yi düşürür. Region bilgisi request context'ten belirlenebilir. Data residency kuralları bazı region'lar arasında read'i sınırlayabilir. Yerel replica çok gerideyse başka region veya primary fallback gerekebilir. Policy açık biçimde belgelenmelidir.

Stale Replica Trafikten Nasıl Çıkarılır?

Stale replica kullanıcılara eski veri sunmaması için otomatik sağlık mekanizmasına bağlanmalıdır. Maximum lag threshold en temel kriterlerden biridir. Health check node'un yalnızca erişilebilir olup olmadığını değil replication durumunu da değerlendirmelidir. Sorunlu replica quarantine durumuna alınabilir. Catch-up tamamlandıktan sonra kontrollü biçimde yeniden trafik almalıdır.

Maximum Lag Threshold

Business toleransına göre kabul edilebilir maksimum replication lag belirlenir. Örneğin analytics için daha yüksek, kullanıcı session read'i için daha düşük eşik kullanılabilir. Tek global threshold yeterli olmayabilir. Metric yanlış veya gecikmeli gelirse routing korunmalıdır. Threshold production baseline üzerinden seçilmelidir.

Health Check

Health check network bağlantısı, query response ve replication state'i kontrol edebilir. Sadece port açık olması replica'nın sağlıklı olduğunu göstermez. Lag ve apply error ayrıca değerlendirilmelidir. Çok sık health check ek yük oluşturabilir. Interval failure detection hedefiyle dengelenmelidir.

Replica Quarantine

Sağlıksız node routing pool'undan çıkarılıp quarantine durumuna alınabilir. Bu sırada catch-up yapmasına izin verilir. Kullanıcı trafiği apply kapasitesini tüketmez. Operator gerekiyorsa root cause incelemesi yapar. Otomatik geri dönüş koşulları net olmalıdır.

Automatic Recovery

Replica lag güvenli seviyeye döndüğünde otomatik yeniden trafik alabilir. Hemen tam yük vermek yerine kademeli ramp-up kullanılabilir. Aynı node sürekli düşüp geri geliyorsa flapping alarmı gerekir. Recovery sonrası error ve latency izlenmelidir. Otomasyon manuel müdahale ihtiyacını azaltır.

Database Sharding Nedir?

Database sharding dataset'i yatay olarak birden fazla bağımsız database bölgesine dağıtır. Her shard verinin yalnızca kendi anahtar aralığını veya hash bölümünü taşır. Böylece storage ve write throughput birden fazla primary node arasında bölünebilir. Query router doğru shard'ı seçmek zorundadır. Sharding güçlü ölçekleme sağlarken cross-shard query, transaction ve migration maliyetini artırır.

Horizontal Data Partitioning

Sharding satırları yatay biçimde farklı node'lara böler. Kolonlar aynı şemayı takip ederken kayıtların bir kısmı shard 1, diğer kısmı shard 2 üzerinde bulunabilir. Dağıtım shard key üzerinden yapılır. Query key içeriyorsa tek shard'a hızlı yönlenebilir. Key yoksa birden fazla shard sorgulanabilir.

Dataset'i Birden Fazla Database'e Bölmek

Tek node'a sığmayan dataset birden fazla database instance'a bölünebilir. Her instance daha küçük working set taşır. Backup ve maintenance shard bazında yapılabilir. Global işlem gereksinimi ise daha zor hale gelir. Metadata hangi verinin hangi shard'da olduğunu doğru tutmalıdır.

Her Shard'ın Verinin Bir Bölümünü Tutması

Her shard yalnızca belirli anahtar alanına ait kayıtları barındırır. Bu davranış node başına storage ihtiyacını azaltır. Query locality iyi tasarlanırsa çoğu işlem tek shard'da kalır. Cross-shard erişim oranı yükseldikçe latency ve coordination artar. Shard key bu nedenle uzun vadeli tasarım kararıdır.

Write ve Storage Scaling

Farklı shard'lar kendi primary node'larında write kabul edebilir. Böylece toplam write kapasitesi tek leader sınırını aşabilir. Dataset de fiziksel olarak dağıtıldığı için storage scale-out sağlanır. Hot shard oluşursa teorik kapasite pratikte kullanılamayabilir. Dengeli dağılım ve rebalancing zorunludur.

Sharding Ne Zaman Gereklidir?

Sharding ancak daha basit ölçekleme araçları gerçek sınırları çözemediğinde uygulanmalıdır. Single-node write ceiling, dataset kapasitesi veya çok büyük tenant izolasyonu güçlü gerekçelerdir. Data locality ve residency gereksinimleri de shard mimarisini destekleyebilir. Fault isolation için büyük tenant ayrı shard'a taşınabilir. Her durumda resharding ve migration planı ilk tasarımın parçası olmalıdır.

Single-Node Write Ceiling

Primary CPU, disk veya transaction log kapasitesi optimize edilmiş workload'u artık taşıyamıyorsa write scale-out gerekir. Sharding write trafiğini birden fazla primary'ye bölebilir. Key dağılımı dengesizse beklenen kazanç oluşmaz. Global unique ve transaction kuralları ayrıca çözülmelidir. Benchmark shard başına güvenli kapasiteyi belirler.

Dataset Tek Node'a Sığmıyor

Dataset depolama veya working set açısından tek node sınırına yaklaşıyorsa sharding doğal çözüm olabilir. Sadece disk kapasitesi değil backup ve restore süresi de dikkate alınmalıdır. Çok büyük node arızası daha uzun recovery yaratabilir. Shard'lar failure domain'i küçültür. Metadata kaybı ise tüm sistemi etkileyebileceği için ayrıca korunmalıdır.

Çok Büyük Multi-Tenant Sistem

Binlerce tenant aynı database içinde büyüdüğünde birkaç büyük müşteri toplam kaynakların çoğunu tüketebilir. Tenant-based sharding izolasyon ve kapasite yönetimi sağlar. Küçük tenant'lar shared shard üzerinde tutulabilir. Büyük enterprise tenant dedicated shard'a taşınabilir. Tenant move operasyonu baştan desteklenmelidir.

Data Locality

Verinin kullanıldığı compute'a yakın tutulması network maliyetini azaltabilir. Region veya tenant bazlı shard locality sağlayabilir. Aynı entity'nin ilişkili verileri aynı shard'da tutulmalıdır. Aksi halde cross-shard join artar. Query pattern shard key seçiminin merkezinde olmalıdır.

Data Residency

Regülasyon bazı verilerin belirli ülke veya region sınırında tutulmasını gerektirebilir. Geographic sharding bu gereksinimi fiziksel placement kuralına dönüştürebilir. Backup ve replica da aynı residency politikasına uymalıdır. Global query farklı region'lara erişim gerektirebilir. Compliance gereksinimi metadata modeline dahil edilmelidir.

Fault Isolation

Bir shard arızalandığında yalnızca o veri bölümünün etkilenmesi hedeflenebilir. Tüm kullanıcıların tek database failure'dan etkilenmesi önlenir. Ancak shared router veya metadata sistemi yeni global failure point olmamalıdır. Büyük tenant ayrı shard'a taşınarak noisy neighbor etkisi azaltılabilir. Fault domain tasarımı topology ile birlikte düşünülmelidir.

Shard Key Nedir?

Shard key bir kaydın hangi shard üzerinde tutulacağını belirleyen anahtar veya anahtar birleşimidir. Sistem scalability'sinin en kritik uzun vadeli kararlarından biridir. İyi key veriyi ve trafiği dengeli dağıtırken query locality sağlar. Kötü key hot shard ve scatter-gather sorgular üretir. Shard key seçmeden önce gerçek production access pattern'leri analiz edilmelidir.

Verinin Hangi Shard'a Gideceğini Belirleyen Alan

Router shard key değerini kullanarak hedef shard'ı hesaplar veya shard map'ten bulur. Tenant ID, user ID veya composite key kullanılabilir. Key yazım sırasında mevcut olmalıdır. Query sırasında key bulunursa tek shard route mümkündür. Sonradan key değiştirmek veri migration gerektirebilir.

Partition Key ile İlişkisi

Partition key ve shard key bazı sistemlerde aynı kavramı ifade edebilir. Diğerlerinde partition database içi, shard ise node dağılımı için kullanılır. Engine terminolojisi dikkatle okunmalıdır. Temel amaç veri placement kararını belirlemektir. Uygulama kendi domain anahtarıyla teknik key ilişkisini açık tutmalıdır.

Query Routing

Query shard key içeriyorsa router hedef node'u doğrudan bulabilir. Key yoksa birden fazla shard sorgulanması gerekebilir. Bu fan-out latency ve network maliyetini artırır. Access pattern analizinde her query'nin shard key kullanım oranı ölçülmelidir. Kritik path mümkün olduğunca single-shard kalmalıdır.

Shard Key'in Uzun Vadeli Etkisi

Shard key veri dağılımını yıllarca etkileyebilir. Tenant büyüme modeli veya trafik deseni değiştiğinde başlangıçta iyi key hot hale gelebilir. Resharding mümkün olsa da maliyetli süreçtir. Key gelecekteki growth senaryolarıyla test edilmelidir. Sentetik ve gerçek trafik simülasyonu fayda sağlar.

İyi Bir Shard Key'in Özellikleri

İyi shard key yüksek cardinality, dengeli veri dağılımı ve dengeli trafik üretir. Aynı zamanda sık sorgulanan ilişkili veriyi mümkün olduğunca aynı shard üzerinde tutar. Cross-shard query oranını düşürür. Gelecekteki dataset büyümesine ve tenant değişimine uyum sağlar. Hiçbir key tüm hedefleri kusursuz karşılamadığı için dağılım ile locality arasında bilinçli denge gerekir.

High Cardinality

Çok sayıda farklı değer üreten key veriyi daha fazla bucket'a dağıtma fırsatı verir. Boolean gibi iki değerli alan kötü shard key'dir. User ID veya yüksek cardinality tenant ID daha uygun olabilir. Cardinality tek başına yeterli değildir. Trafiğin değerler arasında nasıl dağıldığı ayrıca ölçülmelidir.

Even Distribution

Veri miktarı shard'lar arasında dengeli olmalıdır. Bir shard toplam dataset'in büyük kısmını taşıyorsa storage scaling verimsizleşir. Hash tabanlı key genellikle iyi dağılım sağlar. Büyük tenant gibi skew durumları yine sorun yaratabilir. Skew ratio düzenli izlenmelidir.

Uniform Traffic

Row dağılımı dengeli olsa bile trafik dengeli olmayabilir. Bir celebrity user milyonlarca request alabilir. Bu durumda user ID hash edilmiş olsa bile tek shard hot olur. Traffic distribution veri dağılımından ayrı ölçülmelidir. Hot entity için split veya synthetic key gerekebilir.

Query Locality

İlişkili sorguların aynı shard üzerinde çalışması latency ve transaction maliyetini azaltır. Tenant ID SaaS sistemlerinde güçlü locality sağlayabilir. Aynı tenant'ın orders, invoices ve users verisi birlikte tutulabilir. Global raporlar cross-shard kalır. OLTP access pattern öncelikli olmalıdır.

Düşük Cross-Shard Query İhtiyacı

Shard key sık kullanılan filtre ve join'lerle uyumlu olmalıdır. Key query'de yoksa router birden fazla shard'a fan-out yapar. Bu yaklaşım küçük shard sayısında tolere edilebilir. Shard sayısı büyüdükçe tail latency artar. Query envanteri seçim öncesi hazırlanmalıdır.

Gelecekteki Büyümeye Uygunluk

Bugün dengeli görünen key birkaç yıl sonra skew oluşturabilir. Bölgesel büyüme veya enterprise tenant kazanımı dağılımı değiştirebilir. Key adayları gelecekteki senaryolarla simüle edilmelidir. Tenant move veya shard split imkanı bırakılmalıdır. Resharding'in mümkün olması güvenli büyüme sağlar.

Kötü Shard Key Örnekleri

Kötü shard key genellikle düşük cardinality, monotonik artış veya trafik skew'u üretir. Veri dağılımı dengeli görünse bile query pattern ile uyumsuz alan scatter-gather maliyetini artırabilir. Sequential ID yeni write'ları tek range shard'a yönlendirebilir. Dengesiz tenant ID büyük müşteriyi tek shard üzerinde yoğunlaştırabilir. Key seçimi yalnızca schema alanlarına bakılarak yapılmamalıdır.

Boolean

Boolean yalnızca iki değer üretir. Bu nedenle yüzlerce shard'a dengeli dağıtım mümkün değildir. En iyi durumda iki büyük veri grubu oluşur. Trafik de iki noktada yoğunlaşır. Shard key için uygun değildir.

Düşük Cardinality Country

Country alanı bazı global sistemlerde onlarca veya yüzlerce değer taşıyabilir. Ancak trafik birkaç ülkede yoğunlaşabilir. Türkiye veya ABD gibi büyük region tek shard'ı aşırı yükleyebilir. Data residency için region useful olsa da ek hash bileşeni gerekebilir. Composite key locality ile dağılımı dengeleyebilir.

Monotonik Timestamp

Zaman sürekli ileri gittiği için yeni write'lar en son range'e düşer. Bu durum newest shard'ı hot hale getirir. Tarih sorgularında locality avantajı olsa da write dağılımı kötüdür. Time bucket + hash yaklaşımı daha dengeli olabilir. Workload'a göre eski data cold storage'a taşınabilir.

Sequential ID

Range-based sequential ID yeni kayıtları aynı shard'a yönlendirebilir. Eski shard'lar düşük write alırken son shard doygunlaşır. Hashing sequential ID etkisini azaltabilir. Range query ihtiyacı varsa composite strateji düşünülmelidir. ID üretim modeli shard dağılımından bağımsız tasarlanmamalıdır.

Trafiği Çok Dengesiz Tenant ID

Tenant ID güçlü locality sağlar fakat tenant boyutları çok farklıysa sorun yaratabilir. Tek enterprise tenant shard kapasitesinin çoğunu kullanabilir. Tenant dedicated shard'a taşınabilir. Büyük tenant içinde ikinci seviye sharding uygulanabilir. Tenant mobility başlangıçtan desteklenmelidir.

Query'lerde Hiç Kullanılmayan Alan

Dağılımı güzel olan ama sorgularda bulunmayan key routing'i zorlaştırır. Her request shard key'i bulmak için ek lookup yapabilir. Alternatif olarak tüm shard'lara fan-out gerekir. Bu durum application latency'yi artırır. Key erişim deseninin doğal parçası olmalıdır.

Hot Shard Nedir?

Hot shard toplam trafik veya veri yükünün orantısız biçimde tek shard üzerinde toplanmasıdır. Sistem teorik olarak çok shard'lı olsa bile tek hot shard tüm kullanıcı latency'sini belirleyebilir. Celebrity user, büyük tenant veya monotonik time range bu durumu yaratabilir. CPU, I/O ve connection saturation shard bazında izlenmelidir. Hot shard sorunu veri dağılımı kadar trafik dağılımını da incelemeyi gerektirir.

Trafiğin Tek Shard'da Yoğunlaşması

Toplam query'nin büyük kısmı tek shard'a gidiyorsa diğer node'ların kapasitesi boşa kalır. Global average CPU bu sorunu gizleyebilir. Per-shard QPS ve p99 latency izlenmelidir. Routing key dağılımı analiz edilmelidir. Gerekirse shard split veya key değişikliği yapılır.

Celebrity User Problemi

Tek kullanıcı çok yüksek trafik alabilir. Social veya marketplace sistemlerinde büyük hesaplar normal dağılımı bozabilir. User ID hash edilse bile bu user tek shard üzerinde kalır. Read cache veya entity sub-sharding çözüm olabilir. Business erişim modeli özel işlem gerektirebilir.

Hot Tenant

Büyük tenant diğer tenant'ların bulunduğu shared shard'ı doygun hale getirebilir. Dedicated shard'a taşıma izolasyon sağlar. Tenant move işlemi online migration desteklemelidir. SLA farkı placement politikasına yansıtılabilir. Whale tenant baştan kapasite modeli içinde düşünülmelidir.

Son Zaman Aralığının Hot Olması

Range-based time sharding yeni write'ları en yeni partition'a yönlendirir. Son saat veya gün shard'ı diğerlerinden çok daha fazla yük alır. Hash suffix write'ları birkaç active shard arasında dağıtabilir. Read sorguları merge gerektirebilir. Lokalizasyon ile dağılım arasında denge kurulmalıdır.

CPU/I/O Saturation

Hot shard CPU veya disk sınırına ulaştığında o shard'a ait tüm kullanıcılar yavaşlar. Diğer shard'lar düşük kullanımda kalabilir. Horizontal node sayısını artırmak key dağılımı değişmeden fayda sağlamaz. Hot data taşınmalı veya split edilmelidir. Alert shard bazlı threshold kullanmalıdır.

Hot Shard Nasıl Önlenir?

Hot shard önleme shard key tasarımından başlar. Hashing ve composite key dağılımı iyileştirebilir. Büyük tenant veya özel entity'ler dedicated shard'a taşınabilir. Gerekirse salt veya synthetic partition key ile tek hot key birkaç fiziksel bölüme ayrılır. Son çare değil, normal operasyon olarak shard split mekanizması hazır olmalıdır.

Hashing

Hash fonksiyonu sequential veya skew olmayan key'leri daha dengeli dağıtabilir. Point query doğrudan hash sonucu üzerinden route edilir. Range locality azalır. Hot tek key hashing ile bölünmez çünkü aynı key aynı hash değerine gider. Böyle durumda ek salt gerekir.

Composite Shard Key

Birden fazla alanı birleştirmek locality ve distribution arasında denge sağlayabilir. Tenant ID + entity hash buna örnek olabilir. Büyük tenant birden fazla sub-shard'a dağılabilir. Query iki alanı da taşıyorsa routing kolay olur. Key tasarımı application access pattern ile birlikte yapılmalıdır.

Salt / Random Suffix

Hot key'e küçük bir random veya deterministic suffix eklenerek write farklı shard'lara yayılabilir. Read işlemi tüm suffix değerlerini sorgulamak zorunda kalabilir. Bu yüzden read amplification kabul edilebilir olmalıdır. Suffix sayısı kapasite ihtiyacına göre seçilir. Global aggregation merge gerektirir.

Synthetic Partition Key

Domain key doğrudan uygun değilse uygulama yeni teknik key üretebilir. Örneğin tenant ve bucket numarası birleştirilebilir. Bu key routing için optimize edilir. Domain modelinden ayrı tutulmalıdır. Migration ve debugging sırasında mapping anlaşılır olmalıdır.

Tenant Isolation

Büyük tenant shared shard'tan dedicated shard'a taşınabilir. Bu yöntem diğer müşterileri noisy neighbor etkisinden korur. Directory-based routing tenant'ın yeni konumunu kolayca güncelleyebilir. Move sırasında dual read veya CDC kullanılabilir. Tenant placement kapasite politikasıyla otomatikleşebilir.

Shard Split

Hot shard iki veya daha fazla yeni shard'a bölünebilir. Key range veya virtual bucket'lar yeniden atanır. Online split sırasında source ve target state senkron tutulmalıdır. Traffic cutover doğrulama sonrası yapılır. Shard split runbook production öncesi test edilmelidir.

Hash-Based Sharding

Hash-based sharding shard key'i hash fonksiyonundan geçirerek veriyi shard'lara dağıtır. Dengeli key dağılımında storage ve traffic skew'u azaltabilir. Point query hedef shard'ı hızlı bulur. Range query locality'si zayıftır. Basit modulo yaklaşımı node sayısı değiştiğinde büyük rehash maliyeti yaratabileceği için dikkatle seçilmelidir.

hash(key) % N

En basit yaklaşım hash sonucunu shard sayısına göre modulo almaktır. Uygulaması kolay ve deterministiktir. N değiştiğinde birçok key'in hedef shard'ı değişir. Bu durum büyük veri migration gerektirir. Consistent hashing daha az remapping sağlayabilir.

Dengeli Dağılım

İyi hash fonksiyonu yüksek cardinality key'leri shard'lara dengeli dağıtır. Veri ve write trafiği teorik olarak benzer olabilir. Hot tek key problemi devam eder. Shard kapasitesi farklıysa weighted mapping gerekebilir. Dağılım gerçek veride ölçülmelidir.

Point Query Avantajı

Shard key biliniyorsa hash doğrudan hedef node'u verir. Tek shard query düşük latency ile çalışır. Router tüm cluster'a broadcast yapmak zorunda kalmaz. Primary key lookup buna uygun örnektir. Query'nin key'i taşımadığı access pattern zorluk yaratır.

Range Query Dezavantajı

Hash aynı aralıktaki değerleri farklı shard'lara dağıtır. Tarih veya ID aralığı sorgusu tüm shard'lara fan-out yapabilir. Sonuçlar application veya proxy seviyesinde merge edilir. Shard sayısı büyüdükçe latency artar. Range-heavy workload için farklı key stratejisi daha uygun olabilir.

Node Sayısı Değiştiğinde Rehash Problemi

Modulo tabanlı hash'te N değişince büyük miktarda key yeni shard'a taşınır. Online migration pahalı hale gelir. Virtual bucket veya consistent hash mapping bu etkiyi azaltabilir. Yine de gerçek data copy devam eder. Scaling topology baştan rebalancing desteklemelidir.

Range-Based Sharding

Range-based sharding key değer aralıklarını farklı shard'lara atar. ID veya tarih tabanlı sorgularda güçlü locality sağlar. Belirli aralık yalnızca birkaç shard'a dokunabilir. Dezavantaj monotonik write pattern'in en yeni shard'ı hot hale getirmesidir. Range sınırlarının dinamik split ile değiştirilebilir olması önemlidir.

ID Range

ID 1-10 milyon shard A, sonraki aralık shard B gibi bölünebilir. Query ID üzerinden doğrudan target bulur. Sequential insert yeni range üzerinde yoğunlaşır. Eski shard'lar read ağırlıklı kalabilir. Active range'i birkaç shard'a bölmek gerekebilir.

Tarih Aralığı

Tarih bazlı shard zaman serisi ve archive workload'unda doğal locality sağlar. Eski veriyi daha ucuz storage'a taşımak kolaylaşır. Yeni tarih aralığı sürekli write alır. Hot range riskine karşı time bucket + hash kullanılabilir. Global time range query birden fazla shard'a dokunur.

Range Query Avantajı

Query belirli zaman veya ID aralığı istiyorsa yalnızca ilgili shard'lar taranır. Bu durum hash sharding'e göre daha az fan-out üretir. Sorting ve pagination da belirli senaryolarda kolaylaşır. Range sınırı metadata üzerinden hızlı bulunmalıdır. Çok geniş range yine çok shard'a yayılabilir.

Data Locality

Benzer key değerleri fiziksel olarak aynı shard üzerinde tutulur. Bu özellik related scan işlemlerinde cache ve I/O locality sağlayabilir. Domain access pattern range tabanlıysa güçlü avantajdır. Hot spot riskini beraberinde getirir. Locality ve load balance birlikte ölçülmelidir.

Hot Range Riski

Yeni kayıtlar sürekli en yüksek range'e gidiyorsa tek shard write ceiling'e ulaşır. Bu sorun time-series uygulamalarda sık görülür. Active range split edilmelidir. Hash suffix veya birden fazla current shard kullanılabilir. Yalnızca storage dağılımına bakmak bu sorunu gizleyebilir.

Consistent Hashing

Consistent hashing node eklenip çıkarıldığında key'lerin tamamını yeniden dağıtmadan mapping güncellemeyi amaçlar. Hash ring üzerinde node ve key pozisyonları temsil edilir. Virtual node kullanımı dağılımı daha dengeli yapabilir. Remapping miktarı klasik modulo yaklaşımına göre azalır. Ancak taşınması gereken gerçek verinin network ve disk maliyeti yine devam eder.

Hash Ring

Key hash değerleri dairesel bir uzaya yerleştirilir. Her key ring üzerinde sonraki sorumlu node'a atanabilir. Node eklendiğinde yalnızca belirli aralıkların ownership'i değişir. Mapping deterministic tutulmalıdır. Router aynı ring bilgisini kullanmalıdır.

Node Ekleme/Çıkarma

Yeni node ring'e eklendiğinde komşu node'lardan belirli key aralıklarını alır. Node çıkarıldığında ownership sonraki node'a geçer. Metadata güncellemesi tüm router'lara ulaşmalıdır. Data migration tamamlanmadan route değiştirmek risklidir. Transition state açık biçimde modellenmelidir.

Minimum Key Remapping

Consistent hashing hedefi topology değişikliğinde daha az key'in yer değiştirmesidir. Bu durum online rebalancing maliyetini azaltır. "Minimum" gerçek workload'a göre değişir. Virtual node sayısı dağılımı etkiler. Data copy kapasitesi yine planlanmalıdır.

Virtual Nodes

Her fiziksel node ring üzerinde birden fazla virtual position taşıyabilir. Bu yöntem data ve load distribution'ı iyileştirir. Farklı kapasitedeki node'lara daha fazla virtual node atanabilir. Metadata boyutu artar. Rebalancing daha küçük parçalar halinde yapılabilir.

Rebalancing

Node eklenirken veya çıkarılırken key range'leri yeniden dağıtılır. Rebalancing production trafiğiyle aynı disk ve network kaynaklarını kullanabilir. Hız sınırı uygulanmalıdır. Source ve target veri doğruluğu kontrol edilmelidir. İşlem sırasında read/write availability korunmalıdır.

Gerçek Veri Taşıma Maliyetinin Devam Etmesi

Consistent hashing yalnızca kaç key'in hedefinin değiştiğini azaltır. Değişen key'lerin gerçek verisi yine taşınmalıdır. Büyük dataset terabaytlarca network transferi oluşturabilir. Rebalancing süresi kapasite planına dahil edilmelidir. Migration sırasında headroom bırakılmalıdır.

Directory-Based Sharding

Directory-based sharding hangi key veya tenant'ın hangi shard'da olduğunu ayrı shard map üzerinden tutar. Bu yöntem fiziksel placement kararını hash formülünden bağımsız hale getirir. Tenant kolayca başka shard'a taşınabilir. Router mapping'i cache edebilir. Directory sisteminin yüksek erişilebilir olması gerekir çünkü tüm routing bu bilgiye dayanır.

Shard Map

Shard map logical key ile fiziksel shard arasındaki eşleşmeyi tutar. Tenant ID → shard 12 örneği buna uygundur. Mapping versionlanabilir. Migration sırasında source ve target state birlikte tutulabilir. Shard map backup ve recovery planına dahil edilmelidir.

Lookup Service

Router mapping'i merkezi lookup service üzerinden öğrenebilir. Service yüksek availability ve düşük latency sağlamalıdır. Her query için remote lookup pahalı olabilir. Local cache kullanımı yaygındır. Cache invalidation topology değişikliğinde dikkat gerektirir.

Flexible Placement

Hash formülüne bağlı olmadığımız için belirli tenant istenen shard'a atanabilir. Büyük müşteriler dedicated node'a taşınabilir. Region veya compliance gereksinimi placement'a eklenebilir. Kapasite-aware scheduler otomatik karar verebilir. Mapping sistemi daha fazla operasyon yükü getirir.

Tenant Move

Tenant başka shard'a taşınırken mapping geçişi kontrollü yapılır. Initial copy, CDC ve cutover kullanılabilir. Router kısa süre dual-read veya migration-aware olabilir. Write source of truth açık tutulmalıdır. Rollback yolu baştan hazırlanmalıdır.

Router Cache

Shard map her request'te merkezi servisten okunmamalıdır. Router local cache kullanabilir. Version veya TTL güncellemeleri stale route riskini yönetir. Migration sırasında mapping hızlı invalidate edilmelidir. Yanlış cache eski shard'a write göndermemelidir.

Directory HA Gereksinimi

Directory service tüm cluster için kritik metadata taşır. Tek instance olması yeni global single point of failure yaratır. Replication ve quorum ile korunmalıdır. Backup düzenli alınmalıdır. Recovery testinde shard map'in doğru restore edildiği doğrulanmalıdır.

Geographic Sharding

Geographic sharding veriyi kullanıcı veya business region'ına göre farklı shard gruplarında tutar. Latency ve data residency açısından güçlü avantaj sağlar. Avrupa, Türkiye ve ABD kullanıcıları kendi region'larında barındırılabilir. Global kullanıcı veya cross-region entity sorguları daha zor hale gelir. Disaster recovery için region dışı replica politikası regülasyonla birlikte düşünülmelidir.

Avrupa Kullanıcıları

Avrupa kullanıcı verisi Avrupa region shard'larında tutulabilir. Bu yaklaşım düşük read/write latency sağlar. Residency kuralları backup placement'ı da etkileyebilir. Global servislerin hangi metadata'ya erişebileceği belirlenmelidir. Kullanıcı region değiştirirse migration politikası gerekir.

Türkiye Kullanıcıları

Türkiye kullanıcıları ayrı regional shard grubuna atanabilir. Uygulama route kararını user home region üzerinden verebilir. Local read ve write network gecikmesini azaltır. Başka region'daki ortak servisler minimum metadata kullanmalıdır. Data residency sözleşmeleri storage ve log sistemlerini de kapsamalıdır.

ABD Kullanıcıları

ABD kullanıcıları coğrafi olarak yakın shard'larda tutulabilir. Büyük ülke içinde birden fazla region gerekebilir. Locality kullanıcı latency'sini düşürür. Global hesapların hangi region'a ait olduğu net belirlenmelidir. Multi-region failover veri kopyalama politikasıyla uyumlu olmalıdır.

Latency

Local region database round-trip'i uzak kıta erişimine göre çok daha düşüktür. Geographic sharding özellikle write latency'yi iyileştirebilir. Cross-region query aynı avantajı kaybeder. Router kullanıcıyı doğru home region'a göndermelidir. Region failover sırasında geçici latency artışı kabul edilebilir olabilir.

Data Residency

Bazı veri türlerinin ülke veya bölge dışına çıkmaması gerekebilir. Shard placement bu kuralı enforcement seviyesine taşır. Replica ve backup da aynı sınırları izlemelidir. Monitoring logları bile hassas veri içerebilir. Compliance tasarımı yalnızca primary storage'ı kapsamamalıdır.

Multi-Region Disaster Recovery

Region kaybı için başka bölgede replica tutulabilir. Residency kısıtı varsa hangi verinin nereye kopyalanabileceği sınırlandırılabilir. Active-passive veya active-active model seçilebilir. Cross-region replication RPO'yu belirler. DR tatbikatı gerçek trafik cutover'ını içermelidir.

Tenant-Based Sharding

Tenant-based sharding SaaS sistemlerinde güçlü locality ve operasyon avantajı sağlayabilir. Aynı tenant'a ait veriler çoğunlukla tek shard üzerinde tutulur. Küçük tenant'lar shared shard'larda, büyük enterprise müşteriler dedicated shard'larda çalışabilir. Noisy neighbor etkisi böylece azaltılır. Tenant'ın shard'lar arasında taşınabilmesi mimarinin temel yeteneği olmalıdır.

SaaS Multi-Tenant Architecture

SaaS uygulamasında tenant çoğu query'nin doğal filtre alanıdır. Bu nedenle tenant ID güçlü shard key adayı olabilir. Cross-tenant analytics ayrı sistemde yürütülebilir. Tenant büyüklüğü çok farklıysa yalnızca tenant key yeterli olmayabilir. Büyük müşteriler için ikinci seviye dağıtım gerekebilir.

Shared Shards

Çok sayıda küçük tenant aynı shard üzerinde tutulabilir. Kaynak verimliliği yüksek olur. Placement sistemi shard kapasitesini takip etmelidir. Bir tenant büyüdüğünde diğerlerini etkilemeden taşınabilmelidir. Shared shard başına tenant sayısı sadece sabit sayı üzerinden belirlenmemelidir.

Dedicated Enterprise Shard

Büyük müşteri kendi shard veya shard grubunda çalışabilir. Bu izolasyon performans ve compliance avantajı sağlar. Özel backup veya maintenance politikası uygulanabilir. Maliyet tenant SLA'sına yansıtılabilir. Uygulama kodu shared ve dedicated placement'ı aynı routing katmanından görmelidir.

Noisy Neighbor

Tek tenant aşırı query veya write üreterek shared shard performansını bozabilir. Per-tenant QPS ve storage metriği bu davranışı görünür hale getirir. Rate limit kısa vadeli koruma sağlar. Uzun vadede tenant dedicated shard'a taşınabilir. Placement otomasyonu bu süreci kolaylaştırır.

Tenant'ın Shard'lar Arasında Taşınması

Tenant move initial data copy ve incremental change capture ile online yapılabilir. Kaynak ve hedef bir süre senkron tutulur. Validation sonrası router mapping hedef shard'a alınır. Rollback süresi boyunca reverse replication tutulabilir. Move operasyonu düzenli test edilen standart süreç olmalıdır.

Composite Shard Key Nedir?

Composite shard key birden fazla alanı birlikte kullanarak veri placement kararını verir. Bu yaklaşım locality ile load distribution arasındaki dengeyi iyileştirebilir. Tenant + entity veya time bucket + hash sık görülen örneklerdir. Query'nin key bileşenlerini taşıması routing açısından önemlidir. Çok fazla bileşen application kullanımını zorlaştırabilir.

Tenant + Entity

Tenant ID locality sağlarken entity hash büyük tenant'ı alt bölümlere dağıtabilir. Tek tenant birden fazla shard'a yayılabilir. Tenant-wide query birkaç shard'a fan-out yapar. Entity-level query tek shard'a gider. Büyük müşteri ölçeği için faydalı dengedir.

Region + User

Region ilk placement sınırını belirler. User ID aynı region içinde dengeli dağılım sağlar. Data residency korunurken hot regional shard riski azalır. Cross-region user migration daha fazla işlem gerektirir. Global identity metadata ayrı tutulabilir.

Time Bucket + Hash

Zaman bucket sorgu locality'si sağlar. Hash bileşeni aynı zaman dilimindeki write'ları birkaç shard'a dağıtır. Range query bucket içindeki birden fazla hash shard'ını birleştirir. Hot latest range riski azalır. Bucket süresi workload'a göre seçilmelidir.

Locality ile Distribution Dengesi

Tek key bazen güçlü locality ama kötü balance sağlar. Composite key ikinci boyut ekleyerek trafiği dağıtır. Buna karşılık query fan-out artabilir. En iyi tasarım access pattern ağırlıklarıyla test edilmelidir. Mükemmel key yerine kontrollü trade-off aranmalıdır.

Application-Level Sharding

Application-level sharding router mantığının uygulama kodu içinde bulunmasıdır. Uygulama shard key'i alır, shard map'i çözer ve doğru connection pool'u seçer. En yüksek esnekliği sağlar. Bununla birlikte routing code tüm servislerde tekrar edilirse drift ve hata riski artar. Ortak library ve merkezi metadata yönetimi güçlü biçimde önerilir.

Shard Router Kodda

Repository katmanı shard seçimini yapabilir. Business service doğrudan connection detayını bilmez. Router shard key olmadan query çalıştırılmasına izin vermeyebilir. Bu guard scatter-gather hatalarını azaltır. Routing library versionlanmalıdır.

Connection Pool per Shard

Her shard için ayrı connection pool açmak doğal yaklaşımdır. Shard sayısı arttıkça toplam connection hızla büyür. Lazy pool creation veya merkezi proxy gerekebilir. Pool health shard bazında izlenmelidir. Failover sonrası stale connection temizlenmelidir.

Shard Map

Application target shard'ı map üzerinden çözer. Map config dosyası, database veya discovery service içinde tutulabilir. Dynamic resharding için versionlu merkezi kaynak daha uygundur. Local cache latency'yi azaltır. Cache invalidation migration sırasında kritik hale gelir.

Routing Library

Ortak routing library tüm servislerde aynı shard seçme kuralını uygular. Retry, primary/replica seçimi ve topology refresh tek yerde yönetilebilir. Library update kontrollü rollout gerektirir. Eski ve yeni versiyon migration sırasında uyumlu olmalıdır. Observability hook'ları library içine eklenebilir.

Uygulama Karmaşıklığı

Application-level model geliştiriciye fazla kontrol verir. Bunun karşılığında her query shard context taşımak zorundadır. Background job ve event consumer da aynı routing bilgisine ihtiyaç duyar. Hata ayıklama shard ID olmadan zorlaşır. Log ve trace metadata'sı shard bilgisini içermelidir.

Proxy/Middleware ile Sharding

Proxy tabanlı sharding application'dan topology ve bazı routing ayrıntılarını gizlemeyi amaçlar. Query proxy'ye gider ve hedef shard burada seçilir. Bu yaklaşım migration ve resharding süreçlerini merkezi hale getirebilir. Proxy kendi yüksek erişilebilirlik ve kapasite planına ihtiyaç duyar. Uygulamanın cross-shard semantiğini tamamen görmezden gelmesi yine mümkün değildir.

Uygulamadan Sharding'i Gizlemek

Application tek logical endpoint kullanabilir. Proxy shard key veya query yapısından target node'u belirler. Kod değişikliği azaltılabilir. Ancak transaction ve global constraint gibi sınırlar hâlâ mevcuttur. Şeffaflık fiziksel dağıtım maliyetini ortadan kaldırmaz.

Query Routing

Proxy query içindeki key bilgisine göre shard seçebilir. Parametre formatları ve prepared statement davranışı desteklenmelidir. Key yoksa scatter-gather yapılabilir veya query reddedilebilir. Kritik path'te implicit fan-out tehlikelidir. Query plan visibility sağlanmalıdır.

Topology Discovery

Proxy shard ve replica durumunu merkezi metadata üzerinden öğrenir. Failover sırasında yeni primary hızlı biçimde bulunmalıdır. Topology refresh periyodik veya event-driven olabilir. Stale metadata yanlış route oluşturur. Quorum veya managed control plane kullanılabilir.

Vitess Benzeri Yaklaşım

Vitess benzeri sistemler MySQL sharding, routing ve resharding işlemlerini altyapı katmanına taşır. Uygulama SQL kullanmaya devam ederken topology yönetimi merkezi hale gelir. Vindex gibi kavramlar shard mapping sağlar. Tüm SQL özellikleri aynı maliyetle çalışmayabilir. Ürünün transaction ve query sınırları application gereksinimiyle karşılaştırılmalıdır.

Proxy'nin HA Gereksinimi

Proxy tek instance olursa tüm database erişimi için yeni single point of failure oluşturur. Birden fazla stateless proxy instance çalıştırılmalıdır. Metadata cache tutarlı biçimde yenilenmelidir. Load balancer proxy fleet'i dağıtabilir. Proxy latency ve error rate ayrıca izlenmelidir.

Sharding + Replication Nasıl Birlikte Kullanılır?

Production sharded sistemlerde her shard genellikle kendi replication grubuna sahiptir. Sharding write ve storage kapasitesini dağıtırken replication read scaling ve high availability sağlar. Router önce doğru shard'ı, ardından o shard içindeki primary veya uygun replica'yı seçer. Böylece iki farklı dağıtım seviyesi oluşur. Veritabanı Mimarisinde Ölçeklenebilirlik: Sharding ve Replication yaklaşımının temel gücü bu iki mekanizmanın birlikte doğru sınırlarla kullanılmasından gelir.

Shard 1 Primary

Shard 1 belirli key aralığının write leader'ıdır. Tüm ilgili write işlemleri bu primary'ye gider. Primary transaction log üretir. Replica'lar bu değişiklikleri takip eder. Shard 1 failure diğer shard'ların write kapasitesini doğrudan etkilememelidir.

Replica 1A

Replica 1A Shard 1 primary değişikliklerini uygular. Read trafiğinin bir bölümünü taşıyabilir. Lag threshold sürekli izlenmelidir. Primary failure durumunda promotion adayı olabilir. Ağır analytics workload ile aşırı yüklenmemelidir.

Replica 1B

Replica 1B ikinci high availability veya read capacity kopyası olabilir. Farklı availability zone'a yerleştirmek failure isolation sağlar. Sync veya async mode business RPO'ya göre seçilir. Promotion priority tanımlanabilir. Backup bazı durumlarda bu replica üzerinden alınabilir.

Shard 2 Primary

Shard 2 farklı key bölümünün write leader'ıdır. Shard 1 ile bağımsız kapasite sunar. Router shard key'e göre trafiği buraya gönderir. Cross-shard transaction gerekiyorsa coordination oluşur. Per-shard metrikler global dashboard'da birlikte izlenmelidir.

Replica 2A

Replica 2A Shard 2 read ve HA ihtiyacını destekler. Lag ve apply rate bağımsız ölçülür. Shard 2 hot hale gelirse replica read kapasitesi rahatlama sağlayabilir. Write bottleneck primary'de kalır. Shard split gerekebilir.

Replica 2B

Replica 2B ek redundancy sağlar. Zone veya region placement failure hedeflerine göre belirlenir. Failover testi shard bazında yapılmalıdır. Replica promotion sonrası topology router'a hızlı aktarılmalıdır. Eski primary fencing uygulanmalıdır.

Router Önce Shard'ı Seçer

Request shard key ile geldiğinde router logical target shard'ı belirler. Hash, range veya directory map kullanılabilir. Bu seçim veri placement seviyesidir. Yanlış shard seçimi verinin bulunamamasına veya duplicate write'a yol açabilir. Routing version migration sırasında önemlidir.

Ardından Primary veya Replica'yı Seçer

Shard belirlendikten sonra query'nin read veya write yapısı değerlendirilir. Write primary'ye gider. Stale-tolerant read sağlıklı replica'ya yönlenebilir. Read-after-write primary route gerektirebilir. Lag-aware health bu ikinci kararın parçasıdır.

Write Scaling + Read Scaling + HA

Sharding birden fazla primary üzerinden write kapasitesini artırır. Replica'lar read trafiğini dağıtır. Her shard içinde failover high availability sağlar. Bu kombinasyon yüksek trafikli sistemlerde güçlüdür. Operasyon otomasyonu olmadan yönetim maliyeti hızla büyür.

Cross-Shard Query Nedir?

Cross-shard query aynı mantıksal sorgunun birden fazla shard'a erişmesini gerektirir. Shard key bulunmayan global arama veya rapor buna örnektir. Router sorguyu fan-out eder ve sonuçları fan-in aşamasında birleştirir. En yavaş shard toplam latency'yi etkileyebilir. Shard sayısı arttıkça scatter-gather maliyeti belirgin hale gelir.

Tek Shard Query

Shard key biliniyorsa query doğrudan tek shard'a gönderilir. Network ve coordination maliyeti düşüktür. Transaction local kalır. Index planı normal database gibi çalışır. Sharding tasarımının hedefi kritik OLTP sorgularının çoğunu bu kategoriye taşımaktır.

Multi-Shard Query

Query birden fazla shard'dan veri ister. Global user search veya tenant dışı reporting buna örnek olabilir. Her shard kendi local sonucu üretir. Router sonuçları birleştirir. Error handling partial shard failure'ı yönetmelidir.

Scatter-Gather

Scatter aşamasında query ilgili veya tüm shard'lara dağıtılır. Gather aşamasında cevaplar merkezi noktada toplanır. Parallel fan-out latency'yi azaltabilir. Ancak connection ve CPU yükünü shard sayısıyla çarpabilir. Limit ve timeout uygulanmalıdır.

Fan-Out

Router tek request'i birden fazla backend query'ye dönüştürür. Yüz shard varsa tek kullanıcı sorgusu yüz database request üretebilir. Bu amplification kapasite planında hesaba katılmalıdır. Query rate limiting gerekebilir. Analytics workload ayrı sistemde daha verimli olabilir.

Fan-In

Shard sonuçları router veya uygulama katmanında birleştirilir. Aggregation, sort veya pagination ek CPU ve memory tüketir. Büyük sonuç setleri merkezi node'u bottleneck yapabilir. Partial aggregation shard tarafında yapılmalıdır. Streaming merge bazı senaryolarda memory kullanımını azaltır.

Latency Amplification

Parallel query'nin tamamlanması çoğu zaman en yavaş shard'a bağlıdır. Shard sayısı arttıkça bir yavaş node ile karşılaşma olasılığı yükselir. P99 tail latency bu nedenle büyüyebilir. Timeout ve partial response politikası business ihtiyacına göre belirlenmelidir. Global query'ler üretim OLTP yolundan ayrılabilir.

Cross-Shard JOIN Neden Zordur?

JOIN işlemi farklı shard'larda bulunan tabloları birleştirmek zorunda kaldığında network transfer ve distributed planning gerektirir. Database engine tek node memory ve index locality avantajını kaybeder. Büyük tablolar arası distributed join pahalı olabilir. Related data'yı aynı shard'a yerleştirmek en iyi önlemdir. Gerektiğinde denormalization veya analytics sistemi kullanılabilir.

Verinin Farklı Node'larda Bulunması

Join edilen iki kayıt farklı node'larda olabilir. Bir node diğerindeki veriye doğrudan local index üzerinden erişemez. Veri network üzerinden taşınır veya iki tarafta partial işlem yapılır. Bu maliyet veri büyüklüğüyle artar. Shard key co-location bu problemi azaltır.

Network Transfer

Distributed join ara sonuçları network üzerinden taşıyabilir. Büyük dataset bandwidth tüketir. Serialization ve deserialization CPU maliyeti ekler. Cross-region shard'larda latency daha da yükselir. Query planner transfer miktarını minimum tutmalıdır.

Distributed Join

Distributed join birkaç execution plan seçeneği gerektirir. Küçük tablo broadcast edilebilir veya iki taraf repartition edilebilir. Her yöntem farklı network ve memory maliyetine sahiptir. OLTP request içinde pahalı plan risklidir. Analytics engine bu tür join'lerde daha uygun olabilir.

Query Planner Karmaşıklığı

Planner farklı node istatistiklerini ve data distribution'ı bilmelidir. Cardinality tahmini yanlışsa pahalı plan seçilebilir. Shard sayısı plan alanını büyütür. Native distributed database bu işi kendi engine'inde yönetebilir. Manual sharding kullanan uygulamada join çoğu zaman application seviyesine taşınır.

Data Co-Location

İlişkili kayıtları aynı shard'a yerleştirmek local join avantajını korur. Tenant-based sharding bu nedenle SaaS sistemlerinde güçlüdür. Order ve order items aynı tenant veya order key üzerinden co-locate edilebilir. Global relation ayrı reference data olabilir. Co-location shard key tasarımının temel hedeflerinden biridir.

Cross-Shard Query Nasıl Azaltılır?

Cross-shard query azaltmanın en etkili yolu shard key'i gerçek access pattern'e göre seçmektir. Related data aynı shard üzerinde tutulmalıdır. Küçük global reference tablolar kopyalanabilir. Denormalization ve materialized view sık global sorguları hızlandırabilir. Büyük analytics workload ayrı search veya warehouse sistemine offload edilebilir.

Shard Key'i Access Pattern'e Göre Seçmek

Hangi sorguların en sık ve en latency duyarlı olduğu ölçülmelidir. Key bu sorguların doğal filtresinde bulunmalıdır. Sadece veri dağılımı güzel olduğu için key seçilmemelidir. Query heatmap kullanışlıdır. Gelecekteki feature planı da analize eklenmelidir.

Related Data'yı Co-Locate Etmek

Aynı transaction veya join içinde kullanılan data mümkün olduğunca aynı shard'da tutulmalıdır. Tenant ID veya aggregate ID bunun için kullanılabilir. Local transaction ACID semantiğini korur. Global relation ayrı model gerektirir. Domain sınırları data placement'a yardım eder.

Reference Table

Küçük ve nadiren değişen reference data her shard'a kopyalanabilir. Country code veya product category gibi tablolar örnek olabilir. Local join yapılır. Güncelleme propagation mekanizması gerekir. Version drift izlenmelidir.

Denormalization

Sık kullanılan bazı alanlar join'i önlemek için kayıt içine kopyalanabilir. Read hızlı olur. Write sırasında birden fazla kopyayı güncel tutma maliyeti oluşur. Eventual consistency kabul edilebilir olabilir. Kaynak alanın ownership'i açık olmalıdır.

Materialized View

Global veya cross-shard sonucu önceden hesaplayan materialized view kullanılabilir. Query anında fan-out yerine hazır veri okunur. Refresh latency veri tazeliğini belirler. Incremental update event stream ile yapılabilir. View source of truth değildir.

Search/Analytics Sistemine Offload

Global search veya ağır aggregation ayrı sistemde daha doğal çalışabilir. OLTP shard'ları yalnızca transactional access pattern'e odaklanır. CDC event'leri search index veya warehouse'a veri taşır. Eventual consistency kullanıcıya açıklanmalıdır. Bu ayrım database cluster üzerindeki fan-out yükünü azaltır.

Global Aggregation Sharded Database'te Nasıl Yapılır?

Global aggregation tüm shard'lardaki verinin özetlenmesini gerektirir. Her shard kendi partial aggregation sonucunu üretebilir. Merkezi fan-in bu küçük sonuçları birleştirir. Sık kullanılan raporlar önceden hesaplanabilir. Çok büyük analytics ihtiyacında ayrı warehouse genellikle daha ölçeklenebilir olur.

Per-Shard Partial Aggregation

SUM, COUNT veya GROUP BY önce her shard'da local çalıştırılabilir. Ham verinin tamamı network üzerinden taşınmaz. Sonuçlar çok daha küçüktür. Coordinator final merge yapar. Shard failure partial sonuç semantiğini etkiler.

Fan-In

Coordinator shard'lardan gelen partial sonuçları toplar. Basit SUM kolayca birleştirilir. Distinct count veya percentile daha özel algoritma gerektirebilir. Coordinator memory limiti korunmalıdır. Büyük result stream edilebilir.

Precomputed Aggregate

Sık gösterilen metrikler write veya event pipeline sırasında önceden hesaplanabilir. Dashboard request'i hızlı olur. Update lag kabul edilmelidir. Counter idempotency önemli hale gelir. Per-shard aggregate global seviyede yeniden birleştirilebilir.

Streaming Pipeline

Database değişiklikleri CDC ile event stream'e aktarılabilir. Stream processor incremental aggregate üretir. OLTP shard'lara ağır scan yükü gelmez. Rebuild için replay imkanı bulunabilir. Schema evolution pipeline tarafından desteklenmelidir.

Analytics Warehouse

Global rapor ve ad-hoc query için warehouse daha uygun olabilir. Shard data periyodik veya streaming yöntemle buraya taşınır. Columnar storage geniş scan'de avantaj sağlar. OLTP consistency yerine analytics freshness hedeflenir. Veri governance ayrı planlanmalıdır.

Global Pagination Neden Zordur?

Global pagination farklı shard'lardan sıralı sonuç üretmeyi gerektirir. Offset pagination her shard'da büyük scan ve merge maliyeti yaratabilir. Cursor pagination daha iyi olsa da shard başına state tutmak gerekebilir. Global sort tüm shard'lardan candidate sonuç ister. Merge-sort algoritması coordinator üzerinde ek çalışma oluşturur.

Offset Pagination

OFFSET 100000 gibi sorgu tek database'de bile pahalı olabilir. Sharded sistemde her shard yeterince kayıt taramak zorunda kalabilir. Sonuçlar birleştirilip ilk büyük bölüm atılır. Bu yaklaşım shard sayısıyla kötü ölçeklenir. Cursor pagination tercih edilmelidir.

Cursor Pagination

Cursor son görülen sort key'i taşır. Sonraki query bu noktadan devam eder. Sharded sistemde global cursor shard durumunu da içerebilir. Stable ordering gereklidir. Veri değişirken duplicate veya missing item davranışı düşünülmelidir.

Shard Başına Cursor

Her shard kendi son pozisyonunu tutabilir. Global cursor bu state'leri serialize eder. Cursor boyutu shard sayısıyla büyüyebilir. Client tarafından değiştirilmemesi için imzalanabilir. Versioning topology değişikliğinde önem kazanır.

Global Sort

Her shard local sorted candidate listesi üretir. Coordinator bu listeleri global sıraya koyar. Gerekenden fazla row taşınmamalıdır. Sort key shard key ile ilişkiliyse işlem daha kolay olabilir. Cross-region shard'lar latency ekler.

Merge-Sort

Sorted shard stream'leri heap benzeri yapı ile birleştirilebilir. Coordinator yalnızca her stream'in başını tutar. Bu memory kullanımını sınırlar. Slow shard tüm sayfanın tamamlanmasını geciktirebilir. Timeout ve partial behavior ürün gereksinimine göre belirlenmelidir.

Distributed Secondary Index Nasıl Yönetilir?

Shard key dışında bir alan üzerinden hızlı arama gerektiğinde secondary index problemi ortaya çıkar. Local secondary index yalnızca shard içindeki veriyi kapsar. Global secondary index key'den target shard mapping'i tutabilir. Bu yapı write amplification ve eventual consistency maliyeti getirir. Query pattern gerçekten gerekliyse index stratejisi açık biçimde tasarlanmalıdır.

Local Secondary Index

Her shard kendi satırları için normal secondary index tutar. Shard key query'de biliniyorsa hedef shard içinde hızlı lookup yapılır. Shard bilinmiyorsa tüm shard'lar sorgulanabilir. Global uniqueness sağlamaz. Maintenance local transaction içinde kolaydır.

Global Secondary Index

Global index belirli secondary key ile record'un shard konumunu eşler. Query önce index servisinden target bulur. Index ayrı distributed system olabilir. Write sırasında base table ve index birlikte güncellenmelidir. Tutarsızlık riskine karşı reconciliation gerekir.

Index → Shard Mapping

Index entry record ID ve shard ID taşıyabilir. Router doğrudan target shard'a gider. Record taşındığında mapping güncellenmelidir. Stale mapping redirect veya retry gerektirir. Cache invalidation migration sırasında önemlidir.

Write Amplification

Her base table write ek index write oluşturur. Birden fazla global index write throughput'u düşürebilir. Distributed transaction kullanılıyorsa latency artar. Async index update eventual consistency sağlar. Sadece gerçekten gereken index'ler tutulmalıdır.

Eventual Consistency

Global index async event ile güncelleniyorsa kısa süre yeni kayıt bulunamayabilir. Delete sonrası stale index entry eski shard'a işaret edebilir. Application retry veya validation yapmalıdır. Kullanıcı deneyimi bu pencereye dayanıklı olmalıdır. Kritik lookup güçlü consistency gerektirebilir.

Global Unique ID Nasıl Üretilir?

Sharded sistemde tek database auto increment mekanizmasına güvenmek zorlaşır. Her shard bağımsız ID üretirse collision önlenmelidir. UUID, ULID veya Snowflake-style ID dağıtık üretim sağlar. Bazı sistemler shard ID bilgisini ID içine koyar. ID formatı ordering, storage ve index davranışını etkiler.

Auto Increment Problemi

Tek merkezi sequence global uniqueness sağlar fakat write bottleneck yaratabilir. Shard başına sequence collision oluşturabilir. Offset veya step ile ayrım yapılabilir. Merkezi ID service ek bağımlılık getirir. Dağıtık ID çoğu zaman daha esnektir.

UUID

UUID merkezi koordinasyon olmadan büyük uniqueness alanı sunar. Random UUID index locality'sini bozabilir. String saklamak binary formdan daha fazla alan kullanabilir. Uygulama ve database tipi dikkatle seçilmelidir. Zaman sıralı alternatifler bazı workload'larda daha iyi olabilir.

ULID

ULID zaman bileşeni ve random bölüm içerir. Sıralanabilir olması bazı indekslerde avantaj sağlayabilir. Aynı milisaniyede uniqueness random alana bağlıdır. String formatı okunabilirlik sağlar. Security açısından timestamp bilgisi sızabilir.

Snowflake-Style ID

Snowflake tarzı ID timestamp, worker veya shard ve sequence bileşenleri kullanır. Merkezi database sequence olmadan sıralı benzersiz ID üretilebilir. Worker ID koordinasyonu gerekir. Clock regression yönetilmelidir. Bit dağılımı gelecekteki kapasiteye göre seçilmelidir.

Shard ID İçeren ID

ID içine shard bilgisi koymak routing'i kolaylaştırabilir. Record ID tek başına hedef shard'ı gösterir. Resharding sırasında eski shard bit'i problem yaratabilir. Logical shard ID fiziksel node'dan ayrılmalıdır. Format public API'ye sızarsa değiştirmek zorlaşır.

Unique Constraint Sharded Database'te Nasıl Uygulanır?

Unique constraint tek shard içinde database tarafından kolayca uygulanabilir. Global uniqueness farklı shard'ların aynı değeri üretmesini engellemek gerektiğinde zorlaşır. Merkezi registry veya global index kullanılabilir. Alternatif olarak unique key'e shard key dahil edilerek uniqueness scope daraltılır. Requirement gerçekten global değilse gereksiz distributed coordination önlenebilir.

Shard-Local Uniqueness

Tenant içindeki username gibi constraint tenant shard'ında local olabilir. Database normal unique index kullanır. Cross-shard coordination gerekmez. Shard key constraint'e dahil edilir. SaaS sistemlerinde çoğu requirement bu şekilde modellenebilir.

Global Uniqueness

E-posta tüm sistemde tekil olacaksa farklı shard'lar arasında coordination gerekir. Central registry bu değerin owner'ını tutabilir. Distributed transaction veya idempotent reservation uygulanabilir. Registry high availability gerektirir. Business gerçekten global uniqueness istiyor mu yeniden sorgulanmalıdır.

Merkezi Registry

Unique key önce merkezi küçük database veya service üzerinde reserve edilir. Başarılı reservation sonrası target shard write yapılır. İki adım arasında failure varsa cleanup gerekir. Transactional workflow idempotent olmalıdır. Registry throughput global write kapasitesini sınırlayabilir.

Shard Key'i Unique Key'e Dahil Etmek

Unique index tenant_id + email şeklinde tanımlanabilir. Böylece uniqueness tenant sınırında kalır. Tüm sistemde aynı email farklı tenant'larda kullanılabilir. Cross-shard coordination ortadan kalkar. Domain bunu kabul ediyorsa en basit çözümdür.

Foreign Key'ler Sharding'i Nasıl Etkiler?

Foreign key aynı shard içinde kaldığında normal relational integrity avantajı korunabilir. Cross-shard relation database tarafından tek transaction içinde doğrulanamayabilir. Application-level integrity veya eventual referential checks gerekebilir. Bu nedenle ilişkili aggregate'ları aynı shard'a yerleştirmek önemlidir. Sharding domain sınırlarını veri modelinde daha görünür hale getirir.

Same-Shard Foreign Key

Parent ve child aynı shard'daysa database foreign key uygulayabilir. Transaction local kalır. Delete ve cascade davranışı normal relational model gibi çalışır. Shard key related tabloların aynı placement'ını sağlamalıdır. Tenant ID çoğu zaman buna yardımcı olur.

Cross-Shard Foreign Key

Parent başka shard'da ise local database referansı doğrulayamaz. Her write remote query yaparsa latency ve availability bağımlılığı oluşur. Global transaction gerekebilir. Bu nedenle cross-shard FK genellikle kaçınılır. Domain event ile eventual validation kullanılabilir.

Application-Level Integrity

Uygulama relation'ın varlığını service veya registry üzerinden doğrulayabilir. Network failure nedeniyle check ve write arasında race oluşabilir. Immutable ID ve soft delete modeli bazı riskleri azaltır. Background reconciliation orphan kayıtları bulabilir. Strong guarantee gerekiyorsa data co-location daha doğru olabilir.

Eventual Referential Integrity

Referential consistency kısa süre gecikmeli kabul edilebilir. Event consumer relation değişikliklerini takip eder. Orphan kayıtlar belirli süre sonra düzeltilir veya quarantine edilir. Kullanıcıya kritik olmayan metadata için uygun olabilir. Finansal relation gibi alanlarda yeterli olmayabilir.

Cross-Shard Transaction Nedir?

Cross-shard transaction tek business işleminin birden fazla shard'a atomik write yapmasını gerektirir. Network ve node failure nedeniyle tüm katılımcıların aynı sonucu görmesi zorlaşır. Partial commit ciddi consistency problemi yaratabilir. Two-phase commit strong atomicity sağlayabilir ama latency ve blocking maliyeti getirir. Saga ve eventual consistency çoğu business workflow'da alternatif olabilir.

Bir Transaction'ın Birden Fazla Shard'a Yazması

Örneğin iki farklı tenant veya account shard'ı arasında transfer gerekebilir. Her shard kendi local transaction'ını yönetir. Global coordinator iki sonucu eşleştirmelidir. Bir shard başarılı diğeri başarısız olursa state parçalanır. Business model mümkünse operation'ı tek shard'a co-locate etmelidir.

Atomicity Problemi

Local database ACID transaction tek shard içinde güçlüdür. Birden fazla bağımsız database aynı commit noktasını doğal olarak paylaşmaz. Coordinator ek protokol uygulamalıdır. Failure anında belirsiz state oluşabilir. Distributed transaction requirement mümkün olduğunca azaltılmalıdır.

Network Failure

Coordinator commit mesajını bazı shard'lara ulaştırıp diğerlerine ulaştıramayabilir. Timeout sonucu gerçek state bilinmeyebilir. Retry idempotent olmalıdır. Participant transaction state kalıcı tutulmalıdır. Recovery protocol restart sonrası devam edebilmelidir.

Partial Commit

Bir shard write'ı commit ederken diğeri rollback olursa business invariant bozulabilir. Compensation veya 2PC bunu yönetmeye çalışır. Kullanıcıya success dönmeden önce durum netleşmelidir. Eventual workflow'da pending state kullanılabilir. Reconciliation süreçleri önemli hale gelir.

Two-Phase Commit (2PC)

Two-Phase Commit birden fazla participant üzerinde atomic commit sağlamaya çalışan coordination protokolüdür. İlk aşamada katılımcılar prepare edilir. İkinci aşamada coordinator commit veya rollback kararı gönderir. Strong atomicity avantajına karşı latency ve blocking riski vardır. Yüksek trafikli shard sistemlerinde yalnızca gerçekten gereken işlemlerde kullanılmalıdır.

Prepare

Coordinator tüm participant shard'lara transaction'ı commit etmeye hazır olup olmadıklarını sorar. Participant gerekli lock ve state'i tutar. Hazırım cevabı verdikten sonra karar bekler. Bu durum kaynakları bir süre bloke edebilir. Coordinator failure recovery mekanizması gerekir.

Commit

Tüm participant'lar prepare başarılı dönerse coordinator commit kararı verir. Bir participant prepare başarısızsa rollback yapılabilir. Commit mesajı network nedeniyle gecikebilir. Participant karar state'ini durable tutmalıdır. Duplicate mesaj idempotent işlenmelidir.

Coordinator

Coordinator global transaction state'ini yönetir. Tek instance olması availability riski yaratır. Durable log ve failover gerekir. Coordinator recover olduğunda yarım transaction'ları tamamlamalıdır. Monitoring in-doubt transaction sayısını göstermelidir.

Blocking Risk

Participant prepare sonrası coordinator kararını beklerken lock tutabilir. Coordinator uzun süre erişilemezse resource contention oluşur. Bu nedenle 2PC yüksek latency ve failure ortamında pahalıdır. Timeout tek başına doğru karar veremez. Consensus tabanlı distributed database'ler farklı internal mekanizmalar kullanabilir.

Latency

En az iki coordination fazı network round-trip ekler. Cross-region participant'larda latency daha da yükselir. P99 transaction süresi kullanıcı deneyimini etkileyebilir. Local transaction her zaman daha ucuzdur. Data co-location bu yüzden değerlidir.

Ne Zaman Gerekli?

Business invariant kesin atomicity gerektiriyorsa 2PC değerlendirilebilir. Finansal veya kritik inventory senaryoları buna yaklaşabilir. Saga ile compensation kabul edilemiyorsa güçlü transaction gerekebilir. Kullandığınız database'in native distributed transaction desteği varsa uygulama yükü azalabilir. Karar failure ve latency testleriyle doğrulanmalıdır.

Saga Pattern ile Distributed Transaction

Saga uzun business işlemini birden fazla local transaction'a böler. Her adım başarılı oldukça sonraki aşama çalışır. Hata durumunda önceki adımlar compensating transaction ile geri alınmaya çalışılır. Strong instantaneous atomicity yerine eventual consistency kabul edilir. Uzun süreli business workflow'larda 2PC'ye göre daha esnek olabilir.

Local Transactions

Her service veya shard kendi local ACID transaction'ını tamamlar. Global lock tutulmaz. Adımlar event veya orchestrator ile bağlanır. Her adım idempotent olmalıdır. İşlem state'i durable tutulmalıdır.

Orchestration

Merkezi orchestrator hangi adımın sırada olduğunu yönetir. Başarı ve hata durumlarını state machine içinde takip eder. Debugging daha kolay olabilir. Orchestrator high availability gerektirir. Business workflow açık bir model kazanır.

Choreography

Her service event dinleyip kendi adımını çalıştırır. Merkezi coordinator yoktur. Servis bağımlılıkları event zincirinde gizlenebilir. Büyük workflow'da gözlemlenebilirlik zorlaşabilir. Event sözleşmeleri iyi yönetilmelidir.

Compensating Transaction

Compensation daha önce tamamlanan business adımın etkisini tersine çevirmeye çalışır. Her işlem tamamen geri alınabilir olmayabilir. E-posta gönderimini silmek mümkün değildir. Bu nedenle business compensation semantiği baştan tasarlanmalıdır. Manuel intervention state'i gerekebilir.

Eventual Consistency

Saga sırasında sistem geçici intermediate state taşıyabilir. Kullanıcı pending durumunu görebilir. Tüm adımlar tamamlandığında final consistency oluşur. Monitoring stuck workflow'ları tespit etmelidir. Timeout ve retry politikası her adım için tanımlanmalıdır.

Transactional Outbox ile Sharded Sistemler

Transactional Outbox shard içindeki database write ile event publish arasındaki dual-write sorununu azaltır. Her shard kendi outbox tablosuna business transaction ile birlikte event yazar. CDC veya publisher event'i message broker'a taşır. Consumer duplicate event'e hazır olmalıdır. Sharded sistemde outbox stream'lerinin global ordering beklentisi dikkatle değerlendirilmelidir.

Database Write

Business kayıt ilgili shard'a local transaction ile yazılır. Aynı transaction outbox event'i oluşturur. Böylece database state ile publish niyeti birlikte commit olur. Cross-shard transaction gerekmez. Shard ID event metadata'sına eklenebilir.

Outbox Event

Outbox kaydı event ID, type, payload ve timestamp taşıyabilir. Schema version eklemek faydalıdır. İşlendikten sonra cleanup politikası uygulanır. Büyük payload yerine referans kullanılabilir. Event ordering shard-local olabilir.

CDC

Change Data Capture outbox kayıtlarını transaction log üzerinden okuyabilir. Polling yükü azaltılabilir. CDC connector her shard'ı takip etmelidir. Resharding sırasında source ve target event duplication riski yönetilmelidir. Event ID deduplication sağlar.

Message Broker

CDC veya publisher event'i broker'a gönderir. Consumer farklı servis veya analytics pipeline olabilir. Publish retry duplicate mesaj oluşturabilir. At-least-once semantiği normal kabul edilmelidir. Idempotent consumer gerekir.

Dual-Write Problemini Azaltma

Application aynı anda database ve broker'a bağımsız write yapmaz. Outbox event database transaction içinde kalıcılaşır. Broker geçici kapalı olsa bile event daha sonra gönderilebilir. Bu model event kaybını azaltır. Consumer tarafı yine duplicate'e dayanıklı olmalıdır.

Resharding Nedir?

Resharding mevcut shard dağılımını değiştirerek veriyi yeni shard yapısına taşımaktır. Dataset büyümesi, hot shard veya yeni region ihtiyacı bunu gerektirebilir. Shard split veya merge yapılabilir. Online resharding production trafiğini kesmeden migration hedefler. Başarılı sistemde resharding istisna değil, planlanmış operasyon olarak görülmelidir.

Mevcut Shard Sayısını Değiştirmek

Shard sayısı kapasite ihtiyacına göre artırılabilir veya azaltılabilir. Hash modulo kullanan basit tasarımda büyük data hareketi oluşabilir. Virtual bucket veya directory map değişikliği kolaylaştırır. Routing metadata versionlanmalıdır. Migration sırasında old ve new mapping birlikte desteklenebilir.

Shard Split

Büyük shard iki veya daha fazla parçaya bölünür. Key range veya tenant grupları target shard'lara taşınır. Source değişiklikleri copy sırasında devam eder. CDC catch-up farkı kapatır. Cutover sonrası source cleanup yapılır.

Shard Merge

Çok küçük shard'lar operasyon maliyetini azaltmak için birleştirilebilir. Veriler ortak target'a taşınır. Unique constraint ve key collision kontrol edilmelidir. Routing map güncellenir. Backup ve restore planı yeni topology'ye uyarlanır.

Yeni Shard Eklemek

Cluster'a yeni database node veya shard grubu eklenir. Kapasite boşluğu oluşturur. Mevcut verinin bir bölümü buraya taşınmalıdır. Yeni shard'a yalnızca yeni write göndermek bazı skew problemlerini çözmez. Rebalancing planı gereklidir.

Data Redistribution

Resharding gerçek data copy ve network transferi gerektirir. Migration production I/O ile yarışır. Rate limit uygulanmalıdır. Validation source-target eşitliğini kontrol eder. Transfer sırasında kapasite headroom bırakılmalıdır.

Neden Resharding Gerekir?

Shard dağılımı sistem ömrü boyunca sabit kalmayabilir. Dataset büyür, tenant'lar farklı hızlarda genişler ve yeni region gereksinimleri ortaya çıkar. Başlangıçta doğru olan shard key bile zamanla skew üretebilir. Hardware platformu veya node boyutu değişebilir. Bu yüzden resharding kabiliyeti sharding mimarisinin doğal parçasıdır.

Dataset Büyümesi

Shard başına storage güvenli sınırın üzerine çıkabilir. Backup ve maintenance süreleri uzar. Yeni shard ekleyip data bölmek gerekir. Capacity forecast resharding'i son dakikaya bırakmamalıdır. Migration aylar önceden planlanabilir.

Hot Shard

Bir shard diğerlerinden çok daha fazla QPS veya write alabilir. Bu durumda split yükü dağıtır. Key distribution sorunu devam ediyorsa yalnızca node eklemek yeterli olmayabilir. Composite key veya tenant move gerekir. Root cause analiz edilmelidir.

Yeni Region

Yeni pazara girildiğinde kullanıcı verisi farklı region'da tutulmak istenebilir. Existing tenants belirli kuralla taşınabilir. Global router home region mapping'i günceller. Data residency gereksinimi migration sırasını etkiler. Cross-region CDC güvenli biçimde kurulmalıdır.

Hardware Değişikliği

Eski instance tipi kaldırılabilir veya daha iyi fiyat performanslı platforma geçilebilir. Resharding yeni node grubuna kontrollü migration sağlar. Aynı shard sayısı korunabilir. Shadow traffic performans karşılaştırması yapabilir. Rollback yolu tutulmalıdır.

Shard Key Problemi

Başlangıç key'i yeni access pattern'lerde fazla fan-out üretebilir. Hot key veya skew da oluşabilir. Yeni key'e geçiş full data migration gerektirebilir. Application hem eski hem yeni routing'i belirli süre desteklemelidir. Native resharding özelliği operasyonu kolaylaştırabilir.

Online Resharding Nasıl Yapılır?

Online resharding production trafiği devam ederken veriyi yeni shard yapısına taşır. İlk olarak target shard'lar hazırlanır ve mevcut veri kopyalanır. Ardından copy sırasında oluşan değişiklikler CDC veya replication ile yakalanır. Validation tamamlandıktan sonra read ve write trafik kontrollü biçimde hedefe alınır. Eski shard rollback süresi boyunca korunup daha sonra temizlenir.

Target Shard'ları Oluşturma

Yeni shard'lar schema ve capacity açısından hazırlanır. Replica topolojisi production standardıyla aynı olmalıdır. Migration user'ı ve network erişimi tanımlanır. Monitoring migration başlamadan hazır olmalıdır. Boş target üzerinde benchmark yapılabilir.

Initial Data Copy

Source shard'taki mevcut veri target'a bulk kopyalanır. Copy hızının production workload'u bozmaması gerekir. Snapshot veya consistent scan kullanılabilir. Büyük tablolar chunk halinde taşınır. Progress metriği tutulmalıdır.

Incremental Changes

Initial copy sırasında source üzerinde yeni write'lar devam eder. Bu değişiklikler log veya CDC üzerinden yakalanır. Target'a sıralı ve idempotent biçimde uygulanır. Duplicate event güvenli olmalıdır. Gap detection gerekir.

Replication/Catch-Up

Initial copy tamamlandığında target source'a yetişmeye başlar. Lag giderek küçülmelidir. Catch-up hızı production write hızından düşükse cutover mümkün olmaz. Resource kapasitesi artırılabilir. Lag threshold cutover şartı olarak tanımlanmalıdır.

Validation

Row count, checksum ve sample query ile source-target karşılaştırılır. Critical aggregate değerleri kontrol edilir. Validation yalnızca tek sefer yapılmamalıdır. Cutover öncesi son diff alınır. Hata bulunursa migration durdurulur.

Read Traffic Switch

Önce read trafiğinin küçük yüzdesi target'a gönderilebilir. Shadow read sonucu source ile karşılaştırılabilir. Error ve latency gözlenir. Sorun yoksa oran artırılır. Write source hâlâ eski shard olabilir.

Write Traffic Switch

Target güncel ve doğrulanmış olduğunda write ownership taşınır. Route mapping atomik veya versionlu güncellenmelidir. Stale application instance eski shard'a write göndermemelidir. Fencing token kullanılabilir. Cutover anı ayrıntılı loglanmalıdır.

Old Shard Cleanup

Rollback penceresi bittikten sonra source data silinebilir. Backup son kez alınabilir. Routing map eski entry'lerden temizlenir. Connection pool kapatılır. Capacity yeni shard'lara yeniden dağıtılır.

Zero-Downtime Resharding

Zero-downtime resharding kullanıcı trafiğini kesmeden shard değişikliği yapmayı hedefler. Dual read, dual write veya CDC gibi teknikler geçiş sırasında kullanılabilir. Shadow validation target doğruluğunu üretim request'leriyle karşılaştırır. Traffic cutover kontrollü ve geri alınabilir olmalıdır. Reverse replication rollback süresince ek güvenlik sağlar.

Dual Read

Uygulama aynı query'yi source ve target'a gönderebilir. Kullanıcıya source sonucu dönerken target sonucu karşılaştırılır. Bu yöntem data farkını gerçek request üzerinde görür. İki kat read yükü oluşturur. Belirli trafik yüzdesinde uygulanabilir.

Dual Write

Yeni write hem source hem target'a gönderilebilir. İki write arasında dual-write consistency problemi oluşabilir. Idempotency ve retry gerekir. Transactional log veya CDC çoğu durumda daha güvenlidir. Cutover süresi kısa tutulmalıdır.

CDC

Source transaction log değişiklikleri target'a asenkron taşınır. Application çift write yapmaz. Ordering ve deduplication iyi yönetilmelidir. Resharding key dönüşümü CDC pipeline içinde yapılabilir. Lag sürekli ölçülmelidir.

Shadow Validation

Production query target üzerinde shadow olarak çalıştırılır. Sonuç source ile karşılaştırılır. Fark oranı metric olarak izlenir. Kullanıcı target cevabını görmez. Büyük query maliyeti sampling ile sınırlandırılır.

Traffic Cutover

Router mapping source'tan target'a değiştirilir. Değişiklik versionlu rollout ile yapılabilir. Önce küçük trafik yüzdesi target'a alınabilir. Error rate artarsa rollback tetiklenir. Cutover runbook ve owner belirlenmelidir.

Reverse Replication

Cutover sonrası target write'ları eski source'a ters yönde replike edilebilir. Böylece kısa süre içinde rollback mümkündür. Reverse path ek operasyon yükü getirir. Sonsuza kadar tutulmamalıdır. Rollback penceresi sonunda kapatılır.

Rollback

Target beklenmeyen hata üretirse routing source'a geri alınabilir. Source'un cutover sonrası değişiklikleri almış olması gerekir. Rollback criteria önceden tanımlanmalıdır. İnsan kararına tamamen bırakılmamalıdır. Her migration staging ortamında rollback ile prova edilmelidir.

Resharding Doğrulaması Nasıl Yapılır?

Resharding yalnızca data copy tamamlandı mesajına güvenilerek bitirilmemelidir. Row count, checksum ve sample query sonuçları source ile target arasında karşılaştırılmalıdır. Replication lag sıfıra yakın seviyeye gelmelidir. Cutover sonrası error rate ve query latency izlenmelidir. Veri doğruluğu ile performans birlikte kabul kriteridir.

Row Count

Tablo ve partition bazında row count karşılaştırılabilir. Büyük tabloda exact count pahalı olabilir. Metadata veya sample yöntem kullanılabilir. Count eşitliği tek başına data içeriğinin eşit olduğunu kanıtlamaz. Diğer kontrollerle birlikte kullanılmalıdır.

Checksums

Belirli chunk'ların deterministic checksum değeri hesaplanabilir. Source ve target aynı sonucu vermelidir. Büyük dataset için chunking parallel validation sağlar. Sort order normalize edilmelidir. Mismatch otomatik diff sürecini başlatabilir.

Sample Queries

Gerçek access pattern'lerden seçilen sorgular iki tarafta çalıştırılır. Result ve latency karşılaştırılır. Random sampling yanında high-value tenant örnekleri kullanılmalıdır. Hot key davranışı özellikle test edilmelidir. Query plan farkları incelenmelidir.

Source/Target Diff

Mismatch bulunan key'ler ayrıntılı diff ile karşılaştırılır. Field-level fark loglanabilir. Hassas veri korunmalıdır. Otomatik repair gerektiğinde idempotent olmalıdır. Diff oranı cutover threshold'u aşmamalıdır.

Replication Lag

Target source değişikliklerine ne kadar geriden geliyor ölçülür. Cutover anında kabul edilebilir lag business requirement'a bağlıdır. Write switch sonrası direction değişebilir. Lag metric doğru zaman referansı kullanmalıdır. Stale target'a write ownership verilmemelidir.

Error Rate

Target read veya write shadow testlerinde hata oranı izlenir. Connection, constraint ve schema hataları migration sorunu gösterebilir. Error type breakdown tutulmalıdır. Baseline source değerleriyle karşılaştırılır. Cutover sonrası spike otomatik rollback tetikleyebilir.

Shard Key Sonradan Değiştirilebilir mi?

Shard key sonradan değiştirilebilir ancak genellikle kapsamlı data migration gerektirir. Tüm kayıtların yeni key'e göre yeniden yerleştirilmesi gerekir. Application query'leri de yeni routing bilgisini kullanmalıdır. Online resharding kesintiyi azaltabilir. Native database özellikleri süreci kolaylaştırsa da veri taşıma maliyeti ortadan kalkmaz.

Geleneksel Zorluk

Key record placement'ın temel belirleyicisidir. Değişiklik tüm dataset'in yeni shard mapping'e göre hareket etmesine neden olabilir. Global index ve reference'lar güncellenmelidir. Uzun migration penceresi gerekir. Bu yüzden ilk seçim dikkatli yapılmalıdır.

Full Data Migration

Eski shard'lar taranıp kayıtlar yeni key ile target'lara yazılır. Terabayt dataset uzun sürebilir. CDC migration sırasında write değişikliklerini yakalar. Network ve disk kapasitesi korunmalıdır. Validation olmadan cutover yapılmamalıdır.

Online Resharding

Application trafiği devam ederken copy ve catch-up yapılabilir. Old ve new routing aynı anda desteklenir. Version field query'nin hangi sistemden okunacağını belirleyebilir. Rollback mekanizması tutulur. Migration otomasyonu tekrar kullanılabilir olmalıdır.

Application Query Migration

Yeni shard key query parametrelerinde bulunmayabilir. Application contract zamanla değiştirilmelidir. Önce dual-route abstraction eklenebilir. Client veya service katmanı key'i türetebilir. Legacy query'ler tamamen kaldırılmadan eski mapping korunabilir.

Native Database Resharding Özellikleri

Bazı distributed database'ler online resharding veya automatic rebalancing sunar. Bu özellik uygulama operasyon yükünü azaltabilir. Yine de query pattern ve hot key problemi otomatik çözülmez. Migration sırasında performans etkisi devam eder. Ürün sınırları gerçek workload ile test edilmelidir.

Schema Migration Sharded Database'te Nasıl Yapılır?

Sharded sistemde schema migration tüm shard'larda tutarlı biçimde uygulanmalıdır. Bir shard yeni, diğer shard eski schema'da kalırsa application davranışı değişebilir. Backward-compatible değişiklikler rolling migration için daha güvenlidir. Expand-and-contract deseni version drift riskini azaltır. Migration orchestrator her shard'ın durumunu merkezi dashboard'da göstermelidir.

Tüm Shard'larda DDL

DDL değişikliği shard fleet üzerinde kontrollü yürütülür. Aynı anda tüm node'larda ağır index build yapmak I/O spike oluşturabilir. Batch rollout kullanılabilir. Her shard sonucu kaydedilir. Failure durumunda pipeline durmalıdır.

Version Drift

Bazı shard'lar farklı schema version taşıyabilir. Application her iki sürümle kısa süre uyumlu olmalıdır. Uzun drift risklidir. Drift detection otomatik çalışmalıdır. Beklenmeyen version production alert üretmelidir.

Backward-Compatible Schema

Yeni kolon önce nullable veya default ile eklenebilir. Eski application sürümü çalışmaya devam eder. Yeni code kolon kullanmaya başladıktan sonra data backfill yapılır. Son aşamada eski alan kaldırılır. Bu sıralama zero-downtime migration sağlar.

Expand-and-Contract

Expand aşamasında yeni schema eski kullanım bozulmadan eklenir. Application dual-read veya dual-write yapabilir. Data backfill tamamlanır. Contract aşamasında eski alan kaldırılır. Her adım ayrı deployment olabilir.

Rolling Migration

Shard'lar küçük gruplar halinde yeni schema'ya geçirilir. Performance etkisi kontrollü kalır. Failure yalnızca sınırlı shard grubunu etkiler. Migration health metriği rollout'u otomatik durdurabilir. Canary shard seçilebilir.

Shard'larda Schema Drift Nasıl Önlenir?

Schema drift çok sayıda shard bulunan sistemde ciddi operasyon riskidir. Her shard'ın schema version bilgisi merkezi olarak izlenmelidir. Migration orchestrator aynı değişikliği determinist şekilde çalıştırmalıdır. CI/CD migration dosyalarını ve sıra bağımlılıklarını doğrulamalıdır. Dashboard farklı version taşıyan shard'ları anında göstermelidir.

Schema Version Table

Her shard uygulanan migration version'larını kaydeder. Orchestrator mevcut ve hedef version farkını görür. Manuel değişiklik tespit edilebilir. Version tablosu application health check'e dahil edilebilir. Production erişimi kontrollü olmalıdır.

Migration Orchestrator

Orchestrator shard listesi üzerinde rollout yönetir. Concurrency ve batch boyutu sınırlandırılır. Hata oluşursa sonraki shard'lar durdurulur. Retry güvenli olmalıdır. Her adım audit log bırakır.

CI/CD

Migration script staging ve test shard'larında doğrulanır. Backward compatibility otomatik test edilebilir. Long-running DDL riskleri analiz edilir. Deployment sırası application ile koordine edilir. Manual production DDL azaltılır.

Drift Detection

Periyodik job expected schema ile actual schema karşılaştırabilir. Kolon, index ve constraint farkı raporlanır. Drift oluştuğunda ownership ekibine alert gönderilir. Otomatik repair yalnızca güvenli değişikliklerde uygulanmalıdır. Manuel değişiklikler change process'e bağlanmalıdır.

Migration Health Dashboard

Dashboard shard başına current version ve migration state göstermelidir. Running, failed ve pending shard sayıları görünür olur. DDL latency ve lock etkisi eklenebilir. Operator rollout ilerlemesini izler. History geçmiş incident analizine yardım eder.

Replication Failover Nasıl Çalışır?

Replication failover primary erişilemez olduğunda sağlıklı replica'nın yeni primary rolüne geçirilmesidir. Önce gerçek failure tespit edilir. Ardından election veya promotion yapılır ve client yeni primary'yi keşfeder. Eski primary fencing ile write kabul etmekten çıkarılmalıdır. Toplam failover süresi detection, promotion ve reconnect adımlarının tamamından oluşur.

Primary Failure Detection

Health check primary response vermediğini belirler. Tek kısa network timeout hemen failover tetiklememelidir. Birden fazla node veya quorum failure'ı doğrulayabilir. Detection çok yavaşsa RTO uzar. Çok agresifse false failover riski artar.

Replica Promotion

En güncel ve sağlıklı replica yeni primary seçilir. Replication lag aday seçiminde önemlidir. Promotion sonrası write endpoint aktif edilir. Diğer replica'lar yeni leader'ı takip eder. Promotion event observability sistemine gönderilmelidir.

New Primary Discovery

Application yeni primary adresini öğrenmelidir. Proxy, service discovery veya managed endpoint kullanılabilir. DNS TTL uzun ise reconnect gecikebilir. Driver topology refresh destekleyebilir. Discovery mekanizması chaos test ile doğrulanmalıdır.

Application Reconnect

Existing connection'lar eski primary'ye bağlı kalabilir. Pool failure görüp yeni endpoint'e bağlanmalıdır. Retry aynı transaction'ı duplicate çalıştırmamalıdır. Idempotency önemli hale gelir. Connection storm yeni primary'yi aşırı yüklememelidir.

Old Primary Fencing

Eski primary network geri geldiğinde kendini hâlâ leader sanmamalıdır. Fencing token, lease veya cluster consensus write yetkisini engeller. Aksi halde split-brain oluşabilir. Eski node yeniden replica olarak join edebilir. Divergent data varsa rebuild gerekebilir.

Split-Brain Nedir?

Split-brain iki farklı node'un aynı anda primary olduğunu düşünmesi durumudur. Network partition veya hatalı failover bunu oluşturabilir. Her iki taraf write kabul ederse divergent veri oluşur. Quorum, consensus ve fencing bu riski azaltır. Split-brain testi high availability tasarımının zorunlu parçasıdır.

İki Primary Oluşması

İki node aynı shard için write leader olursa aynı key farklı değerler alabilir. Replication tekrar kurulduğunda conflict çözümü gerekir. Single-leader sistemlerde bu durum ciddi incident'tır. Application iki endpoint'e write göndermemelidir. Leadership token merkezi veya consensus tabanlı olmalıdır.

Network Partition

Node'lar birbirini göremezken client'ların farklı taraflara erişebilmesi mümkündür. Her taraf diğerinin öldüğünü sanabilir. Quorum çoğunluğu olmayan tarafın write kabul etmesini engeller. Availability kısa süre düşebilir. Bu trade-off consistency korumasının parçasıdır.

Divergent Writes

Partition sırasında iki leader farklı transaction'lar kabul ederse log geçmişleri ayrılır. Otomatik merge her zaman mümkün değildir. Finansal veride manuel reconciliation gerekebilir. Fencing bu durumu oluşmadan önlemek için daha güvenlidir. Incident sonrası audit trail korunmalıdır.

Quorum

Leader olabilmek için node çoğunluk onayı isteyebilir. Network ikiye bölündüğünde yalnızca majority taraf write kabul eder. Minority availability kaybeder. Bu yaklaşım split-brain riskini azaltır. Odd node sayısı quorum tasarımında yaygındır.

Fencing

Eski leader'ın kaynaklara erişimi aktif olarak kesilir. Lease veya generation number kullanılabilir. Storage veya proxy eski token ile write kabul etmez. Sadece application flag güvenli fencing değildir. Mechanism failure testlerinde doğrulanmalıdır.

Consensus

Consensus protokolü cluster üyelerinin tek leader ve log sırası üzerinde anlaşmasını sağlar. Raft veya benzeri algoritmalar kullanılabilir. Detay database ürününe göre farklıdır. Network partition altında availability ve consistency davranışı belirlenir. Operator bu semantiği bilmelidir.

Failover Gerçekten Anlık mıdır?

Failover hiçbir gerçek sistemde sıfır süreli değildir. Failure'ın fark edilmesi, election, promotion, endpoint güncelleme ve client reconnect zaman alır. DNS ve connection pool cache süreci daha da uzatabilir. RTO bu toplam sürenin business açısından kabul edilebilir sınırını belirler. High availability planı "otomatik failover var" cümlesinden daha ayrıntılı olmalıdır.

Failure Detection Süresi

Health check timeout ve retry sayısı detection süresini belirler. Çok kısa süre false positive oluşturabilir. Çok uzun süre write kesintisini uzatır. Network jitter normal davranıştan ayrılmalıdır. Threshold production latency baseline'ına göre seçilir.

Election

Cluster yeni leader için oylama yapabilir. Node sayısı ve network durumu election süresini etkiler. Quorum yoksa leader seçilemeyebilir. Bu consistency için bilinçli availability kaybıdır. Election timeout ayarları dikkatle seçilmelidir.

Promotion

Replica writable primary rolüne geçer. Recovery ve log replay gerekebilir. Çok geride replica promotion için uygun değildir. Index ve cache warmup kısa performans düşüşü yaratabilir. İlk trafik kontrollü gelmelidir.

DNS/Proxy Güncelleme

Yeni primary adresi client'a ulaştırılmalıdır. Proxy topology değişikliğini hızlı uygular. DNS cache eski IP'yi tutabilir. TTL tek başına tüm resolver davranışını garanti etmez. Managed endpoint driver-level discovery daha hızlı olabilir.

Client Reconnect

Uygulama eski socket'in kırıldığını fark eder. Pool yeni connection açar. Binlerce client aynı anda reconnect ederse connection storm oluşabilir. Jitter ve backoff kullanılabilir. İlk retry business operation idempotency'sini korumalıdır.

Cache/Pool Temizleme

Application stale topology bilgisini cache'de tutabilir. Connection pool eski primary'ye bağlı kalabilir. Failover event cache invalidation tetikleyebilir. Driver automatic refresh davranışı test edilmelidir. Manuel restart gerektiren tasarım yüksek availability hedefiyle uyumlu değildir.

RPO ve RTO Replication Tasarımını Nasıl Etkiler?

RPO kabul edilebilir veri kaybı miktarını, RTO ise servisin ne kadar sürede geri gelmesi gerektiğini tanımlar. Replication modu bu iki hedefe göre seçilmelidir. Async replication düşük latency sunarken küçük data-loss window oluşturabilir. Sync replication RPO'yu iyileştirirken write latency maliyeti getirir. Business requirement'tan topology kararına doğru ilerlemek en sağlıklı yöntemdir.

Recovery Point Objective

RPO "failure olduğunda en fazla ne kadar veri kaybedebiliriz" sorusuna cevap verir. Sıfır RPO güçlü synchronous durability gerektirebilir. Beş saniye tolerans async replication ile karşılanabilir. Gerçek lag dağılımı ölçülmelidir. Backup RPO ayrıca değerlendirilir.

Recovery Time Objective

RTO servis kesintisinin kabul edilebilir maksimum süresidir. Automatic failover bu süreyi azaltabilir. Client reconnect ve DNS değişimi de hesaba katılmalıdır. Manual approval gerekiyorsa RTO uzar. DR tatbikatı gerçek süreyi ölçer.

Async Data-Loss Window

Primary commit sonrası replica gerideyse failure anında son write'lar kaybolabilir. Window gerçek replication lag kadardır. Ortalama değil p99 lag önemlidir. Kritik tablolar farklı replication policy kullanabilir. Kullanıcıya verilen durability sözü bu ölçüme dayanmalıdır.

Sync Replication Maliyeti

Sync model replica acknowledgement beklediği için latency ekler. Cross-region network maliyeti daha yüksektir. Replica failure write availability'yi etkileyebilir. Quorum ayarı trade-off'u yönetir. Maliyet business risk ile karşılaştırılmalıdır.

Business Requirement'tan Topolojiye Gitmek

Önce ürün ve risk ekipleri kabul edilebilir veri kaybını tanımlar. Ardından teknik ekip replication topolojisini seçer. Tersine mevcut database default ayarını business requirement kabul etmek yanlıştır. Kritik domain'ler farklı RPO kullanabilir. Tasarım kararı dokümante edilmelidir.

Backup Replication'ın Yerini Alır mı?

Backup ve replication farklı problemlere cevap verir. Replica hardware failure'a karşı hızlı erişilebilirlik sağlar. Yanlış delete veya bozuk update replica'lara da hızla kopyalanabilir. Point-in-time recovery geçmiş state'e dönmeyi mümkün kılar. Bu yüzden replication hiçbir zaman backup yerine kullanılmamalıdır.

Replica'nın Aynı Mantıksal Hatayı Kopyalaması

Yanlış DELETE primary'de commit edildiğinde replica da aynı işlemi uygular. Tüm kopyalar aynı anda veri kaybeder. Replication bu hatayı korur, düzeltmez. Backup geçmiş state'i geri getirebilir. Audit log incident analizine yardım eder.

Accidental Delete

Operator veya application bug kritik tabloyu silebilir. Replica kısa sürede aynı state'e gelir. Immutable backup veya PITR gerekir. Restore işlemi yeni cluster üzerinde test edilmelidir. Permission ve change management riski azaltır.

Point-in-Time Recovery

PITR backup ve transaction log kullanarak belirli zamana dönmeyi sağlar. Hatalı değişiklikten saniyeler öncesi seçilebilir. Log retention RPO'yu etkiler. Restore süresi dataset büyüklüğüne bağlıdır. Düzenli restore testleri zorunludur.

Offline/Immutable Backup

Backup üretim cluster'ından bağımsız storage üzerinde tutulmalıdır. Immutable politika ransomware veya yanlış silmeye karşı koruma sağlar. Erişim yetkisi sınırlanmalıdır. Region dışı kopya disaster recovery sağlar. Retention business ve compliance requirement'a göre seçilir.

Restore Testleri

Backup alınması restore edilebilir olduğu anlamına gelmez. Düzenli test cluster kurulup gerçek restore yapılmalıdır. Süre RTO ile karşılaştırılır. Application query'leri veri doğruluğunu test eder. Metadata ve shard map restore sürecine dahil edilmelidir.

Sharded Database Backup Nasıl Alınır?

Sharded database backup her shard'ın verisini ve global metadata'yı birlikte korumalıdır. Shard başına bağımsız snapshot alınabilir. Global tutarlılık gerekiyorsa ortak transaction point belirlenmelidir. PITR logları shard bazında saklanmalıdır. Restore sırası shard map ve application topology ile birlikte planlanmalıdır.

Shard Başına Backup

Her shard kendi backup planına sahip olabilir. Aynı anda backup almak I/O spike oluşturabilir. Schedule shard grupları arasında yayılabilir. Backup success merkezi dashboard'da izlenmelidir. Missing shard backup global recovery'yi eksik bırakır.

Consistent Snapshot

Tek shard içinde transaction-consistent snapshot alınabilir. Global snapshot farklı shard timestamp'lerini eşleştirmeyi gerektirir. Application kısa write freeze uygulayabilir. Distributed snapshot mekanizması ürün tarafından sağlanabilir. Requirement gerçekten global consistency istiyor mu belirlenmelidir.

Global Transaction Point

Shard log position'ları aynı business zamanına bağlanabilir. Restore her shard'ı ilgili noktaya getirir. Clock time tek başına yeterli olmayabilir. Event ID veya global checkpoint kullanılabilir. Bu metadata backup ile birlikte saklanmalıdır.

PITR

Her shard için continuous transaction log arşivi tutulur. Restore hedef zamanı shard'lar arasında koordine edilmelidir. Bir shard'ın log zinciri eksikse global state bozulabilir. Retention window capacity planına dahil edilir. Recovery runbook otomatikleştirilebilir.

Restore Ordering

Önce metadata ve shard map restore edilmesi gerekebilir. Ardından shard database'ler hedef noktaya getirilir. Router trafik açmadan önce validation yapılır. Dependency service'ler doğru sırada başlatılır. DR tatbikatı bu sıralamayı doğrular.

Metadata/Shard Map Backup

Data shard'ları var olsa bile mapping kaybolursa application doğru route yapamaz. Shard map ayrı kritik veri olarak yedeklenmelidir. Version history yararlıdır. Mapping restore edildiğinde physical endpoint doğrulanmalıdır. Secret veya credential ayrı güvenli sistemde tutulmalıdır.

Multi-Region Database Replication

Multi-region replication verinin farklı coğrafi bölgelerde kopyalanmasını sağlar. Region-local read replica kullanıcı latency'sini düşürebilir. Cross-region async replication düşük write latency sunar. Active-passive model daha basitken active-active conflict ve consistency yönetimini büyütür. Region failure senaryosu düzenli olarak test edilmelidir.

Region-Local Read Replica

Her region kullanıcıları kendine yakın replica'dan okuyabilir. Global read latency azalır. Write central region'a gidiyorsa read-after-write daha dikkatli yönetilir. Replica lag cross-region linkten etkilenir. Permission gibi kritik read'ler primary region'a yönlendirilebilir.

Cross-Region Async Replication

Primary remote region acknowledgement beklemeden commit eder. Write latency düşük kalır. Remote copy kısa süre geriden gelir. Region kaybında son değişiklikler kaybolabilir. RPO bu lag penceresine göre belirlenir.

Active-Passive

Tek region write kabul eder. İkinci region standby olarak replica taşır. Failure halinde promotion yapılır. Conflict modeli basittir. Failover sonrası eski region dönüşü dikkatle yönetilmelidir.

Active-Active

Birden fazla region aynı anda trafik ve write kabul eder. Kullanıcı local latency kazanır. Conflict resolution ve global constraint zorlaşır. Data placement ve ownership kuralı ile conflict azaltılabilir. Her data type için active-active gerekmeyebilir.

Network Latency

Region'lar arası round-trip onlarca veya yüzlerce milisaniye olabilir. Sync replication bu süreyi write path'e ekleyebilir. Async model consistency penceresi yaratır. Application timeout değerleri topology'ye göre ayarlanmalıdır. Network egress maliyeti de hesaba katılmalıdır.

Region Failure

Tüm region erişilemez olduğunda traffic başka bölgeye geçmelidir. Database promotion tek adım değildir. Application, cache ve message broker dependency'leri de hazır olmalıdır. DNS veya global load balancer route değiştirir. DR testi uçtan uca yapılmalıdır.

Multi-Region Sharding

Multi-region sharding data placement ile geographic ownership'i birleştirir. Kullanıcı veya tenant home region'a atanabilir. Local query kendi shard grubunda çalışır. Cross-region entity erişimi ek latency ve consistency ihtiyacı getirir. Data residency ve disaster recovery aynı model içinde açık kurallarla ele alınmalıdır.

Region-Based Shard

Her region kendi shard setini barındırır. Region kullanıcıları local database'e erişir. Global router önce region sonra shard seçer. Region kapasitesi bağımsız scale edilir. Metadata global olarak erişilebilir olmalıdır.

User Home Region

Her kullanıcı için canonical home region belirlenebilir. Tüm write default olarak bu region'a gider. Kullanıcı seyahat etse bile veri ownership değişmez. Uzun vadeli relocation migration gerektirebilir. Profile metadata route kararını taşır.

Cross-Region Query

Global admin veya search query birden fazla region'a fan-out yapabilir. Network latency tail süreyi artırır. Data residency bazı query'leri engelleyebilir. Aggregation warehouse tercih edilebilir. OLTP request mümkün olduğunca local tutulmalıdır.

Global User

Bazı kullanıcı veya tenant birden fazla region'da aktif olabilir. Tek home region write consistency'yi basitleştirir. Read replica diğer bölgelerde bulunabilir. Multi-leader ihtiyaç varsa conflict model gerekir. Business SLA karar verici olmalıdır.

Data Residency

Her shard placement policy hangi region'larda primary ve replica bulunabileceğini belirler. Backup da aynı kurala uymalıdır. Cross-region analytics hassas veriyi taşımamalıdır. Metadata sınıflandırması gereklidir. Compliance audit otomatik raporlanabilir.

Disaster Recovery

Region-local shard'ların başka bölgede DR kopyası tutulabilir. Residency izin vermiyorsa aynı ülke içinde ikinci bölge gerekebilir. Failover home region mapping'ini geçici değiştirebilir. Recovery sonrası failback planı gerekir. RPO shard bazında ölçülmelidir.

CAP Teoremi Sharding ve Replication'ı Nasıl Etkiler?

CAP teoremi network partition gerçekleştiğinde distributed sistemin consistency ve availability arasında seçim yapmak zorunda kalabileceğini açıklar. Partition tolerance gerçek dağıtık sistemde kaçınılmaz kabul edilir. Database'in normal günlerde latency veya performance seçimi CAP ile aynı şey değildir. Sharding ve replication network sınırlarını artırdığı için partition davranışı daha önemli hale gelir. Ürünün failure anındaki tercihi business risk ile uyumlu olmalıdır.

Consistency

Consistency burada tüm client'ların aynı logical state'i görmesine yakın güçlü garanti anlamında değerlendirilir. Partition sırasında minority taraf write kabul etmeyebilir. Kullanıcı kısa süre hata görür. Buna karşılık divergent data riski azalır. Finansal sistemler bu yaklaşımı tercih edebilir.

Availability

Availability her request'in cevap almasını önceliklendirir. Partition sırasında iki taraf da write kabul ederse state ayrışabilir. Daha sonra conflict resolution gerekir. Social veya bazı telemetry workload'ları bunu tolere edebilir. Business semantics belirleyicidir.

Partition Tolerance

Network bağlantısının kısmen kopabileceği kabul edilir. Farklı node grupları birbirini göremeyebilir. Distributed sistem bu durumda davranmaya devam etmelidir. "Network hiç bölünmez" varsayımı güvenli değildir. Chaos test partition senaryosunu doğrulamalıdır.

Network Partition Altındaki Kararlar

Cluster majority tarafı write kabul edip minority'yi kapatabilir. Bu consistency ağırlıklı seçimdir. Alternatif sistem iki tarafta write kabul edip sonra merge yapabilir. Bu availability ağırlıklı seçimdir. Tek global doğru tercih yoktur.

CAP'in Normal Operasyon Latency Trade-Off'uyla Karıştırılmaması

CAP özellikle network partition durumundaki garanti çatışmasına odaklanır. Normal healthy network altında sync replication latency'si farklı bir trade-off'tur. Her distributed database tartışmasını CAP ile açıklamak yeterli değildir. PACELC gibi daha geniş modeller latency kararlarını ele alır. En önemlisi ürünün gerçek consistency sözleşmesini anlamaktır.

Strong Consistency mi Eventual Consistency mi?

Consistency modeli veri türünün business riskine göre seçilmelidir. Banking ve inventory gibi alanlarda eski state ciddi hata yaratabilir. Social feed veya analytics birkaç saniye gecikmeyi tolere edebilir. Tek sistem içinde farklı tablolar farklı consistency gereksinimi taşıyabilir. Performans uğruna kritik state'i eventual consistency'ye çevirmek doğru değildir.

Banking

Bakiye ve transfer durumları güçlü consistency gerektirebilir. Kullanıcı aynı parayı iki kez harcamamalıdır. Transaction ve idempotency önemlidir. Replica read yalnızca raporlama amaçlı kullanılabilir. RPO hedefi çok düşük olmalıdır.

Inventory

Stok sayısı oversell riskini doğrudan etkiler. Güçlü reservation veya atomic decrement gerekebilir. Replica lag eski stok gösterebilir. Display count eventual olabilirken checkout decision strong olabilir. Aynı veri için farklı read yolları kullanılabilir.

Social Feed

Yeni gönderinin birkaç saniye geç görünmesi çoğu kullanıcı için kabul edilebilir. Eventual consistency daha yüksek availability ve read scaling sağlayabilir. Feed fan-out ayrı sistemde yapılabilir. Like sayıları approximate olabilir. Permission filtreleri yine güçlü olmalıdır.

Analytics

Analytics verisi genellikle saniye veya dakika gecikmeyi tolere eder. Replica veya warehouse read kullanılabilir. Batch aggregation performans açısından daha uygundur. Kesin finansal rapor farklı consistency sınıfı olabilir. Dashboard üzerinde freshness bilgisi gösterilebilir.

Business Risk'e Göre Tutarlılık Seçimi

Teknik ekip önce "ne kadar stale kabul edilir" sorusunu ürün sahiplerine sormalıdır. Risk kullanıcı deneyimi, para veya güvenlik üzerinden değerlendirilir. Ardından routing ve replication modeli seçilir. Consistency requirement dokümante edilir. Bu yaklaşım gereksiz strong consistency maliyetini de önler.

Sharded Database İçin Connection Pooling

Sharded sistemde connection pooling daha zor hale gelir çünkü her application instance birden fazla shard'a erişebilir. Her shard için büyük pool açmak connection explosion yaratır. Shard sayısı yüzlere çıktığında bu model sürdürülemez olabilir. Proxy-based pooling veya lazy connection yaklaşımı gerekebilir. Serverless workload'larda kısa ömürlü instance sayısı problemi daha da büyütür.

Her Shard İçin Pool

Basit tasarım her shard endpoint'i için ayrı pool tutar. Az shard'da yönetilebilir. Pool minimum connection değeri bile toplamda büyük sayı oluşturabilir. Lazy open kullanılmalıdır. Inactive shard connection'ları kapatılabilir.

Shard Sayısı Arttıkça Connection Sayısı

100 app instance ve 50 shard kombinasyonu büyük connection matrisi üretir. Her pool 10 connection açarsa teorik sayı çok büyür. Database max connection limitleri aşılabilir. Connection budget global hesaplanmalıdır. Router lokal affinity kullanabilir.

Connection Explosion

Aşırı connection database memory'sini tüketir. Context switching ve process overhead artar. Query throughput yükselmek yerine düşebilir. Proxy pool çok sayıda client connection'ı az backend connection'a multiplex edebilir. Transaction semantics proxy desteğiyle uyumlu olmalıdır.

Proxy-Based Pooling

Application proxy'ye bağlanır. Proxy shard backend connection'larını ortak havuzda tutar. Client instance sayısı database connection sayısına doğrudan yansımaz. Proxy HA ve latency önemlidir. Session-level feature'lar multiplexing'i sınırlayabilir.

Serverless Workload'lar

Serverless function sayısı kısa sürede yüzlerce instance'a çıkabilir. Her instance doğrudan database pool açarsa connection storm oluşur. Managed proxy veya data API kullanılabilir. Cold start connection latency'yi etkiler. Concurrency database kapasitesiyle sınırlandırılmalıdır.

Shard Router'ın High Availability Tasarımı

Shard router tüm query'lerin doğru data node'una ulaşmasını sağladığı için kritik altyapıdır. Router mümkün olduğunca stateless çalışmalıdır. Shard map replicated metadata kaynağında tutulmalıdır. Local cache latency'yi azaltır ancak topology refresh güvenilir olmalıdır. Tek router failure tüm database erişimini durdurmamalıdır.

Stateless Router

Stateless instance kolayca yatay ölçeklenir. Request başka router'a geçtiğinde session state kaybolmaz. Routing metadata dış kaynak veya cache üzerinden alınır. Deployment basitleşir. Connection state yine local olabilir.

Replicated Shard Map

Shard map tek node üzerinde tutulmamalıdır. Replication veya consensus ile korunmalıdır. Mapping değişikliği versionlu yapılır. Router eski ve yeni version farkını anlayabilir. Metadata backup ayrıca alınmalıdır.

Local Cache

Router her query için merkezi map servisine gitmez. Local cache düşük latency sağlar. TTL veya push invalidation kullanılabilir. Migration sırasında hızlı refresh gerekir. Stale route için redirect veya retry mekanizması olmalıdır.

Topology Refresh

Failover veya resharding mapping'i değiştirir. Router event veya polling ile yeni topology öğrenir. Refresh çok yavaşsa yanlış node'a trafik gider. Çok sık refresh control plane yükünü artırır. Version check hafif çözüm sunabilir.

Router Failure

Bir router instance çöktüğünde load balancer trafiği diğerlerine vermelidir. In-flight request retry olabilir. Write retry idempotent olmalıdır. Health check hızlı failure detection sağlamalıdır. Router fleet farklı zone'lara dağıtılabilir.

Hot Shard Nasıl İzlenir?

Hot shard global database metriğine bakılarak kolayca görülemeyebilir. Her shard için QPS, CPU, disk I/O, storage, connection ve p95/p99 query latency ayrı ölçülmelidir. Ortalama cluster CPU düşükken tek shard yüzde yüze ulaşabilir. Dashboard dağılımı yan yana göstermelidir. Alert relative skew ve absolute threshold birlikte kullanabilir.

Per-Shard QPS

Read ve write QPS shard bazında izlenir. Median ile en yüksek shard karşılaştırılabilir. Büyük fark hot key veya tenant göstergesi olabilir. Workload türü ayrıca etiketlenmelidir. Ani spike access pattern değişikliğini gösterebilir.

CPU

Shard CPU uzun süre diğerlerinden yüksekse query veya traffic skew olabilir. Top queries listesi incelenir. Replica CPU read distribution'ı gösterebilir. Primary CPU write yükünü temsil eder. Headroom kapasite planında tutulmalıdır.

Disk I/O

Hot shard daha fazla read veya write IOPS kullanabilir. Disk latency query p99'u etkiler. Backup veya compaction geçici spike oluşturabilir. Workload ile maintenance ayrıştırılmalıdır. Storage tier gerekirse shard bazında değiştirilebilir.

Storage

Row distribution dengeli görünse bile bazı kayıtlar çok daha büyük olabilir. Shard storage byte bazında izlenmelidir. Growth rate gelecekteki split zamanını gösterir. Index size ayrıca takip edilmelidir. Capacity threshold migration'dan aylar önce alarm vermelidir.

Connection Count

Belirli shard çok fazla connection alıyorsa router veya tenant skew olabilir. Active ve idle connection ayrılmalıdır. Pool config tüm shard'larda aynı olmamalı olabilir. Connection wait application metric'iyle birlikte incelenir. Proxy usage durumu görünür olmalıdır.

p95/p99 Query Latency

Hot shard tail latency global kullanıcı deneyimini etkileyebilir. Ortalama süre normal kalabilir. Query type ve tenant bazında breakdown faydalıdır. Slow query log shard ID taşımalıdır. Rebalancing sonrası latency değişimi karşılaştırılmalıdır.

Shard Balance Nasıl Ölçülür?

Shard balance yalnızca row sayısına bakılarak değerlendirilmemelidir. Storage, read, write ve connection dağılımı ayrı ayrı ölçülmelidir. Skew ratio en yoğun shard'ın median veya average değere oranını gösterebilir. Capacity headroom tüm shard'larda yeterli olmalıdır. Denge zaman içinde değişebileceği için sürekli gözlem gerektirir.

Row Distribution

Her shard toplam satır sayısı karşılaştırılır. Büyük fark data skew gösterebilir. Row size farklıysa tek başına yanıltıcıdır. Tenant count ile birlikte değerlendirilebilir. Resharding candidate shard'lar belirlenir.

Storage Distribution

Disk kullanım yüzdesi node bazında ölçülür. Index ve table size ayrımı yapılır. Bir shard storage ceiling'e yaklaşırken diğerleri boş kalıyorsa balance kötüdür. Compression oranı farklı olabilir. Data lifecycle politikası etkiler.

Read Distribution

Read QPS ve bytes read shard bazında karşılaştırılır. Hot cache veya celebrity entity tek shard'ı yoğunlaştırabilir. Replica sayısı shard bazında farklılaştırılabilir. Read cache çözüm olabilir. Shard key değişikliği her zaman gerekli değildir.

Write Distribution

Write QPS ve log generation rate dağılımı önemlidir. Monotonic key latest shard'ı hot yapabilir. Tenant büyüklüğü write skew oluşturabilir. Split veya salt stratejisi gerekebilir. Write imbalance primary capacity'yi doğrudan etkiler.

Skew Ratio

En yoğun shard değeri median shard değerine bölünebilir. Oran belirli eşiği aştığında alarm üretilir. Metric CPU, storage ve QPS için ayrı hesaplanmalıdır. Tek sayı bütün resmi vermez. Trend zaman içinde incelenmelidir.

Capacity Headroom

Her shard peak yük üzerinde güvenli boş kapasite taşımalıdır. Migration ve failover sırasında ek yük oluşabilir. Yüzde yüz kullanılan shard normal kabul edilmemelidir. Headroom SLO ve recovery planına göre seçilir. Büyük tenant move için target kapasitesi önceden ayrılmalıdır.

Replication İçin Hangi Metrikler İzlenmelidir?

Replication sağlığı yalnızca replica up/down durumundan ibaret değildir. Lag, transaction log farkı, apply rate, CPU ve disk metrikleri birlikte izlenmelidir. Failover sayısı beklenmeyen instability göstergesi olabilir. Replica read latency ayrıca takip edilmelidir. Alarm threshold'ları RPO ve read freshness hedefleriyle bağlantılı olmalıdır.

Replica Lag

Replica'nın primary'den ne kadar geride olduğu ölçülür. Time-based ve log-position-based değerler kullanılabilir. P95 lag kullanıcı riskini daha iyi gösterebilir. Threshold aşılırsa read pool'dan çıkarılabilir. DR replica için farklı sınır kullanılabilir.

WAL/Binlog Lag

Log byte veya position farkı replication backlog'un miktarını gösterir. Time lag düşük olsa bile çok büyük byte backlog olabilir. Catch-up süresi apply rate ile birlikte tahmin edilir. Log retention dolmadan müdahale edilmelidir. Shard bazında grafiklenmelidir.

Apply Rate

Replica saniyede ne kadar log değişikliği uyguluyor izlenir. Primary generation rate daha yüksekse lag büyür. CPU veya disk upgrade gerekebilir. Analytics load apply rate'i düşürebilir. Maintenance sırasında geçici değişim normal olabilir.

Replica CPU

Read traffic ve apply işlemi aynı CPU kaynağını kullanabilir. Yüksek CPU lag'i artırabilir. Failover adayı replica için headroom önemlidir. Promotion sonrası write yükünü taşıyabilmelidir. Boyutlandırma yalnızca read workload'a göre yapılmamalıdır.

Replica Disk

Apply ve read aynı disk kaynaklarına yük bindirir. Disk latency yükseldiğinde replication geride kalabilir. Storage queue depth izlenir. Backup job aynı diski etkileyebilir. Replica role göre ayrı storage seçilebilir.

Failover Count

Sık failover altyapı veya network instability göstergesidir. Otomatik failover olması sık gerçekleşmesini normal yapmaz. Her olay root cause ile incelenmelidir. False positive election ayarları düzeltilebilir. Failover sonrası data loss ve latency kaydedilmelidir.

Database Scaling İçin SLO'lar

Database scaling teknik kapasite kadar ölçülebilir service hedefleriyle yönetilmelidir. Read ve write availability ayrı SLO olabilir. p95/p99 latency kullanıcı deneyimini temsil eder. Replica lag, failover time ve data loss budget distributed topology için kritik hedeflerdir. SLO kapasite kararlarını ve alert önceliğini yönlendirir.

Read Availability

Read request'lerin başarı oranı ölçülür. Replica çokluğu read availability'yi artırabilir. Critical read ile analytics read farklı SLO taşıyabilir. Partial region failure ayrı değerlendirilir. Error budget operasyon kararlarına girdi olur.

Write Availability

Write availability primary veya quorum erişimine bağlıdır. Failover sırasında kısa kesinti olabilir. Retry kullanıcıya görünmeyen hataları azaltabilir. Duplicate write riskine karşı idempotency gerekir. SLO business transaction türüne göre değişebilir.

p95/p99 Latency

Average query süresi tail problemi gizler. p95 ve p99 yüksek shard veya replica sorununu gösterir. Read ve write ayrı ölçülmelidir. Cross-shard query farklı SLO alabilir. Load test bu hedefleri doğrular.

Replica Lag SLO

Örneğin replica'ların yüzde 99'unda lag belirli sürenin altında olabilir. Bu hedef read freshness garantisini destekler. Aşım olduğunda routing primary'ye dönebilir. DR replica farklı threshold kullanabilir. Metric doğru clock veya log position üzerinden hesaplanmalıdır.

Failover Time

Primary failure'dan başarılı write recovery'ye kadar geçen süre ölçülür. Detection, promotion ve reconnect dahil edilir. Sadece database control plane süresine bakılmamalıdır. Application perspective esas alınmalıdır. Düzenli test gerçek RTO'yu doğrular.

Data Loss Budget

Business belirli zaman aralığında kabul edilebilir maksimum data loss tanımlayabilir. Bu RPO ile bağlantılıdır. Async replication bu bütçeye göre ayarlanır. Kritik operation farklı policy kullanabilir. Incident sonrası gerçek kayıp ölçülmelidir.

Database Scaling Load Testleri

Sharding ve replication production'a alınmadan önce gerçek workload'a yakın load testleri yapılmalıdır. Read-heavy, write-heavy ve mixed senaryolar ayrı çalıştırılmalıdır. Hot-key ve cross-shard query davranışı özellikle test edilmelidir. Rebalancing sırasında normal trafik tekrar ölçülmelidir. En önemli amaç sistemin saturation noktasını ve recovery davranışını bilmektir.

Read-Heavy Test

Replica routing ve cache etkisi yüksek read oranıyla test edilir. Replica lag artışı gözlenir. Load balancer dağılımı ölçülür. Primary read fallback kapasitesi kontrol edilir. Stale read testleri ayrıca yapılır.

Write-Heavy Test

Primary veya shard primary'leri yüksek write QPS altında çalıştırılır. Transaction log ve disk flush izlenir. Hot shard oluşup oluşmadığı kontrol edilir. Retry ve timeout oranı ölçülür. Shard sayısıyla throughput artışı doğrulanır.

Mixed Workload

Production'a yakın read/write oranı kullanılır. Read replica ve primary aynı anda yük altındadır. Analytics veya background job eklenebilir. Gerçek connection pool davranışı görülür. Tail latency capacity limitini gösterir.

Hot-Key Test

Tek tenant veya user üzerine yoğun trafik bilinçli gönderilir. Shard skew gözlenir. Rate limit ve cache etkisi ölçülür. Sistem diğer tenant'ları koruyabiliyor mu kontrol edilir. Split stratejisi gerektiğinde test edilir.

Cross-Shard Query Test

Scatter-gather sorgular farklı shard sayılarında çalıştırılır. Fan-out connection ve CPU amplification ölçülür. En yavaş shard latency etkisi görülür. Timeout ve partial failure davranışı test edilir. Query'nin warehouse'a taşınma ihtiyacı değerlendirilir.

Rebalancing Sırasında Load Test

Data migration production I/O ile aynı anda yürütülür. Query latency ve replica lag değişimi izlenir. Rebalance rate limit ayarlanır. Target shard warming etkisi ölçülür. Migration kullanıcı SLO'sunu bozmamalıdır.

Failure ve Chaos Testleri

Distributed database mimarisinin güvenilirliği failure senaryolarıyla doğrulanmalıdır. Primary, replica, router veya tüm shard kasıtlı olarak kapatılabilir. Network partition ve full disk gibi durumlar da test edilmelidir. Amaç beklenen failover, fencing ve recovery mekanizmalarının gerçekten çalıştığını görmektir. Test yalnızca staging değil kontrollü production game day süreçlerinde de uygulanabilir.

Primary Kill

Primary process veya node aniden durdurulur. Replica promotion süresi ölçülür. Client reconnect ve retry davranışı izlenir. Duplicate write oluşmamalıdır. RTO hedefi doğrulanır.

Replica Kill

Tek replica kaybının read capacity ve durability etkisi ölçülür. Load balancer node'u hızla çıkarmalıdır. Primary write behavior replication policy'ye göre değişebilir. Yeni replica rebuild süresi kaydedilir. Alert doğru ekibe ulaşmalıdır.

Network Partition

Primary ile replica veya cluster üyeleri arasındaki network kesilir. Quorum davranışı gözlenir. Split-brain oluşmamalıdır. Minority write policy doğrulanır. Network geri geldiğinde rejoin güvenli olmalıdır.

Slow Replica

Replica CPU veya disk yapay olarak yavaşlatılır. Lag threshold routing'i node'dan çıkarmalıdır. Catch-up sonrası recovery kontrol edilir. Failover candidate priority etkilenebilir. Kullanıcı stale read yaşamamalıdır.

Full Disk

Disk kapasitesi dolduğunda database write davranışı test edilir. Log veya temporary file failure görülebilir. Alert önceden tetiklenmelidir. Auto-scaling storage varsa süre ölçülür. Replica rebuild veya cleanup runbook çalıştırılır.

Shard Failure

Tek shard grubu tamamen erişilemez hale getirilebilir. Diğer shard kullanıcıları hizmet almaya devam etmelidir. Router failure scope'u doğru göstermelidir. Global query partial failure politikası test edilir. DR shard activation gerekebilir.

Router Failure

Shard router instance'ları kapatılır. Load balancer diğer router'lara geçmelidir. Connection storm oluşmamalıdır. Metadata service erişilebilir kalmalıdır. Router fleet kapasitesi N-1 durumda yeterli olmalıdır.

Sharding Maliyeti Nasıl Hesaplanmalıdır?

Sharding maliyeti yalnızca ek database node fiyatından ibaret değildir. Her shard için replica, backup, monitoring ve network gideri oluşur. Schema migration ve resharding için mühendislik zamanı gerekir. Incident response ve operasyon otomasyonu da toplam sahip olma maliyetine dahildir. Kurumsal veritabanı sharding replication ve ölçeklendirme hizmeti planlanırken teknik kazanç bu toplam maliyetle karşılaştırılmalıdır.

Daha Fazla Database Node

Shard sayısı arttıkça primary node sayısı artar. Her node için compute ve storage maliyeti oluşur. Küçük shard'lar düşük kullanımda kalabilir. Capacity pooling azalabilir. Optimal shard size ekonomik olarak da değerlendirilmelidir.

Replica Maliyeti

Her primary için bir veya daha fazla replica gerekebilir. Bu compute ve storage maliyetini katlar. Cross-region replica network egress ekler. Analytics replica ayrı kapasite olabilir. RPO ve availability hedefi replica sayısını belirler.

Network Transfer

Replication ve resharding ciddi network trafiği oluşturabilir. Cross-region transfer daha pahalı olabilir. Cross-shard query de sürekli data movement yaratır. Network maliyeti query design ile azaltılabilir. Data locality ekonomik avantaj da sağlar.

Backup

Her shard backup storage tüketir. PITR logları ayrıca büyür. Retention süresi maliyeti etkiler. Restore test cluster'ı geçici compute gerektirir. Backup yalnızca storage line item değildir.

Monitoring

Per-shard ve per-replica metric cardinality artar. Log ve trace hacmi büyür. Dashboard ve alert yönetimi ekstra çalışma gerektirir. Observability maliyeti capacity planına eklenmelidir. Sampling ve retention optimize edilebilir.

Operational Engineering Cost

Sharding schema migration, failover ve resharding otomasyonu gerektirir. Ekibin distributed systems deneyimi önem kazanır. On-call yükü artabilir. Managed solution bazı işleri azaltabilir. Mühendislik zamanı en büyük gizli maliyetlerden biridir.

Over-Sharding Nedir?

Over-sharding ihtiyaçtan çok daha fazla shard oluşturulmasıdır. Çok küçük dataset'ler ayrı node'lara bölündüğünde connection ve operasyon maliyeti gereksiz büyür. Schema migration daha fazla target üzerinde çalışır. Monitoring ve backup sayısı artar. Gelecek büyüme için headroom gerekir ama aşırı shard sayısı da verimsizdir.

Gereğinden Fazla Shard

Trafik ve dataset küçükken yüzlerce shard yönetmek gereksiz olabilir. Node başına kullanım çok düşük kalır. Her topology değişikliği daha fazla metadata üretir. Global query fan-out büyür. Daha az ama yeterli shard genellikle daha sağlıklıdır.

Çok Küçük Dataset per Shard

Her shard birkaç gigabayt veri taşıyorsa büyük database instance kapasitesi boşa gidebilir. Backup ve maintenance avantajı sınırlı olur. Connection overhead dataset'ten daha önemli hale gelir. Tenant grouping kullanılabilir. Shard size hedefi belirlenmelidir.

Connection Maliyeti

Her shard ayrı pool ve health check gerektirir. Application instance sayısı connection sayısını katlar. Proxy olmadan connection explosion oluşabilir. Idle connection memory tüketir. Shard sayısı connection budget ile uyumlu olmalıdır.

Schema Migration Maliyeti

Her DDL yüzlerce shard üzerinde uygulanır. Canary ve batch rollout uzun sürebilir. Drift riski büyür. Migration orchestrator zorunlu hale gelir. Küçük sistem için bu yük gereksiz olabilir.

Operasyonel Karmaşıklık

Daha fazla shard daha fazla failover, backup ve alert kaynağı demektir. Operator mental modeli ağırlaşır. Otomasyon olmadan hata riski büyür. Incident scope bulmak zorlaşabilir. Shard count teknik kapasite kadar ekip kapasitesine göre seçilmelidir.

Sharding Yerine Distributed SQL Kullanılabilir mi?

Distributed SQL verinin node'lar arasında otomatik dağıtılması, transaction coordination ve rebalancing gibi işleri database engine içine taşıyabilir. Application manual shard routing yazmak zorunda kalmayabilir. SQL semantics korunur. Bununla birlikte network coordination, latency ve vendor özellikleri yeni trade-off'lar getirir. Migration cost ve transaction requirement detaylı değerlendirilmelidir.

Automatic Data Distribution

Engine key range veya hash bölümlerini node'lar arasında otomatik dağıtır. Node eklenince rebalancing başlar. Application physical shard map bilmez. Hot key yine sorun olabilir. Partition key seçimi önemini korur.

Distributed Transactions

Database cross-node transaction protokolünü kendi içinde yönetebilir. Application 2PC kodu yazmaz. Latency local transaction'dan daha yüksek olabilir. Network partition semantics ürün tarafından belirlenir. Transaction scope yine mümkün olduğunca küçük tutulmalıdır.

Automatic Rebalancing

Cluster yeni node eklenince data hareketini otomatik başlatabilir. Operator manuel shard split yapmaz. Rebalancing production load'u etkileyebilir. Rate ve priority ayarı gerekir. Metric ve alert yine gereklidir.

SQL Semantics

Application tanıdık SQL kullanabilir. Ancak tüm feature ve query plan'ları single-node database ile aynı maliyete sahip değildir. Global join pahalı olabilir. Secondary index distributed write amplification oluşturabilir. Query plan inceleme önemlidir.

Operasyonel Kolaylık

Manual shard map ve router kodu azalır. Backup ve schema migration daha merkezi olabilir. Buna karşılık distributed engine'in kendisini işletmek ayrı uzmanlık gerektirir. Managed service bu yükü azaltabilir. Ürün sınırları ve support modeli değerlendirilmelidir.

Yeni Trade-Off'lar

Automatic distribution coordination maliyetini gizler ama yok etmez. Cross-region strong consistency latency ekleyebilir. Hot key ve poor access pattern hâlâ problem yaratır. Vendor-specific SQL behavior olabilir. Benchmark gerçek workload ile yapılmalıdır.

PostgreSQL Ölçekleme Seçenekleri

PostgreSQL read replica, native partitioning ve farklı logical dağıtım araçlarıyla çeşitli ölçekleme seçenekleri sunar. Streaming replication high availability ve read scaling için kullanılabilir. Logical replication belirli tablo veya event akışlarını farklı topolojilere taşıyabilir. Citus gibi yaklaşımlar distributed PostgreSQL modeli sağlar. Seçim workload, transaction ve operasyon gereksinimine göre yapılmalıdır.

Streaming Replication

WAL değişiklikleri replica'lara fiziksel olarak aktarılır. High availability ve read-only replica için kullanışlıdır. Sync ve async seçenekler topolojiye göre ayarlanabilir. Replica lag izlenmelidir. Primary write bottleneck devam eder.

Logical Replication

Logical replication tablo veya değişiklik seviyesinde daha esnek aktarım sağlar. Selective replication ve migration için kullanılabilir. Schema uyumluluğu ayrıca yönetilmelidir. Resharding veya CDC kullanımında faydalı olabilir. Physical HA mekanizmasının doğrudan alternatifi değildir.

Read Replicas

Read-only PostgreSQL replica read throughput'u artırır. Application read/write splitting yapabilir. Read-after-write problemi vardır. Reporting replica ayrı tutulabilir. Failover mekanizması ek orchestration gerektirebilir.

Native Partitioning

Range, list ve hash partitioning büyük tabloları organize eder. Partition pruning query maliyetini azaltır. Maintenance ve archive işlemleri kolaylaşır. Tek instance write ceiling değişmez. Sharding öncesi güçlü adımdır.

Citus

Citus PostgreSQL tablolarını distributed biçimde worker node'lara yaymayı sağlayabilir. Distribution column shard key benzeri rol oynar. Co-located table tasarımı cross-node join maliyetini azaltır. Distributed transaction ve query davranışı workload'a göre test edilmelidir. Operasyon modeli standard PostgreSQL'den daha geniştir.

Sharding Middleware

Application veya proxy tabanlı middleware PostgreSQL shard routing sağlayabilir. Her shard normal PostgreSQL cluster olabilir. Büyük kontrol esnekliği sunar. Schema migration ve resharding ekip sorumluluğunda kalır. Otomasyon güçlü olmalıdır.

MySQL Ölçekleme Seçenekleri

MySQL primary-replica topolojisi, Group Replication ve sharding araçlarıyla ölçeklenebilir. Read/write splitting read kapasitesini dağıtabilir. Vitess gibi platformlar büyük MySQL fleet'lerinde routing ve resharding sağlar. Online migration araçları production değişikliklerini kolaylaştırır. Hangi yöntemin uygun olduğu dataset ve transaction pattern'e göre belirlenmelidir.

Primary-Replica

Write primary üzerinde, read replica'larda çalışabilir. Binlog replication temel değişiklik akışını sağlar. Async model yaygındır. Lag-aware routing gereklidir. Write bottleneck primary'de kalır.

Group Replication

Group Replication cluster üyeleri arasında coordination ve failover özellikleri sunar. Single-primary veya farklı mode seçenekleri olabilir. Quorum davranışı split-brain riskini azaltır. Network latency performansı etkiler. Production failure testleri gereklidir.

Read/Write Splitting

Application veya proxy write sorgularını primary'ye yönlendirir. Read sorguları replica'lara dağıtılır. Transaction içi read primary'de tutulmalıdır. Stale data riskine karşı session routing uygulanabilir. Monitoring replication lag'i route kararına eklemelidir.

Vitess

Vitess MySQL sharding ve topology yönetimini platform katmanına taşır. VTGate query routing sağlar. Vindex shard mapping için kullanılır. Online resharding büyük cluster değişikliklerini kolaylaştırabilir. SQL ve transaction sınırları workload ile test edilmelidir.

Online Resharding

VReplication benzeri mekanizmalar source ve target shard'ları senkron tutabilir. Data copy devam ederken application çalışır. Validation sonrası traffic cutover yapılır. Rollback planı tutulmalıdır. Büyük dataset migration'ında network kapasitesi ölçülmelidir.

MongoDB Sharding ve Replication

MongoDB sharding ve replication kavramlarını native cluster mimarisi içinde birlikte sunar. Replica set high availability sağlar. Mongos query routing yapar ve config server metadata taşır. Shard key veri dağılımının temelidir. Balancer ve resharding özellikleri topology değişikliklerini yönetmeye yardımcı olur.

Replica Set

Her shard replica set olarak çalışabilir. Primary write kabul eder. Secondary node'lar replication yapar. Election failure recovery sağlar. Read preference consistency davranışını etkiler.

Mongos

Mongos application ile shard cluster arasında router görevi görür. Query shard key içeriyorsa target belirlenir. Key yoksa scatter-gather yapılabilir. Birden fazla mongos instance HA sağlar. Router stateless'e yakın çalışır.

Config Server

Config server cluster metadata ve chunk placement bilgisini tutar. Kritik control plane bileşenidir. Replica set olarak korunur. Backup ve recovery planına dahil edilmelidir. Metadata drift tüm routing'i etkileyebilir.

Shard Key

Shard key chunk dağılımını belirler. Cardinality ve query pattern önemlidir. Monotonik key hot shard yaratabilir. Hashed key daha dengeli dağıtabilir. Resharding sonradan değişiklik imkanı sunabilir.

Balancer

Balancer chunk'ları shard'lar arasında taşıyarak dağılımı dengeler. Migration network ve I/O kullanır. Production workload ile aynı kaynakları paylaşır. Window veya rate kontrol edilebilir. Hot single key'i otomatik çözemeyebilir.

Resharding

Yeni shard key'e geçiş için online resharding kullanılabilir. Data yeni dağılıma kopyalanır. Değişiklikler migration boyunca senkron tutulur. Feature davranışı kullanılan sürüme göre incelenmelidir. Büyük dataset üzerinde kapasite etkisi test edilmelidir.

Cassandra ve Leaderless Scaling

Cassandra leaderless replication ve partition key tabanlı dağıtım modeli kullanır. Data consistent hashing benzeri ring yapısıyla node'lara dağıtılır. Replication factor birden fazla kopya sağlar. Read ve write consistency seviyeleri quorum üzerinden ayarlanabilir. Multi-datacenter topology yüksek availability ve locality hedefleri için kullanılabilir.

Partition Key

Partition key data placement ve query locality'yi belirler. Query çoğunlukla partition key üzerinden yapılmalıdır. Kötü key hot partition oluşturabilir. Çok büyük partition maintenance ve read performansını bozar. Data modeling query-first yapılır.

Replication Factor

Her partition'ın kaç node kopyası olacağını belirler. Daha yüksek değer storage ve write maliyetini artırır. Failure tolerance güçlenir. Datacenter bazlı placement yapılabilir. Consistency level ile birlikte düşünülmelidir.

Quorum

Read veya write için çoğunluk replica cevabı istenebilir. Quorum consistency ile availability arasında denge kurar. Local quorum cross-region latency'yi azaltabilir. Node failure davranışı test edilmelidir. İşlem türüne göre farklı consistency kullanılabilir.

Consistent Hashing

Token ring data'yı node'lara dağıtır. Virtual nodes balance'ı iyileştirebilir. Node eklenip çıkarılırken belirli range'ler taşınır. Rebuild ve repair operasyonları network kullanır. Hot partition key yine sorun oluşturabilir.

Multi-Datacenter

Data birden fazla datacenter'da replike edilebilir. Local read/write düşük latency sağlar. Cross-region consistency seviyesi ayrı seçilebilir. Network partition davranışı açık olmalıdır. Repair ve replication health izlenmelidir.

Vitess ile MySQL Sharding

Vitess MySQL'i büyük sharded deployment'larda yönetmek için geliştirilmiş bir platform yaklaşımı sunar. Keyspace logical database alanını, shard fiziksel veri bölümünü temsil eder. Vindex routing key mapping'i sağlar. VTGate application query'lerini doğru shard'a yönlendirir. VReplication online migration ve resharding süreçlerinde kullanılır.

Keyspace

Keyspace uygulamanın logical database alanını temsil eder. Sharded veya unsharded olabilir. Schema yönetimi keyspace seviyesinde planlanabilir. Application connection abstraction bu sınırı kullanır. Birden fazla service farklı keyspace kullanabilir.

Shard

Shard keyspace içindeki veri bölümüdür. Her shard MySQL primary ve replica topolojisine sahip olabilir. Write ve storage kapasitesi dağıtılır. Cross-shard query VTGate üzerinden yürüyebilir. Shard count online değiştirilebilir.

Vindex

Vindex column değerini shard placement'a eşler. Hash veya lookup benzeri farklı türler bulunabilir. Query routing performansını doğrudan etkiler. Access pattern ile uyumlu seçilmelidir. Lookup Vindex ek write maliyeti oluşturabilir.

VTGate

VTGate application query router ve proxy rolü görür. Topology bilgisini kullanarak shard seçer. Birden fazla instance yatay ölçeklenebilir. Cross-shard result merge yapabilir. Latency ve error metriği izlenmelidir.

VReplication

VReplication data migration ve replication workflow'larında kullanılabilir. Source shard'tan target'a change stream taşır. Online resharding mümkün olur. Validation ve cutover workflow'u gerekir. Large migration production I/O ile birlikte test edilmelidir.

Online Resharding

Yeni shard topology production çalışırken hazırlanabilir. Initial copy ve incremental replication yapılır. Traffic switching kontrollü gerçekleştirilir. Source rollback süresi boyunca tutulabilir. Automation manual sharding operasyon yükünü azaltır.

Database Seçerken Manual Sharding mi Native Distribution mı?

Manual sharding mevcut database ve ekip bilgisini korurken routing ve migration sorumluluğunu application platformuna bırakır. Native distributed database bu işlerin büyük kısmını engine içine taşır. Buna karşılık yeni SQL davranışı, transaction semantics ve vendor bağımlılığı oluşabilir. Migration cost ve operasyon ekibi deneyimi önemli kriterlerdir. En doğru seçim mevcut sistemin gerçek kısıtlarına göre yapılmalıdır.

Existing Database

Yıllardır kullanılan database üzerinde büyük domain bilgisi bulunabilir. Tam migration yüksek risk taşır. Manual sharding mevcut tooling'i koruyabilir. Native distribution'a geçiş uzun dual-run gerektirebilir. Legacy contract'lar değerlendirilmelidir.

Migration Cost

Database engine değiştirmek schema ve query migration gerektirir. Driver, backup ve observability araçları değişebilir. Büyük dataset transferi zaman alır. Application behavior shadow test edilmelidir. Toplam proje maliyeti shard platform geliştirmekle karşılaştırılmalıdır.

SQL Requirements

Complex join ve transaction yoğun uygulama manual sharding'de zorlanabilir. Distributed SQL bu semantics'i daha doğal sağlayabilir. Ancak global query latency daha yüksek olabilir. Feature uyumluluğu test edilmelidir. ORM behavior ayrıca doğrulanmalıdır.

Operations Team

Ekip PostgreSQL veya MySQL konusunda güçlü deneyime sahip olabilir. Yeni distributed database farklı on-call becerisi gerektirir. Managed service operasyon yükünü azaltabilir. Manual sharding ise internal platform ekibi gerektirebilir. İnsan kapasitesi teknik tasarımın parçasıdır.

Transaction Requirements

Cross-shard strong transaction sık kullanılıyorsa manual sharding application code'u büyütür. Native distributed transaction avantaj sağlayabilir. Çoğu operation single-shard ise manual model daha basit olabilir. Business invariant'lar listelenmelidir. Performance benchmark kararın parçasıdır.

Vendor Lock-In

Managed distributed platform özel API veya SQL davranışı sunabilir. Migration out maliyeti değerlendirilmelidir. Open protocol ve standard SQL lock-in'i azaltabilir. Manual sharding de internal platform lock-in yaratabilir. Karar yalnızca vendor adına göre verilmemelidir.

Sharding'de En Sık Yapılan Hatalar

Sharding'deki hataların çoğu teknoloji seçiminden önce access pattern ve operasyon planının yetersiz olmasından kaynaklanır. Çok erken shard etmek ekip yükünü gereksiz artırır. Yanlış shard key hot shard ve cross-shard query üretir. Resharding ve tenant move planı olmayan sistem büyüdükçe sıkışır. Router ve schema migration gibi operasyonel alanlar ilk tasarımdan itibaren düşünülmelidir.

Çok Erken Shard Etmek

Küçük dataset için sharding gereksiz complexity ekler. Query optimizasyonu ve vertical scaling yeterli olabilir. Ekip distributed failure senaryolarıyla uğraşmak zorunda kalır. Feature development yavaşlayabilir. Gerçek capacity metric görülmeden shard edilmemelidir.

Access Pattern Analiz Etmeden Shard Key Seçmek

Key yalnızca cardinality'ye göre seçilirse query locality bozulabilir. En sık sorgular shard key taşımayabilir. Fan-out tüm sistemde yaygın hale gelir. Query inventory hazırlanmalıdır. Production trace verisi key seçiminde kullanılmalıdır.

Timestamp ile Hot Shard Oluşturmak

Monotonik time range tüm yeni write'ı tek active shard'a gönderir. Eski shard'lar boşta kalır. Hash bucket eklemek yükü dağıtabilir. Range query merge maliyeti kabul edilmelidir. Hot latest range load test ile görülmelidir.

Cross-Shard JOIN'leri Görmezden Gelmek

Mevcut application sık global join kullanıyorsa shard sonrası büyük performans sorunu yaşanabilir. Related data co-locate edilmelidir. Bazı query'ler analytics sistemine taşınabilir. Migration öncesi query graph çıkarılmalıdır. ORM generated query'ler de incelenmelidir.

Resharding Planı Olmamak

Shard sayısının hiç değişmeyeceğini varsaymak gerçekçi değildir. Dataset ve tenant büyür. Online migration tooling sonradan geliştirmek risklidir. Initial architecture virtual bucket veya directory map bırakmalıdır. Resharding staging'de düzenli test edilmelidir.

Shard Router'ı Tek Hata Noktası Yapmak

Tek router tüm application database erişimini durdurabilir. Stateless router fleet kullanılmalıdır. Metadata service replicated olmalıdır. Load balancer health check hızlı çalışmalıdır. Router capacity N-1 scenario'yu taşımalıdır.

Schema Migration'ı Sonradan Düşünmek

Bir tabloda DDL artık onlarca shard üzerinde uygulanacaktır. Manual script kolayca version drift oluşturur. Migration orchestrator ilk günden kullanılmalıdır. Expand-and-contract standard hale gelmelidir. Dashboard version durumunu göstermelidir.

Tenant Move Stratejisi Olmamak

Tenant büyüdüğünde dedicated shard ihtiyacı doğabilir. Mapping sabit hash formülüne bağlıysa move zorlaşır. Directory overlay çözüm olabilir. Online copy ve CDC tooling hazırlanmalıdır. Büyük müşteri gelmeden önce süreç prova edilmelidir.

Replication'da En Sık Yapılan Hatalar

Replication'ın en yaygın hatası replica'nın primary ile her zaman aynı state'te olduğu varsayımıdır. Async replication doğal lag üretir. Read-after-write problemi ve data loss window tasarımda açıkça ele alınmalıdır. Failover ve split-brain koruması yalnızca configuration ile güvenilir sayılmamalıdır. Backup ihtiyacını replica ile karıştırmak ciddi veri kaybına yol açabilir.

Replica'yı Anında Güncel Sanmak

Write commit sonrası replica henüz değişikliği almamış olabilir. Kullanıcı stale read görür. Lag ölçülmeli ve routing'e dahil edilmelidir. Kritik read primary'den yapılmalıdır. Test environment artificial lag ile davranışı doğrulamalıdır.

Read-After-Write Problemini Görmezden Gelmek

Kullanıcı kendi write'ını göremezse ürün güveni düşer. Permission ve state hataları daha ciddi sonuç yaratabilir. Sticky primary veya session routing uygulanmalıdır. Tüm read replica'ya kör yönlendirilmemelidir. Consistency requirement endpoint bazında tanımlanmalıdır.

Async Replication'da Sıfır Data Loss Beklemek

Async model primary'nin replica beklemeden commit etmesine dayanır. Failover anında son write'lar kaybolabilir. RPO sıfır gerekiyorsa daha güçlü replication seçilmelidir. Gerçek data loss window ölçülmelidir. Business bu riski bilmelidir.

Failover'ı Test Etmemek

Otomatik promotion configuration üzerinde çalışıyor görünebilir. Gerçek client reconnect farklı sorun çıkarabilir. DNS cache ve pool eski primary'yi tutabilir. Game day testleri yapılmalıdır. RTO application perspective'ten ölçülmelidir.

Split-Brain Koruması Olmamak

Network partition iki primary oluşmasına yol açabilir. Quorum ve fencing kullanılmalıdır. Eski primary geri geldiğinde write kabul etmemelidir. Divergent write recovery çok zordur. Failure testleri protection mekanizmasını doğrulamalıdır.

Replica Lag Alert'i Kullanmamak

Replica saatlerce geride kalabilir ve kullanıcıya eski data sunabilir. Failover adayı da güvensiz hale gelir. Lag threshold alert üretmelidir. Read balancer stale node'u çıkarmalıdır. Apply rate root cause bulmaya yardım eder.

Backup Yerine Replica'ya Güvenmek

Yanlış delete replica'ya da kopyalanır. Ransomware veya schema bug tüm kopyaları etkileyebilir. Immutable backup ve PITR gerekir. Restore testleri düzenli yapılmalıdır. Replication availability, backup history korumasıdır.

Production-Ready Sharding Checklist

Production-ready sharding tasarımı shard key, query pattern, operasyon ve observability alanlarını birlikte kontrol etmelidir. Cardinality ve trafik dağılımı gerçek dataset ile ölçülmelidir. Cross-shard query ve global aggregation önceden haritalanmalıdır. Resharding ile backup restore süreçleri test edilmelidir. Hot shard alarmı olmadan distributed kapasite güvenli biçimde yönetilemez.

Shard Key

Shard key production data distribution'ıyla test edilmelidir. Yalnızca örnek birkaç kayıt üzerinden karar verilmemelidir. Query locality ve traffic balance birlikte ölçülür. Büyük tenant senaryosu ayrıca simüle edilir. Key'in gelecekte değiştirilebilirliği değerlendirilir.

Cardinality yeterli mi?

Key yeterince farklı değer üretiyor mu ölçülmelidir. Düşük cardinality shard sayısını sınırlar. Key distribution histogram çıkarılabilir. Null veya default değer yoğunluğu incelenmelidir. Yeni müşteri segmentleri hesaba katılmalıdır.

Trafik eşit dağılıyor mu?

Row sayısı değil gerçek QPS dağılımı incelenmelidir. Hot entity key'in zayıf yönünü gösterebilir. p99 load test önemlidir. Shard başına capacity headroom karşılaştırılır. Gerekirse composite key kullanılır.

Query locality sağlıyor mu?

Kritik OLTP sorguları tek shard üzerinde kalmalıdır. Join edilen aggregate aynı shard'da bulunmalıdır. Global query oranı ölçülür. Query plan routing test edilir. Key yoksa application davranışı belirlenir.

Queries

Sharding öncesi tüm önemli query pattern'leri envantere alınmalıdır. Her query single-shard veya multi-shard olarak sınıflandırılır. Global sort ve pagination ayrıca incelenir. ORM generated query'ler dahil edilmelidir. Yeni feature review sürecine shard-awareness eklenmelidir.

Cross-shard sorgular belirlendi mi?

Production trace üzerinden shard key taşımayan sorgular bulunmalıdır. Her biri için latency ve fan-out maliyeti hesaplanır. Bazıları reference table veya denormalization ile local hale getirilebilir. Analytics query ayrı sisteme taşınabilir. Kalanlar için timeout ve limit uygulanmalıdır.

Global aggregation planı var mı?

Global COUNT ve SUM nasıl üretilecek belirlenmelidir. Per-shard partial aggregation tercih edilebilir. Sık metrikler precompute edilebilir. Warehouse kullanımı değerlendirilebilir. Freshness beklentisi business ile netleştirilmelidir.

Operations

Sharding operation ekibine yeni runbook'lar getirir. Resharding, backup, failover ve schema migration otomatikleştirilmelidir. Her shard'ın owner ve health bilgisi merkezi görünmelidir. Manual adımlar minimum tutulmalıdır. Game day ile operasyon pratiği yapılmalıdır.

Resharding planı var mı?

Yeni shard ekleme ve split prosedürü belgelenmelidir. Online copy ve CDC mekanizması test edilmelidir. Cutover ve rollback kriterleri tanımlanmalıdır. Kapasite threshold migration'ı erken tetiklemelidir. İlk production ihtiyacından önce prova yapılmalıdır.

Backup/restore test edildi mi?

Her shard backup'ı otomatik alınmalıdır. Metadata ve shard map ayrıca korunmalıdır. Tam cluster restore testi yapılmalıdır. RTO ölçülmelidir. PITR global consistency senaryosu doğrulanmalıdır.

Observability

Global dashboard shard-level metrikleri yan yana göstermelidir. Ortalama cluster metric hot shard'ı gizleyebilir. Traffic, storage ve latency skew ayrı izlenir. Resharding progress ve error state görünür olmalıdır. Trace kayıtları shard ID içermelidir.

Shard skew ölçülüyor mu?

Read, write, CPU ve storage için skew ratio hesaplanmalıdır. Median veya average ile en yüksek shard karşılaştırılır. Threshold trend bazlı olabilir. Büyük tenant farklı etiketle izlenir. Skew uzun süre yükseliyorsa rebalancing planlanır.

Hot shard alert'i var mı?

Shard CPU veya p99 belirli sınırı aşınca alarm üretmelidir. Sadece absolute threshold değil relative imbalance da izlenebilir. Alert owner'a doğru routing yapmalıdır. Runbook tenant move veya split seçeneklerini içerir. Tekrarlayan alarm capacity planına dönüşmelidir.

Production-Ready Replication Checklist

Production-ready replication consistency, routing, availability ve recovery kontrollerini birlikte içermelidir. Sync veya async kararı RPO ve latency hedefinden türetilmelidir. Read-after-write politikası açık olmalıdır. Automatic failover split-brain korumasıyla birlikte test edilmelidir. Replica lag ve failover süresi sürekli ölçülmelidir.

Consistency

Hangi read'lerin stale veri kabul ettiği sınıflandırılmalıdır. Critical state primary veya güçlü consistent path kullanmalıdır. Replica lag beklentisi belgelenmelidir. Session guarantee gerekiyorsa uygulanmalıdır. Test ortamında artificial lag oluşturulmalıdır.

Sync/async kararı verildi mi?

Replication modu default ayar olarak bırakılmamalıdır. Business RPO ve p99 write latency değerlendirilmelidir. Cross-region link maliyeti hesaba katılmalıdır. Critical tablo farklı policy kullanabilir. Failure testi garanti seviyesini doğrulamalıdır.

Read-after-write tasarlandı mı?

Kullanıcı write sonrası hangi endpoint'ten okuyacak belirlenmelidir. Sticky primary veya position-based routing seçilebilir. Session state dağıtık application instance'larda çalışmalıdır. Fallback davranışı tanımlanmalıdır. Replica lag spike altında test yapılmalıdır.

Routing

Read ve write endpoint separation açık olmalıdır. Driver ve proxy behavior belgelenmelidir. Transaction içindeki query route değiştirmemelidir. Replica health routing'e dahil edilmelidir. Failover sonrası topology refresh hızlı çalışmalıdır.

Read/write split doğru mu?

Write query replica'ya gitmemelidir. Strong read yanlışlıkla stale replica kullanmamalıdır. Query sınıfları repository seviyesinde tanımlanabilir. Integration test route'u doğrular. ORM magic behavior görünür hale getirilmelidir.

Lag-aware routing var mı?

Replica selection gerçek lag bilgisini kullanmalıdır. Maximum threshold aşıldığında node trafikten çıkarılır. Uygun replica yoksa primary fallback olabilir. Recovery kademeli yapılır. Metric failure durumunda güvenli default seçilir.

Availability

Primary failure otomatik veya hızlı manuel promotion ile yönetilmelidir. Replica sayısı failure domain'lere dağıtılmalıdır. Election ve fencing split-brain'i önlemelidir. Client retry idempotent olmalıdır. RTO application seviyesinde ölçülmelidir.

Automatic failover var mı?

Failure detection, promotion ve endpoint update otomatik olabilir. Her adım ayrı izlenmelidir. False positive riskine karşı quorum kullanılır. Client reconnect testi yapılır. Manual override runbook bulunmalıdır.

Split-brain koruması var mı?

Eski primary fencing ile write dışı bırakılmalıdır. Majority olmayan partition leader olmamalıdır. Lease ve generation token doğrulanmalıdır. Network partition chaos testi yapılmalıdır. Divergent write detection süreci ayrıca hazırlanmalıdır.

Recovery

Replica arızası rebuild ve backup restore planına bağlanmalıdır. Region failure ayrı runbook gerektirir. RPO ve RTO ölçülebilir hedefler olmalıdır. Restore ve failover farklı süreçlerdir. Operator her ikisini düzenli pratik etmelidir.

RPO/RTO tanımlı mı?

Business kabul edilebilir data loss ve downtime değerini açıkça belirtmelidir. Replication topolojisi bu hedefe göre seçilir. Monitoring gerçek değerlere kıyaslanır. Incident sonrası sapma raporlanır. Hedefler düzenli gözden geçirilir.

Failover testi yapılıyor mu?

Scheduled game day primary kill senaryosu çalıştırılmalıdır. Uygulama reconnect süresi ölçülür. Write loss kontrol edilir. Alert ve runbook doğrulanır. Test sonuçları ekip içinde paylaşılır.

Uçtan Uca Ölçeklenebilir Database Mimarisi Nasıl Tasarlanır?

Ölçeklenebilir database mimarisi önce ölçümle başlar, ardından en düşük riskli optimizasyonlardan dağıtık çözümlere ilerler. Access pattern, query plan ve connection davranışı görülmeden topology seçilmemelidir. Read replica consistency ve lag ile birlikte tasarlanır. Sharding write veya storage sınırı gerçekten aşıldığında uygulanır. Son aşamada resharding, failover ve observability sürekli operasyon sürecine dönüşür.

1. Access Pattern'leri Ölçün

Hangi query ne sıklıkta ve hangi tenant için çalışıyor belirlenmelidir. Read/write oranı çıkarılır. Hot key ve global query listelenir. p95 ve p99 latency kaydedilir. Shard key adayları bu veriden doğar.

2. Query ve Index'leri Optimize Edin

En pahalı execution plan'lar incelenir. Full scan ve gereksiz join azaltılır. Composite index gerçek filtre sırasına göre tasarlanır. Kullanılmayan index kaldırılır. Optimize edilmemiş workload dağıtılmamalıdır.

3. Connection Pooling Kurun

Application connection sayısı merkezi bütçeye bağlanır. Pool boyutu instance ve replica sayısına göre hesaplanır. Timeout ve max lifetime ayarlanır. Connection leak metric'i eklenir. Serverless workload için proxy düşünülür.

4. Cache Gereksinimini Değerlendirin

Sık ve stale-tolerant read cache'e alınabilir. Invalidation stratejisi yazılmalıdır. Permission ve financial state cache politikası farklı olabilir. Cache stampede korunmalıdır. Hit ratio gerçek değerle izlenmelidir.

5. Vertical Scale Limitini Ölçün

Daha büyük instance ile performans artışı benchmark edilir. CPU ve I/O ceiling görülür. Maliyet artışıyla kazanım karşılaştırılır. Recovery süresi büyük node'da ölçülür. Horizontal geçiş eşiği belirlenir.

6. Read Replica Ekleyin

Read-heavy workload replica'lara dağıtılır. Reporting ayrı replica kullanabilir. Failover adayı sağlıklı tutulur. Read/write routing test edilir. Lag dashboard hazırlanır.

7. Consistency Modelini Belirleyin

Her read sınıfı strong veya eventual olarak etiketlenir. Read-your-writes gereksinimi belirlenir. Financial ve permission state farklı davranır. Product team stale tolerance tanımlar. Teknik route buna göre uygulanır.

8. Replication Lag'i Ölçün

Time ve log-position lag birlikte izlenebilir. p99 lag read freshness'i gösterir. Stale replica otomatik çıkarılır. Lag spike root cause analizi yapılır. RPO hedefiyle karşılaştırılır.

9. Partitioning Gereksinimini Değerlendirin

Büyük tablolar range veya hash partition ile düzenlenebilir. Query pruning ölçülür. Archive workflow kolaylaştırılır. Partitioning tek node write sınırını çözmez. Yine de sharding ihtiyacını geciktirebilir.

10. Write/Storage Limiti Gerçekten Aşılıyorsa Sharding'e Geçin

Single-node ceiling metric ile kanıtlanmalıdır. Read problemi için sharding yapılmamalıdır. Dataset ve write growth forecast hazırlanır. Migration budget ayrılır. Sharding decision record oluşturulur.

11. Shard Key Adaylarını Test Edin

Birden fazla key production dataset üzerinde simüle edilir. Row ve traffic skew karşılaştırılır. Query locality ölçülür. Büyük tenant senaryosu test edilir. Gelecekteki büyüme modeli eklenir.

12. Cross-Shard Query'leri Haritalayın

Her endpoint single veya multi-shard olarak sınıflandırılır. Global join ve pagination ayrı incelenir. Fan-out maliyeti hesaplanır. Bazı query'ler warehouse'a taşınır. Kritik request mümkün olduğunca local hale getirilir.

13. Shard Router'ı Tasarlayın

Router stateless ve high available olmalıdır. Shard map versionlu tutulur. Local cache kullanılır. Topology refresh failover ve resharding ile uyumlu olur. Routing metric ve trace eklenir.

14. Her Shard İçin Replication Kurun

Her shard single point of failure olmamalıdır. Primary ve replica farklı failure domain'lerde tutulur. Sync veya async policy seçilir. Failover test edilir. Replica lag shard bazında izlenir.

15. Online Resharding Planı Oluşturun

Data copy, CDC ve cutover pipeline geliştirilir. Rollback yolu hazırlanır. Validation automated olur. Migration rate production workload'a göre sınırlandırılır. Test shard üzerinde düzenli prova yapılır.

16. Schema Migration Sürecini Kurun

Expand-and-contract standard hale getirilir. Migration orchestrator shard fleet'i yönetir. Drift detection otomatik çalışır. CI backward compatibility test eder. Long DDL canary ile başlatılır.

17. Failover/Recovery Testleri Yapın

Primary kill, replica loss ve network partition test edilir. RTO ölçülür. Split-brain protection doğrulanır. Backup restore ayrıca test edilir. Runbook ekip tarafından uygulanır.

18. Shard ve Replica Metrics Ekleyin

Per-shard QPS, latency ve storage izlenir. Replica lag ve apply rate eklenir. Global dashboard skew gösterir. Alert ownership doğru ekibe yönlenir. Capacity forecast metric'ten üretilir.

19. Load ve Chaos Testleri Yapın

Normal ve peak trafik çalıştırılır. Hot-key ve cross-shard query test edilir. Resharding sırasında load ölçülür. Failure recovery senaryosu eklenir. p99 SLO doğrulanır.

20. Gerçek Trafik Verisiyle Sürekli Rebalance Edin

Shard dağılımı zamanla değişir. Tenant büyümesi ve yeni feature skew yaratabilir. Placement plan düzenli gözden geçirilir. Hot shard erkenden split edilir. Rebalancing günlük operasyonun doğal parçası haline gelir.

Veritabanı ve Dağıtık Sistemler İçin En İyi Programlama Dili Hangisidir?

Dağıtık database sistemlerinde tek bir en iyi programlama dili yoktur. Go, Java, Python ve Rust farklı tooling ve infrastructure ihtiyaçlarında güçlü yönlere sahiptir. SQL ise query ve data modeling bilgisinin temelini oluşturur. Dil seçiminden daha önemli olan consistency, replication, failure ve networking kavramlarını anlamaktır. Ekip deneyimi ve mevcut ekosistem üretim başarısını sentetik benchmark'tan daha fazla etkileyebilir.

Go

Go network service ve infrastructure tooling geliştirmede sade concurrency modeli sunar. Database proxy ve router projelerinde sık tercih edilir. Static binary deployment operasyonu kolaylaştırabilir. Garbage collection davranışı workload'a göre ölçülmelidir. Dil bilgisi distributed systems bilgisinin yerine geçmez.

Distributed systems

Goroutine ve channel modelleri concurrent service yazmayı kolaylaştırır. Network timeout ve context cancellation doğal API'lerle yönetilebilir. Consensus veya storage algoritması yine derin sistem bilgisi gerektirir. Profiling araçları performans analizine yardım eder. Production failure testleri zorunludur.

Database proxy ve tooling

Stateless proxy ve migration tooling Go ile geliştirilebilir. Connection pooling ve protocol parsing dikkat gerektirir. High concurrency workload benchmark edilmelidir. Backpressure uygulanmalıdır. Observability baştan eklenmelidir.

Java

Java uzun ömürlü enterprise backend ve distributed system ekosistemine sahiptir. JVM güçlü profiling ve concurrency araçları sunar. Büyük database client ve messaging ekosistemi vardır. Memory tuning workload'a göre yapılmalıdır. Modern JVM sürümleri güçlü performans sağlayabilir.

Enterprise backends

Büyük organization'larda Java standard tooling ve platformlarla iyi bütünleşebilir. Transaction ve observability araçları olgundur. Thread veya async model framework'e göre değişir. Connection pool kullanımı kritik kalır. Database scaling mimarisi dilden bağımsızdır.

Cassandra ekosistemi

Cassandra JVM ekosistemiyle güçlü bağlantıya sahiptir. Driver ve operational tooling yaygındır. Data modeling partition key odaklı yapılmalıdır. Heap ve compaction davranışı ayrıca anlaşılmalıdır. Uygulama dili database consistency modelini değiştirmez.

Python

Python data tooling, migration script ve automation için güçlü üretkenlik sağlar. ETL ve validation araçları geniştir. High-throughput proxy için başka dil daha uygun olabilir. Async library'ler I/O tooling'de kullanılabilir. Performans kritik path ölçülmelidir.

Data tooling

Migration verification ve checksum script'leri hızlı geliştirilebilir. Analytics library'leri veri karşılaştırmasını kolaylaştırır. Büyük dataset memory'ye alınmamalıdır. Streaming ve batch processing kullanılmalıdır. Script production safety kontrolleri taşımalıdır.

Automation

Schema migration orchestrator veya operational script Python ile yazılabilir. Idempotency her otomasyonda önemlidir. Retry ve timeout kontrolsüz olmamalıdır. Credential güvenli biçimde alınmalıdır. Dry-run özelliği riskli işlemleri azaltır.

Rust

Rust yüksek performans ve memory safety gerektiren infrastructure yazılımlarında güçlü seçenektir. Database proxy, storage component veya protocol tool geliştirilebilir. Learning curve ekip açısından değerlendirilmelidir. Async runtime davranışı iyi anlaşılmalıdır. Düşük seviyeli performans avantajı ancak doğru mimariyle anlamlıdır.

Yüksek performanslı database infrastructure

Network proxy ve storage engine bileşenlerinde predictable memory davranışı sağlayabilir. Zero-copy teknikleri uygulanabilir. Unsafe kullanım minimum tutulmalıdır. Benchmark gerçek protokol workload'u ile yapılmalıdır. Maintenance becerisi ekip içinde bulunmalıdır.

SQL

Database scaling alanında SQL bilgisi programlama dili kadar önemlidir. Query plan anlamadan sharding problemi doğru teşhis edilemez. Index ve transaction davranışı SQL üzerinden görülür. Distributed SQL bile local query maliyetlerinden etkilenir. Geliştirici EXPLAIN ve execution plan okumayı öğrenmelidir.

Query optimization

Filtre sırası, index kullanımı ve join strategy incelenir. Full scan gerçekten gerekli mi değerlendirilir. Cardinality tahmin hatası fark edilir. Query latency data büyüdükçe test edilir. Optimize sorgu shard başına kapasiteyi artırır.

Data modeling

Schema access pattern'e göre tasarlanmalıdır. Foreign key ve normalization trade-off'u anlaşılmalıdır. Sharding sonrası co-location ihtiyacı modelde yer alır. Global uniqueness requirement sorgulanır. Data lifecycle partitioning kararını etkiler.

Programlama Dilinden Daha Önemli Olan Distributed Systems Temelleri

Network timeout, partial failure ve duplicate delivery her dilde aynı temel problemlerdir. Consistency ve availability trade-off'u syntax ile çözülmez. Idempotency ve observability production güvenilirliğini belirler. Shard key ve transaction sınırı data modelinden gelir. Güçlü distributed systems bilgisi dil değişse bile değerini korur.

Veritabanı Ölçekleme Alanında Yazılımcı Olmak İçin Ne Yapmalı?

Database scaling alanında ilerlemek için SQL ve query plan okumakla başlamak gerekir. Transactions, Linux ve networking bilgisi daha sonra replication davranışını anlamayı kolaylaştırır. Sharding ve distributed systems ileri aşamada öğrenilmelidir. Caching, message queue ve observability bu bilgiyi production mimarisine bağlar. En etkili öğrenme küçük lab ortamlarında failure ve migration deneyleri yapmaktır.

SQL Öğrenmek

SELECT yazmanın ötesinde join, aggregation ve transaction düşüncesi öğrenilmelidir. Query sonucu kadar execution maliyeti önemlidir. Büyük dataset üzerinde sorgu davranışı test edilmelidir. NULL ve isolation semantics anlaşılmalıdır. SQL data access pattern'in temel dilidir.

Index ve Query Planları

B-tree ve composite index temel davranışları öğrenilmelidir. EXPLAIN plan okunmalıdır. Index scan ve sequential scan farkı anlaşılmalıdır. Cardinality ve selectivity test edilmelidir. Over-indexing write maliyeti oluşturur.

Transactions ve ACID

Atomicity, consistency, isolation ve durability kavramları öğrenilmelidir. Isolation level anomaly'leri küçük örneklerle test edilebilir. Lock ve deadlock davranışı incelenmelidir. Cross-shard transaction sonrası neden zorlaştığı daha iyi anlaşılır. Idempotency ile transaction farkı netleşir.

Linux

CPU, memory, filesystem ve process davranışını bilmek database troubleshooting'i kolaylaştırır. I/O metric okunmalıdır. File descriptor ve network socket limitleri anlaşılmalıdır. Container resource limit etkisi görülmelidir. Sistem performansı yalnızca SQL katmanında değildir.

Networking

TCP latency, connection establishment ve packet loss database davranışını etkiler. Cross-region round-trip ölçülmelidir. DNS ve load balancer failover sürecine dahildir. Timeout değerleri network gerçeğine göre seçilir. Network partition distributed systems'in temel failure mode'udur.

Replication

Primary-replica lab kurulabilir. Artificial lag oluşturulabilir. Failover sırasında client behavior gözlenir. Sync ve async farkı ölçülür. Backup ile replication ayrımı pratik edilir.

Sharding

İki veya dört shard ile basit router yazılabilir. Hash ve range dağılımı karşılaştırılır. Hot key senaryosu oluşturulur. Cross-shard query maliyeti ölçülür. Resharding egzersizi yapılır.

Distributed Systems

CAP, quorum ve consensus temelleri öğrenilmelidir. Partial failure örnekleri çalışılmalıdır. Retry ve idempotency birlikte uygulanmalıdır. Saga ve outbox küçük projede denenebilir. Failure test teoriyi kalıcı hale getirir.

Caching

Cache-aside modeli ve invalidation öğrenilmelidir. Stale data etkisi test edilmelidir. Thundering herd korunmalıdır. Hot key cache üzerinden hafifletilebilir. Cache database consistency yerine geçmez.

Message Queues

Queue asynchronous migration ve CDC pipeline'larında önemlidir. At-least-once delivery ve idempotency öğrenilmelidir. Retry, DLQ ve ordering test edilir. Database outbox ile broker bağlantısı kurulabilir. Backpressure burada da temel kavramdır.

Observability

Query latency, replica lag ve shard skew metric olarak toplanmalıdır. Trace query route bilgisini göstermelidir. Log shard ID ve transaction ID içerebilir. Dashboard failure pattern'lerini görünür yapar. Ölçüm olmadan scaling kararı güvenilir değildir.

Open Source ve İşbirliği ile Database Scaling

Database scaling bilgisini geliştirmek için açık kaynak projelerin issue ve design tartışmalarını okumak güçlü yöntemdir. PostgreSQL, MySQL, Vitess, Citus ve Cassandra ekosistemleri gerçek production problemlerini görünür hale getirir. Benchmark ve migration tooling üzerinden küçük katkılar yapılabilir. GitHub issue incelemek failure mode ve backward compatibility düşüncesini geliştirir. Ortak çalışma teknik kararları farklı deneyim seviyelerinden geri bildirimle güçlendirir.

PostgreSQL

PostgreSQL replication, planner ve partitioning konularında geniş açık kaynak tartışmasına sahiptir. Release note okumak davranış değişikliklerini anlamaya yardım eder. Küçük documentation katkısı iyi başlangıçtır. Extension ekosistemi scaling tooling konusunda fikir verir. Test suite kullanımı öğrenilebilir.

MySQL

MySQL replication ve performance konularında güçlü kaynaklara sahiptir. Binlog ve failover davranışı lab ortamında test edilebilir. Community bug raporları edge case'leri gösterir. Query optimizer değişiklikleri sürüm notlarından izlenebilir. Upgrade öncesi compatibility testi önemlidir.

Vitess

Vitess shard routing ve online resharding tasarımlarını açık biçimde inceleme fırsatı sunar. Vindex ve VTGate kodu distributed routing düşüncesini geliştirir. Issue tartışmaları büyük fleet operasyonlarını gösterir. Local lab kurulabilir. Küçük test veya documentation contribution yapılabilir.

Citus

Citus distributed PostgreSQL query ve co-location yaklaşımını öğrenmek için uygundur. Distribution column seçimi pratik edilebilir. Cross-node join maliyeti benchmark edilir. Open source issue'ları gerçek deployment ihtiyaçlarını gösterir. PostgreSQL bilgisiyle distributed model bağlanır.

Cassandra

Cassandra partition key ve quorum yaklaşımını uygulamalı öğrenme sağlar. Multi-node local cluster kurulabilir. Node failure ve repair test edilebilir. Hot partition davranışı simüle edilir. Data modeling query-first mantığı pekişir.

CockroachDB Ekosistemi

Distributed SQL, range distribution ve consensus davranışlarını incelemek için bu ekosistem öğretici olabilir. Transaction ve rebalancing kavramları uygulamalı görülür. Cross-region latency trade-off'ları test edilebilir. Query plan ve locality ayarları incelenebilir. Her distributed database'in kendi operational modeline sahip olduğu görülür.

Benchmark ve Migration Tooling

Open source benchmark script'leri gerçek workload'a uyarlanabilir. Migration checksum veya diff aracı geliştirilebilir. Tool idempotent ve resumable olmalıdır. Metric output standart formatta sunulabilir. Küçük araçlar production deneyimini hızla geliştirir.

GitHub Üzerinden Katkı

Issue reproduction hazırlamak iyi başlangıçtır. Test eklemek kod tabanını anlamayı kolaylaştırır. Pull request review teknik iletişim becerisi kazandırır. Benchmark metodolojisi açık biçimde yazılmalıdır. Düzenli katkı güçlü teknik portföy oluşturur.

Diyarbakır Yazılım Topluluğu İçin Database Scaling Proje Fikirleri

Diyarbakır Yazılım Topluluğu içinde database scaling konularını laboratuvar formatında çalışmak teori ile üretim davranışı arasındaki farkı görmek açısından değerlidir. PostgreSQL replication, read/write splitting ve shard router gibi küçük projeler gerçek failure senaryolarını güvenli ortamda deneme imkanı sunar. Hot-shard dashboard veya distributed failure lab observability kültürünü güçlendirir. Topluluk projelerini https://www.diyarbakiryazilim.com.tr/projects ve topluluk hakkında bilgileri https://www.diyarbakiryazilim.com.tr/about üzerinden incelemek mümkündür. Backend uygulama katmanındaki request akışlarını anlamak isteyenler için https://www.diyarbakiryazilim.com.tr/nest-js-middleware-ve-interceptor-kullanimi içeriği de database erişiminin çevresindeki uygulama davranışını düşünmek açısından tamamlayıcı olabilir.

PostgreSQL Replication Lab

Bir primary ve iki replica ile küçük cluster kurulabilir. Async lag yapay olarak artırılabilir. Read-after-write problemi gözlemlenir. Primary kill ile failover süresi ölçülür. Sonuçlar ortak teknik rapora dönüştürülebilir.

Read/Write Splitting Demo

Basit backend primary ve replica connection pool'ları kullanabilir. Query type'a göre routing yapılır. Sticky primary window uygulanır. Replica lag altında kullanıcı deneyimi test edilir. Dashboard routing oranlarını gösterir.

Sharding Router Projesi

Tenant ID üzerinden dört PostgreSQL shard'a route eden library geliştirilebilir. Hash ve directory map yaklaşımı karşılaştırılır. Cross-shard query bilinçli olarak sınırlandırılır. Tenant move işlemi eklenebilir. Proje distributed data access temelini öğretir.

Hot-Shard Detection Dashboard

Per-shard QPS, CPU ve p99 metric toplanabilir. Skew ratio hesaplanır. Büyük tenant traffic spike simüle edilir. Alert threshold test edilir. Dashboard rebalancing kararına veri sağlar.

Vitess Resharding Atölyesi

Küçük MySQL keyspace üzerinde shard split yapılabilir. Vindex routing incelenir. VReplication ile data move gözlenir. Cutover ve rollback adımları test edilir. Katılımcılar manual sharding ile platform yaklaşımını karşılaştırabilir.

Distributed Database Failure Lab

Primary, replica ve router process'leri kontrollü biçimde kapatılır. Network delay eklenir. Split-brain protection gözlenir. RTO ve data loss ölçülür. Failure sonrası runbook birlikte değerlendirilir.

Open Source Database Tooling Contribution Day

Katılımcılar küçük issue veya documentation task seçebilir. Benchmark veya migration script geliştirebilir. Pull request review birlikte yapılır. Contribution süreci açık kaynak iletişimini öğretir. Düzenli etkinlik teknik öğrenmeyi sürdürülebilir hale getirir.

Sık Sorulan Sorular

Sharding ve replication konusunda en sık sorulan sorular genellikle hangi yöntemin ne zaman kullanılacağı, shard key'in nasıl seçileceği ve failover sırasında hangi garantilerin korunacağı etrafında toplanır. Replication read scaling ve availability sağlarken sharding write ve storage scaling için kullanılır. İki yöntem çoğu büyük sistemde birlikte çalışır. En önemli kararlar consistency, access pattern ve operational readiness üzerinden verilir. Aşağıdaki cevaplar temel kavramları production bakışıyla özetler.

Database sharding nedir?

Database sharding dataset'in satır bazında birden fazla database node'a dağıtılmasıdır. Her shard verinin belirli bölümünü tutar. Böylece storage ve write kapasitesi scale-out yapılabilir. Query router hedef shard'ı shard key üzerinden bulur. Cross-shard işlem ek coordination gerektirir.

Database replication nedir?

Replication aynı verinin birden fazla node'da kopyalanmasıdır. Primary write kabul eder ve değişiklik replica'lara aktarılır. Read scaling ve high availability sağlar. Async model replica lag oluşturabilir. Backup'ın yerine geçmez.

Sharding ile replication arasındaki fark nedir?

Sharding farklı veri parçalarını farklı node'lara dağıtır. Replication aynı verinin kopyalarını birden fazla node'da tutar. Sharding write ve storage scaling sağlar. Replication read scaling ve availability sağlar. Büyük sistemlerde her shard kendi replica setine sahip olabilir.

Partitioning ile sharding arasındaki fark nedir?

Partitioning çoğu durumda aynı database sistemi içindeki table parçalanmasıdır. Sharding veriyi bağımsız database node'larına fiziksel olarak dağıtır. Partitioning transaction ve query planner açısından daha şeffaftır. Sharding routing ve cross-node consistency gerektirir. Partitioning çoğu sistemde sharding öncesi değerlendirilmelidir.

Replication write performansını artırır mı?

Single-leader replication genel olarak primary write kapasitesini artırmaz. Tüm write'lar aynı leader'dan geçer. Replica read workload'u primary'den alarak dolaylı rahatlama sağlayabilir. Gerçek write scale-out için sharding veya farklı write leadership modeli gerekir. Önce query ve transaction optimizasyonu yapılmalıdır.

Read replica nedir?

Read replica primary data'nın kopyasını tutan ve read sorguları kabul edebilen node'dur. Reporting ve normal read trafiğini taşıyabilir. Async replica primary'den geride kalabilir. Read-after-write için primary route gerekebilir. Failover adayı olarak da kullanılabilir.

Replication lag nedir?

Replication lag primary'deki değişiklik ile replica'nın aynı state'e ulaşması arasındaki gecikmedir. Network, CPU ve disk etkileyebilir. Stale read riskinin temel kaynağıdır. Lag threshold routing kararına dahil edilmelidir. Failover adayı replica için düşük tutulmalıdır.

Read-after-write consistency nasıl sağlanır?

Write sonrası read primary'den yapılabilir. Sticky primary window basit yöntemdir. Session routing veya replication position daha hassas çözümler sunar. Lag-aware replica seçimi kullanılabilir. Business consistency ihtiyacı yöntemi belirler.

Shard key nasıl seçilir?

Shard key yüksek cardinality ve dengeli trafik sağlamalıdır. Sık query'lerde bulunmalıdır. Related data'yı aynı shard'da tutması faydalıdır. Büyük tenant ve future growth simüle edilmelidir. Tek bir teknik formül tüm sistemler için doğru değildir.

Hot shard nedir?

Hot shard trafiğin veya verinin tek shard üzerinde aşırı yoğunlaşmasıdır. CPU ve I/O doygunluğu oluşabilir. Celebrity user veya büyük tenant sebep olabilir. Hash, composite key veya shard split çözüm olabilir. Per-shard metrikler problemi görünür yapar.

Hash-based ve range-based sharding arasındaki fark nedir?

Hash-based yöntem key'leri daha dengeli dağıtır ve point query için iyidir. Range-based yöntem benzer değerleri aynı shard'da tutar. Range query range sharding'de daha verimlidir. Monotonik write hot range oluşturabilir. Workload access pattern seçimde belirleyicidir.

Consistent hashing nedir?

Consistent hashing topology değişikliğinde daha az key'in yeni node'a taşınmasını hedefler. Hash ring ve virtual node kullanılabilir. Node ekleme daha kontrollü olur. Gerçek data transferi yine gerekir. Rebalancing production kapasitesini etkiler.

Cross-shard query nedir?

Bir query'nin birden fazla shard'a erişmesi cross-shard query'dir. Router fan-out yapar ve sonuçları birleştirir. Latency en yavaş shard'a bağlı olabilir. Global sort ve aggregation maliyetlidir. Query locality iyi shard key ile artırılmalıdır.

Cross-shard transaction nasıl yapılır?

Strong atomicity gerekiyorsa 2PC veya native distributed transaction kullanılabilir. Bu yaklaşım latency ve blocking maliyeti taşır. Saga local transaction ve compensation modeli sunar. Business requirement eventual consistency kabul ediyorsa daha esnek olabilir. Data co-location en iyi önlemdir.

Resharding nedir?

Resharding mevcut data distribution'ı yeni shard yapısına taşımaktır. Shard split, merge veya key değişimi içerebilir. Initial copy ve incremental replication kullanılır. Validation sonrası traffic cutover yapılır. Online resharding kullanıcı kesintisini azaltır.

Shard key sonradan değiştirilebilir mi?

Evet, ancak çoğu durumda büyük data migration gerekir. Yeni key'e göre tüm kayıtlar yeniden yerleştirilir. Application routing de değişmelidir. Online resharding kesintiyi azaltabilir. Native database özellikleri operasyonu kolaylaştırabilir.

Sharding ve replication birlikte kullanılabilir mi?

Evet ve büyük production sistemlerinde bu oldukça yaygındır. Her shard ayrı primary ve replica grubuna sahip olabilir. Sharding write ve storage scale sağlar. Replication read capacity ve high availability ekler. Router iki seviyeli seçim yapar.

PostgreSQL sharding destekler mi?

PostgreSQL native table partitioning ve replication özellikleri sunar. Manual sharding application veya middleware ile uygulanabilir. Citus gibi distributed PostgreSQL çözümleri kullanılabilir. Logical replication migration ve data distribution süreçlerine yardım edebilir. Seçim transaction ve query ihtiyacına göre yapılmalıdır.

MongoDB resharding nasıl çalışır?

MongoDB cluster yeni shard key veya dağılıma göre veriyi yeniden yerleştirebilir. Existing data target distribution'a taşınır. Migration boyunca değişikliklerin senkron tutulması gerekir. Balancer ve config metadata sürecin parçasıdır. Gerçek davranış kullanılan sürüm ve cluster configuration'a göre test edilmelidir.

Sharding ne zaman gereksizdir?

Query ve index optimizasyonu yapılmadan sharding çoğu zaman gereksizdir. Tek node write ve storage kapasitesi yeterliyse vertical scaling daha basit olabilir. Read problemi replica ile çözülebilir. Büyük tablo partitioning ile yönetilebilir. Sharding ancak gerçek distributed capacity ihtiyacı varsa uygulanmalıdır.

Veritabanı mimarisinde ölçeklenebilirlik için Sharding ve Replication nasıl kullanılır?

Replication aynı verinin birden fazla kopyasını oluşturarak read scaling ve high availability sağlar. Sharding dataset'i farklı node'lara bölerek write ve storage kapasitesini artırır. Büyük sistemlerde her shard kendi replica grubuna sahip olabilir. Router önce shard'ı, ardından query'nin primary veya replica üzerinde çalışacağını seçer. Bu kombinasyon yüksek trafikli sistemlerde horizontal scaling ile failure tolerance'ı birlikte sunar.

Sharding ile Replication arasındaki farklar nelerdir ve hangi durumda hangisi tercih edilmelidir?

Read trafiği ve failover ihtiyacı baskınsa replication genellikle ilk yatay adımdır. Primary write veya tek node storage limiti gerçek sorun haline geldiyse sharding değerlendirilir. Replication dataset'i bölmez, yalnızca kopyalar. Sharding ise veriyi böler ve query routing ihtiyacı oluşturur. Pek çok production mimaride iki yöntem birbirinin alternatifi değil tamamlayıcısıdır.

Sharding yapılırken doğru shard key nasıl seçilir ve veri dağılımı nasıl dengelenir?

Shard key yüksek cardinality, dengeli trafik ve query locality sağlamalıdır. Gerçek production access pattern'leri aday key'lerle simüle edilmelidir. Büyük tenant, celebrity user ve monotonik timestamp gibi hot shard senaryoları ayrıca test edilmelidir. Composite key, hashing veya directory-based placement kullanılabilir. Veri ve trafik dağılımı resharding sonrasında bile sürekli ölçülmelidir.

Replication lag, veri tutarlılığı ve failover sorunları yüksek trafikli veritabanlarında nasıl yönetilir?

Replica lag sürekli ölçülmeli ve belirli eşik üzerindeki node read trafiğinden çıkarılmalıdır. Read-after-write gereken sorgular primary'ye yönlendirilmelidir. Failover quorum, promotion ve fencing mekanizmalarıyla split-brain riskine karşı korunmalıdır. RPO ve RTO business requirement olarak tanımlanmalıdır. Primary kill, network partition ve slow replica senaryoları düzenli chaos test ile doğrulanmalıdır.

Veritabanı Sharding ve Replication mimarisi konusunda yakınımda danışmanlık veya eğitim nerede bulabilirim?

Veritabanı ölçeklendirme ve DBA danışmanlığı yakınımda gibi yerel aramalarda teknik topluluklar, uygulamalı workshoplar ve gerçek proje çalışmaları güçlü başlangıç noktalarıdır. Diyarbakır Yazılım Topluluğu'nun teknik çalışmalarını https://www.diyarbakiryazilim.com.tr üzerinden takip edebilirsiniz. Eğitim veya danışmanlık değerlendirilirken yalnızca teorik sharding anlatımı değil, replication lag ölçümü, failover testi, shard key analizi ve online resharding pratiği bulunmasına dikkat etmek gerekir. Kurumsal veritabanı sharding replication ve ölçeklendirme hizmeti için hazırlanacak çalışma planının gerçek access pattern ve kapasite metrikleriyle başlaması daha sağlıklı sonuç verir. En iyi öğrenme modeli gerçek workload'u küçük laboratuvar ortamında ölçmek, hata senaryoları oluşturmak ve sonuçları deneyimli geliştiricilerle birlikte değerlendirmektir.

Sonuç: Ölçeklenebilir Veritabanı Mimarisinde Doğru Sharding ve Replication Kararı

Veritabanı Mimarisinde Ölçeklenebilirlik: Sharding ve Replication konusu güçlü database altyapısının yalnızca daha fazla node eklemekten ibaret olmadığını gösterir. İlk adım her zaman query, index, connection ve gerçek kapasite sınırlarını ölçmektir. Read trafiği replica ile dağıtılabilirken write ve storage ceiling gerçekten aşıldığında sharding devreye alınmalıdır. Shard key, replication lag, failover, backup ve resharding süreçleri ilk production gününden önce test edilmelidir. Database mimarisi, backend performansı ve dağıtık sistem çalışmaları hakkında teknik içerik ve topluluk projelerine ulaşmak için https://www.diyarbakiryazilim.com.tr adresini takip edebilirsiniz.