SQL, NoSQL ve Redis Arasında Seçim: Kurumsal Veri Mimarisini Erişim Modelinden Kurmak

“SQL mi NoSQL mi?” sorusu, kurumsal bir sistem için yanlış soyutlama düzeyindedir. Asıl seçim relational model ile document model arasında değil; belirli bir verinin nasıl yazıldığı, hangi sınırlar içinde consistent kalması gerektiği, hangi sorgularla okunduğu ve partition sırasında hangi davranışın kabul edildiği arasındadır. PostgreSQL, MSSQL, Redis veya Elasticsearch bu gereksinimlerin ardından gelir.

Bu ayrım mimarinin hata davranışını belirler. Aynı sipariş kaydını üç database'e eşit otoriteyle yazmak ile PostgreSQL'i system of record tutup Redis ve Elasticsearch'i türetilmiş read model olarak kullanmak, kutu diyagramında benzer görünebilir ama failure durumunda tamamen farklı sistemler üretir. Verilecek karar, “hangi database daha iyi?” değil, her veri sınıfının authoritative store'unun hangisi olduğu ve diğer store'ların ondan nasıl beslendiğidir.

Erişim modeli **store** seçimini belirler

Relational model, entity'ler arasındaki ilişkileri constraint, key ve transaction sınırlarıyla ifade eder. Bir ödeme kaydının siparişe bağlı olması, stok düşümüyle birlikte atomik bir business invariant korunması veya finansal kayıtların belirli bir state transition sırasını izlemesi gerekiyorsa PostgreSQL ya da MSSQL doğal adaydır. SQL burada yalnızca sorgu dili değildir; schema ve transaction mekanizmaları veri bütünlüğünü database sınırında uygular.

Document database farklı bir problemi iyi çözer. Bir aggregate çoğunlukla bütün olarak okunup yazılıyor, alan yapısı kayıt tipine göre değişiyor ve join yerine aggregate sınırı üzerinden erişiliyorsa document model erişim modeline uyabilir. “Schema yok” gerekçesi ise zayıftır: uygulama verinin biçimine yine bağımlıdır, dolayısıyla schema enforcement database'den application code'a kaymış olur.

Key-value store daha dar bir sözleşme sunar: bilinen bir key ile value bulunur. Redis bu modelin yanında TTL, çeşitli data structure'lar ve hızlı memory erişimi sağladığı için session, rate limit state, kısa ömürlü hesaplanmış sonuç veya cache için güçlüdür. Bu özellikler Redis'i transactional system of record'un otomatik alternatifi yapmaz; durability ve consistency beklentileri kullanım biçimine göre ayrıca tasarlanmalıdır.

Elasticsearch de genel amaçlı primary database seçimi olarak başlamamalıdır. Inverted index, full-text search, ranking ve denormalized search document'ları için tasarlanmış bir search engine'dir. Kullanıcıların ürün adı, açıklaması ve özellikleri üzerinde arama yapması gerekiyorsa uygun olabilir; siparişin ödenip ödenmediğine dair authoritative kararın Elasticsearch document'ından verilmesi ise index gecikmesini business consistency problemine dönüştürür.

Read-heavy ve write-heavy ayrımı da ürün etiketinden daha somut olmalıdır. Read-heavy bir endpoint cache veya replica ile ölçeklenebilirken, write-heavy bir workload index maintenance, replication ve partition key seçiminin maliyetini daha görünür kılar. “NoSQL write için hızlıdır” gibi genellemeler, write amplification ve gereken consistency seviyesini belirtmeden mimari karar taşıyamaz.

Veri sahipliği **consistency** sınırını belirler

Consistency, bütün kopyaların her an aynı byte'ları taşıması gibi belirsiz bir hedef olarak ele alınmamalıdır. Önce business invariant tanımlanır: örneğin “aynı ödeme iki kez capture edilmemeli” güçlü bir transaction sınırı isteyebilirken, yeni ürün açıklamasının search sonuçlarına birkaç saniye sonra düşmesi kabul edilebilir. Gereken consistency store bazında değil, karar bazında seçilir.

Partitioning ve replication bu tercihin fiziksel sonuçlarını ortaya çıkarır. Replication availability ve read capacity sağlayabilir, fakat replica lag stale read üretir; partitioning data ve load'u dağıtır, fakat yanlış partition key hotspot yaratabilir ve cross-partition operation'ları pahalılaştırabilir. Network partition sırasında her isteğe başarı cevabı vermek ile tek bir güncel değer üzerinde uzlaşmak aynı anda garanti edilemez; sistem hangi operation'ın bekleyeceğini veya başarısız olacağını açıkça seçmelidir.

