1. GİRİŞ

Veri, modern yazılım sistemlerinin omurgasıdır. Doğru tasarlanmış bir database architecture; performans, ölçeklenebilirlik, dayanıklılık, maliyet ve güvenlik arasındaki kritik dengeyi sağlar. Bulutun yaygınlaşması, mikroservis mimarileri, gerçek zamanlı uygulamalar ve yapay zekâ uygulamalarındaki büyüme veri katmanına yönelik beklentileri değiştirdi. Artık veriyi sadece saklamak değil; erişim modelini, tutarlılık garantilerini, yedekleme ve felaket senaryolarını, maliyet ve gecikme optimizasyonunu da tasarlamak gerekiyor.

Bu konu neden bugün konuşuluyor?

Veri hacimleri ve erişim gereksinimleri hızla artıyor. Gerçek zamanlı analiz, global kullanıcı dağılımı, regülasyonlar (GDPR vb.) ve maliyet baskıları, veritabanı seçimlerinin ve mimari kararların işletme başarısına doğrudan etkide bulunmasını sağlıyor. Ayrıca mikroservislerin benimsenmesiyle birlikte veritabanı sınırları, ownership ve entegrasyon desenleri yeniden değerlendirilmelidir.

Kimler için önemli?

• Çözüm mimarları ve veri mimarları
• Backend geliştiriciler ve veri mühendisleri
• Platform, SRE ve DevOps ekipleri
• CTO, ürün yöneticileri ve güvenlik/uyum ekipleri

Hangi problemleri çözüyor?

• Veri tutarlılığı ve erişilebilirlik gereksinimlerini karşılamak
• Performans hedeflerini (low latency, high throughput) sağlamak
• Ölçeklenebilirlik ve maliyet optimizasyonu sunmak
• Yedeklilik, felaket kurtarma ve veri bütünlüğünü temin etmek

2. KAVRAMSAL TEMELLER

Bu bölümde database architecture ile ilgili temel kavramlar, terminoloji ve bileşenler açıklanacaktır. Net tanımlar, doğru seçimleri ve trade-off'ları değerlendirmeye yardımcı olur.

2.1. Temel Kavramlar

• OLTP (Online Transaction Processing): Kısa, tutarlı işlemler; yüksek concurrency ve düşük latency gerektirir. Örnek: ödeme işlemleri.
• OLAP (Online Analytical Processing): Büyük hacimli sorgulama, toplulaştırma ve raporlama. Genelde batch veya kolon tabanlı depolama uygundur.
• ACID: Atomicity, Consistency, Isolation, Durability — tutarlılık garantileri sağlayan klasik transaction modeli.
• BASE: Basically Available, Soft state, Eventual consistency — dağıtık sistemlerde esnek tutarlılık yaklaşımı.
• Sharding: Veritabanının yatay olarak bölünmesi; veri parçalara ayrılarak paralel işleme olanak verir.
• Replication: Verinin birden çok kopyasının tutulması; yüksek erişilebilirlik ve ölçeklendirme sağlar (read replicas).
• Indexing: Sorgu performansı için veri üzerinde oluşturulan yapı; doğru index tasarımı performansı dramatik arttırır.

2.2. Mimari Bileşenler

• Primary/Leader: Yazma işlemlerinin yönlendirildiği ana düğüm.
• Replica/Follower: Okumalar ve yedekleme için kullanılan kopyalar.
• Proxy / Connection Pooler: Bağlantı yönetimi, sorgu yönlendirme ve failover işlemleri.
• Coordination Service: Consul, ZooKeeper veya etcd gibi dağıtık koordinasyon ve konfigürasyon yönetimi.

3. NASIL ÇALIŞIR?

Bu bölüm teknik mimarinin detaylarını içerir: hangi bileşenler nasıl etkileşir, veri akışı nasıl gerçekleşir ve hangi tasarım desenleri hangi ihtiyaçlara cevap verir.

3.1. Veri Katmanının Temel Modelleri

Monolitik RDBMS

Tek bir ilişkisel veritabanı (ör. PostgreSQL, SQL Server) başlangıç için kolaydır: güçlü ACID garantileri, zengin sorgu yetenekleri ve olgun ekosistem sunar. Ancak yatay ölçeklendirme sınırlıdır; yüksek yazma hacimlerinde sharding veya partitioning gerekir.

Microservice-özel Veritabanları

