1. Giriş: Kaosun Ortasında Tutarlılık Aramak
Kripto para piyasası, geleneksel finansın aksine saniyelerle ölçülen volatiliteye sahip, 7/24 yaşayan ve hata toleransının sıfıra yakın olduğu bir ekosistemdir. Bu kaotik veri denizinde, bir finans platformunun "gerçeği" temsil eden sembol kataloğu, sistemin temel taşıdır. Yanlış bir parite verisi veya eksik bir listeleme, sadece teknik bir aksaklık değil, finansal bir kayıptır.
HemenBasvur platformundaki sembol verilerini yöneten servisin(SymbolService) mimarisi, CoinGecko ve CoinAPI gibi dev sağlayıcılardan binlerce satırlık veriyi toplarken çok temel bir mühendislik paradoksuyla yüzleşiyor: Hizmet kesintisi yaşatmadan, dağıtık sistemlerde veri tutarlılığını nasıl garanti ederiz? Bu yazı, bir servisin çökme anında bile nasıl "doğru" kalabildiğini, modern bir sistem mimarının gözünden beş temel dersle inceliyor.
2. A/B Koleksiyon Değişimi: Görünmez Bir "Sıfır Kesinti" Sanatı
Yüksek trafikli sistemlerde canlı verinin üzerine yazmak (in-place update), "kirli okuma" (dirty read) ve kısmi veri bozulması risklerini beraberinde getirir. SymbolService, bu riski MongoDB üzerinde kurgulanan A/B koleksiyon değişimi (swap) ve atomik durum geçişi ile bertaraf eder.
Mimari, veriyi o an aktif olan koleksiyona değil, pasif duran "next suffix" koleksiyonuna yazar. Ancak asıl sihir, yazma işlemi bittikten sonra gerçekleşir. Aktif koleksiyonun bilgisini tutan meta kayıt(SymbolsSnapshotMeta) belgesi üzerinde tek bir atomik FindOneAndUpdate komutuyla hem aktif koleksiyonu belirleyen alan(ActiveSuffix) (A/B) değiştirilir hem de veri kümesinin sürüm numarası(SnapshotVersion) monotonik olarak artırılır.
"Eski koleksiyona işaret eden artırılmış bir versiyonun okunabileceği bir pencere yoktur."
Kıdemli bir gözle bakıldığında, burada dikkat edilmesi gereken bir "artık risk" (residual risk) mevcuttur: MongoDB'deki mevcut pasif koleksiyonun temizlenmesi(ClearAsync) ve yeni kayıtların koleksiyona toplu olarak eklenmesi(AddRangeAsync) işlemleri bir transaction içinde değildir. Eğer süreç adım aktif koleksiyonun değiştirildiği meta güncellemesinden(atomik swap) hemen önce çökerse, pasif koleksiyon boş kalabilir. Bu yüzden dayanıklı bir mimari, sadece kod mantığına güvenmez; başlangıçta (startup health-check) aktif koleksiyonun boş olmadığını doğrulayan güvenlik bariyerleri kurar.
3. "Hiçbir Şey Yapmamanın" Gücü: Boş Snapshot Koruması (Empty-Guard)
Yazılım dünyasında genellikle "her zaman güncel kalma" içgüdüsü hakimdir. Ancak bazen "hiçbir şey yapmamak", sistemi büyük bir felaketten kurtaracak en akıllıca tercihtir. SymbolService mimarisindeki "Empty-snapshot guard", veri bütünlüğünü güncelliğin önüne koyan kritik bir kontrol noktasıdır.
Eğer dış sağlayıcılardan gelen verilerin birleştirilmesi sonucunda elde edilen entity sayısı sıfır ise, sistem tüm akışı anında durdurur. Bu durum sadece sağlayıcıların kapalı olmasıyla ilgili değildir; API formatındaki bir değişiklik veya filtreleme mantığındaki bir hata (örneğin SPOT/USDT gibi beklenen işlem çiftlerinin bulunamaması), yanlışlıkla tüm kataloğu silmemize neden olabilir.
Bu karşı-sezgisel strateji, "boş bir liste yayınlayıp tüm platformu felç etmektense, eski ama tutarlı veriyle yola devam etme" prensibine dayanır. Mimari bir değişmez (invariant) olarak bu koruma, sistemin kendi kendini imha etmesini engelleyen bir emniyet supabıdır.
4. Çift Olay Stratejisi: Redis Çöktüğünde Bile Ayakta Kalmak
Modern sistemlerde Redis gibi önbellek katmanları vazgeçilmezdir, ancak "tekil hata noktası" (SPOF) olmamalıdırlar. SymbolService, Redis'e yazma başarısını bir redisOk boolean değişkeni ile takip eder ve MassTransit üzerinden kurgulanan çift olay (dual-event) stratejisini devreye sokar:
Normal Yol (
SymbolsUpdatedEventV1): Redis yazma işlemi başarılıysa yayınlanır. Sadece bir "metadata pointer" taşır; tüketicilere veriyi Redis'ten okumalarını söyler.Yedek Yol (
SymbolsSnapshotEventV1): Redis bağlantısı koptuğunda veya yazma hatası alındığında (try/catch bloğu) yayınlanır. Bu olay, tüm veri yükünü (full payload) kendi içinde taşır.
Buradaki mimari esneklik, aşağı akış (downstream) tüketicilerinin her iki olay tipini de işlevsel olarak eşdeğer kabul etmesinden gelir. Redis çöktüğünde sistem performans kaybedebilir (gecikme artabilir) ancak veri akışı asla durmaz. Bu, dağıtık sistemlerde "zarif bozunma" (graceful degradation) ilkesinin somut bir örneğidir.
5. Teknik Borçla Yüzleşmek: Sabit Kodlanmış Anahtarların Gizli Tehlikesi
En iyi tasarlanmış mimariler bile operasyonel güvenliğin ihmal edildiği noktalarda kırılabilir. İnceleme notlarında tespit edilen CoinApi bağlantısını yöneten istemci(CoinApiClient) içindeki sabit kodlanmış (hardcoded) API anahtarı, teknik borcun en sinsi ve "kritik" halidir.
Mimari mükemmellik sadece algoritmik verimlilik değil, aynı zamanda operasyonel çevikliktir. Altyapı katmanına gömülmüş bir anahtar, şu riskleri taşır:
Kaynak kontrol sistemine (VCS) sızma riski.
Anahtar rotasyonu (rotation) için kodun yeniden derlenip dağıtılma zorunluluğu.
"Bir CoinAPI API anahtarı altyapı katmanında sabit kodlanmıştır... kod değişikliği ve yeniden dağıtım olmadan döndürülemez."
Sistem mimarisini savunurken, güvenlik standartlarından ödün vermemek gerekir. API anahtarları, bağlantı dizgileri ve sırlar; IConfiguration üzerinden beslenen, Secrets Manager veya ortam değişkenleri ile yönetilen dinamik yapılar olmalıdır. Bir sistemin "sarsılmaz" olması, onun ne kadar kolay yönetilebildiğiyle doğrudan ilişkilidir.
6. Sonuç: Yarının Finansal Altyapısını İnşa Etmek
SymbolService örneği bize gösteriyor ki; dayanıklı bir sistem sadece "mutlu senaryolarda" çalışan bir kod bütünü değildir. Gerçek mimari güç; A/B Swap ile atomik durum geçişlerinde, Empty-Guard ile veri bütünlüğü savunmasında, Redis fallback mekanizmalarıyla altyapısal bağımsızlıkta ve sıkı yapılandırma yönetimiyle operasyonel güvenlikte gizlidir.
Bugün sisteminizi tasarlarken kendinize şu soruyu sorun: "Sistemim sadece her şey yolundayken mi çalışıyor, yoksa dış dünyadaki tüm API'ler sustuğunda ve veritabanı bağlantıları sarsıldığında bile elindeki gerçeği koruyacak kadar inatçı mı?" Yarının finans dünyasında sadece kaos anında ayakta kalmayı önceden planlayan (Chaos Engineering) yapılar varlığını sürdürebilecektir.