Bu nedenle polyglot persistence, aynı veriyi rastgele birçok teknolojiye dağıtmak değildir. Terim, farklı persistence modellerini farklı erişim gereksinimleri için birlikte kullanmak demektir; güvenli uygulamasında ise her business fact için sahiplik belirgindir. Çoğu kurumsal sistemde karmaşıklığı kontrol altında tutan ayrım primary data ile derived data arasındadır.

Bir e-ticaret ekibinin sipariş detay endpoint'ini düşünün. Sipariş kaydı ve ödeme state'i PostgreSQL'dedir; application sık okunan sipariş görünümünü Redis'te kısa TTL ile cache'ler ve ürün metnini Elasticsearch'e index'ler. Müşteri hizmetleri uzmanı bir iade kararı verdiğinde write PostgreSQL'e commit edilir; ardından event veya outbox kaydı Redis'teki ilgili cache key'inin invalidation'ını ve Elasticsearch'teki gerekiyorsa yeni projection'ı tetikler.

Bu akışta Redis geçici olarak eski değer döndürebilir, Elasticsearch index'i de geriden gelebilir. İade tutarını belirleyen operation bu nedenle cache veya search index'e güvenmez; authoritative state'i PostgreSQL'den okur ya da aynı transaction'ın ürettiği sonucu kullanır. Store rolleri böyle ayrılınca eventual consistency bir sürpriz değil, belirlenmiş bir sınır olur.

Veri sıcaklığı **cache** politikasını belirler

Cache Aside, application'ın önce cache'i kontrol ettiği, miss durumunda authoritative store'dan okuyup sonucu cache'e yazdığı pattern'dir. Redis bu pattern için sık kullanılır çünkü key lookup hızlıdır ve TTL doğal bir expiration mekanizması sağlar. Fakat cache performans katmanıdır; hangi kaydın doğru olduğuna karar veren yeni bir source of truth olmamalıdır.

Cache invalidation'ın zorluğu silme çağrısının kendisinde değil, write ile invalidation arasındaki yarışlarda yatar. Database commit başarılı olup Redis invalidation başarısız olursa stale data TTL bitene kadar yaşayabilir; invalidation commit'ten önce gerçekleşirse eşzamanlı bir reader eski database değerini yeniden cache'leyebilir. Transactional outbox, idempotent consumer ve uygun TTL gibi mekanizmalar bu failure window'u yönetir, fakat sıfırlamaz.

Hot data, sık veya latency-sensitive erişilen working set'tir; cold data ise seyrek erişilir ve daha ucuz storage ya da farklı retention politikalarıyla tutulabilir. Bu ayrım yalnızca yaşa göre yapılmamalıdır: yıllık bir müşteri kaydı her request'te okunuyorsa hot olabilir, dün üretilmiş bir audit file ise operasyonel path dışında cold kalabilir. Redis'e ne konacağını data age değil, access frequency, latency hedefi ve yeniden üretme maliyeti belirlemelidir.

Cache hit ratio tek başına başarı ölçüsü de değildir. Büyük ama ucuz sorguları cache'lemek memory tüketirken küçük fakat pahalı bir authorization projection'ı daha değerli olabilir. Ayrıca cache stampede, hot key ve memory eviction davranışları capacity planına dahil edilmelidir; aksi halde Redis ana database üzerindeki yükü azaltmak yerine failure anında yükü katlayan bir bağımlılığa dönüşebilir.

Açık sahiplik **polyglot persistence** kararını belirler

Kurumsal sistem için varsayılan tercih, business transaction'ları ve güçlü invariant'ları relational store'da tutmak; Redis'i ölçülmüş latency veya load problemi bulunan geçici erişimler için; Elasticsearch'i gerçek search gereksinimleri için eklemektir. Document database ise aggregate biçimi ve access pattern gerçekten document model ile uyuştuğunda seçilmelidir. PostgreSQL ya da MSSQL ile başlamak, her problemi relational database'e zorlamak anlamına gelmez; ek store için kanıt gerektiren bir complexity budget belirler.

Bu öneri, dominant workload relational transaction'lardan uzaklaştığında geçerliliğini kaybeder. Çok yüksek write throughput, doğal ve dengeli bir partition key, aggregate-local operation'lar veya relational constraint gerektirmeyen document erişimi başka bir primary store'u daha doğru kılabilir. O noktada da yöntem değişmez: önce authoritative data, consistency boundary ve failure davranışı tanımlanır; teknoloji bunların ardından seçilir.