Her mikroservisin kendi veri mağazası (database per service) prensibi, servis bağımsızlığını ve takım otonomisini artırır. Ancak veri bütünlüğü ve çapraz servis sorgulamaları daha karmaşık hale gelir; event-driven ve sagas pattern'leri tercih edilir.

NoSQL & Polyglot Persistence

Anahtar-değer, belge (document), kolon ve grafik veri tabanları farklı kullanım durumlarına uygundur. Örneğin, yüksek yazma/okuma için Cassandra, belge odaklı model için MongoDB, ilişki ve yoğun sorgulama için RDBMS, doğal ilişki keşfi için graph DB (Neo4j) tercih edilebilir.

3.2. Replikasyon ve Tutarlılık Seçimleri

Replikasyon topolojisi (master-slave, leaderless, multi-leader) ve tutarlılık mekanizmaları (strong vs eventual) uygulamanın ihtiyaçlarına göre seçilmelidir. Örnekler:

• Single-leader replication: Yazma tek lidere; read replica ile ölçeklendirme. Basit failover prosedürleri fakat leader bottleneck olabilir.
• Multi-leader replication: Birden fazla yazma noktası; geo-distributed yazma senaryolarında fayda sağlar fakat çakışma çözümü gerekir.
• Leaderless (gossip) replication: Cassandra gibi sistemlerde eventual consistency varsayılır, yüksek yazma throughput sağlanır.

3.3. Sharding ve Partitioning

Sharding veri setini yatay parçalara bölerek ölçeklenmeyi sağlar. Tasarım kararları:

• Shard key seçimi: Düşük cardinality veya kötü seçilmiş shard key hotspot'lara yol açar. İyi seçim request routing ve balance sağlar.
• Rebalancing: Düğümler arasında veri yeniden dağıtımı, online veya offline olabilir; operational complexity yüksektir.
• Partitioning: RDBMS içinde range veya hash partitioning ile performansı iyileştirme.

3.4. Caching ve Denormalization

Cache (Redis, Memcached) önbellekleme ve denormalization sorgu performansını ciddi biçimde artırır. Ancak cache invalidation (geçersiz kılma) ve veri tutarlılığı sorunları yönetilmelidir. Denormalize edilmiş verilere yazma sırasında event veya CDC (Change Data Capture) ile güncelleme yaygın bir pratiktir.

3.5. Event-driven Data Architecture

Mikroservislerin veri tutarlılığını korumak için event sourcing, change data capture ve event streaming (Kafka gibi) yaygın kullanılır. Bu desenlerde veri değişiklikleri olay olarak yayımlanır; farklı servisler bu olayları subscribe ederek kendi local state'lerini günceller.

3.6. Backup, Snapshot ve Disaster Recovery

Yedekleme stratejileri RPO (Recovery Point Objective) ve RTO (Recovery Time Objective) gereksinimlerine göre belirlenir. Örnekler:

• Continuous replication ile near-zero RPO
• Point-in-time recovery için WAL/transaction log arşivleme
• Cross-region replication ve failover playbook'ları

4. GERÇEK DÜNYA KULLANIMLARI

Aşağıda büyük teknoloji şirketlerinin veri mimarisinde öne çıkan tercihleri ve nedenleri özetlenmiştir. Her şirketin ihtiyaçları farklıdır; ancak ortak temalar ölçeklenebilirlik, düşük latency ve güvenilirliktir.

Netflix

Çok yüksek read yoğunluğu ve global dağıtım gerektirdiği için Netflix, edge cache, CDN ve local replicated stores kullanır. Müşteri deneyimi için read-through cache ve read replicas yoğun olarak kullanılır.

Uber

Gerçek zamanlı talepler ve düşük latency zorunluluğu nedeniyle Uber, in-memory ve geo-aware data grids ile çalışır; ayrıca özel sharding stratejileriyle hotspot'ları önler.

Amazon (AWS)

AWS hem ilişkisel hem de NoSQL çözümleri (RDS, DynamoDB) sunar; müşteri ihtiyaçlarına göre managed hizmetler ve multi-AZ replication seçenekleri ile operasyonel karmaşıklığı azaltır.

OpenAI

Model eğitim ve inference verileri büyük hacimlidir; object storage, vector database ve distributed cache'lerin bir arada kullanımı ve veri pipeline'larının performans odaklı tasarımı önemlidir.

Stripe

Ödeme işlemleri yüksek tutarlılık ve idempotency gerektirir. Stripe benzer ticari uygulamalar gibi ACID garantilerini güçlü tutmak adına RDBMS ve transaction modellenmesine önem verir, aynı zamanda analitik için ETL pipelineleri kullanır.

5. AVANTAJLAR VE SINIRLAMALAR

Avantajlar

• Doğru mimari ile performans ve ölçeklenebilirlik gereksinimleri dengelenebilir.
• Replikasyon ve sharding yüksek erişilebilirlik ve paralel işleme sağlar.
• Event-driven mimariler servisler arasında gevşek bağlılığı ve asenkron entegrasyonu mümkün kılar.

Sınırlamalar

• Dağıtık veri tutarlılığı karmaşıktır ve uygulama seviyesinde tasarım gerektirir.
• Sharding, rebalancing ve failover operasyonel açıdan maliyetlidir.
• NoSQL seçimleri esneklik sağlasa da bazı sorgu türlerinde sınırlamalar getirir.

6. ALTERNATİFLER VE KARŞILAŞTIRMA

Bu bölümde yaygın veri mağazalarını ve yaklaşımlarını avantaj ve dezavantajlarıyla karşılaştırıyoruz.

7. EN İYİ PRATİKLER

Burada üretimde uygulanması gereken öneriler var; kod örneği yoktur. Mimari, operasyon ve güvenlik tavsiyelerine odaklanıyoruz.

Production Kullanımı

• Veri ownership: Hangi servisin hangi veriye sahip olduğu net olsun (database per service).
• Schema evolution: backward/forward compatible migration stratejileri (blue-green, online schema changes).
• Observability: query latency, slow queries, lock/DB wait metrics, replication lag sürekli izlenmeli.

Performans Optimizasyonu

• Indexing stratejisini sorgu profiline göre tasarlayın; gereksiz index eklemek yazma maliyetini artırır.
• Denormalize ve materialized views ile okuma performansını iyileştirin; write path'lerde event-driven update planlayın.
• Connection pooling ve prepared statements kullanın; long-running transactions'dan kaçının.

Güvenlik

• Encryption at-rest ve in-transit; KMS ve per-tenant encryption stratejileri.
• Least privilege: veri erişimi rol/tabanlı olarak sınırlandırılmalı.
• Audit logging ve immutable storage: regülasyon uyumu için gerekli.

Ölçeklenebilirlik ve Operasyon

• Shard ve replica planlarını test edilmiş rebalancing prosedürleriyle uygulayın.
• Backup ve DR planlarını düzenli test edin (failover drills).
• Capacity planning: büyüme trendlerini izleyerek önceden provisioning yapın.

8. SIK YAPILAN HATALAR

• Başlangıçta tüm veriyi tek bir RDBMS'e koymak ve ölçeklendirme zamanı gelene kadar mimari düşünmemek.
• Yanlış shard key seçimi: hotspot'lar ve düzensiz dağılım performansı bozar.
• Index'leri sorgulamadan eklemek: write path performansının düşmesine yol açar.
• Backup/DR planlarını test etmemek; kurtarma süresi gerçek felakette bilinmez olur.
• Veri gizliliği ve erişim kontrollerini göz ardı etmek; regülasyonlara uymama riski.

9. GELECEK TRENDLER

AI ve Veri Katmanı

AI ve ML, veritabanı yönetiminde otomatik indeks önerileri, sorgu optimizasyonu ve anomaly detection için kullanılacak. Otomatik tuning ve self-driving database'ler daha yaygın hale gelecektir.

Vector Databases ve Semantic Search

Özelikle yapay zekâ uygulamaları için vektör tabanlı veri tabanları (Pinecone, Milvus, FAISS-tabanlı çözümler) semantic retrieval ve RAG senaryolarında kritik rol oynayacaktır.

Serverless ve Managed Data Services

Serverless veri hizmetleri (serverless databases, serverless data warehouses) operasyonel yükü azaltacak ve tüketim tabanlı maliyet modelini genişletecektir. Ancak cold start ve performans garantileri dikkatle yönetilmelidir.

Global Data Mesh ve Data-as-a-Product

Veri ürünleştirme ve data mesh yaklaşımları, domain-driven veri ownership ile veri erişimini ve kaliteyi iyileştirecek; governance ve discoverability öne çıkacaktır.