Kripto Borsa Altyapısını Ölçeklendirme: Günde 1.000 Kullanıcıdan 100.000 Kullanıcıya

Konular

• Borsalar Yük Altında Neden Çöker
• Üç Ölçeklendirme Aşaması
• Tıkanıklıkları Sizi Bulmadan Önce Tespit Edin
• Veritabanı Ölçeklendirme: Karşınıza Çıkacak Duvar
• Eşleştirme Motoru Ölçeklendirme: Kutsal Tek Çekirdekli Tasarım
• WebSocket Ölçeklendirme: Ölçekte Gerçek Zamanlı
• API Gateway Tasarımı: Ön Kapınız
• Blockchain Düğüm Altyapısı
• CDN ve Statik Varlık Optimizasyonu
• Gözlemleme ve Uyarı Sistemleri: Borsaya Özgü Yaklaşım
• Kubernetes ile Otomatik Ölçeklendirme
• Felaket Kurtarma ve Çok Bölgeli Dağıtım
• Yük Testi: Gerçekçi Alım Satım Yükü Simülasyonu
• Ölçekte Maliyet Optimizasyonu
• Gerçek Metrikler ve Kıyaslamalar
• Tümünü Bir Araya Getirmek

Borsalar Yük Altında Neden Çöker

Her kripto borsası geliştirme ortamında sorunsuz çalışır. Her borsa ilk yüz kullanıcısını zorlanmadan kaldırır. Sorunlar gerçek yatırımcılar geldiğinde başlar ve onlar her zaman en kötü anda gelirler. Bir token listelemesi viral olur. Bitcoin bir saatte %15 hareket eder. Bir likidasyon zinciri tetiklenir. Bir anda eşleştirme motorunuz emirlere boğulur, veritabanı bağlantılarınız tükenir, WebSocket sunucularınız bağlantıları düşürür ve destek kuyruğunuz “PARAM NEREDE” talepleriyle dolar.

Demo alım satımı mükemmel şekilde kaldıran borsaların gerçek bir piyasa olayının ilk dakikalarında çöktüğünü gördüm. Temel neden neredeyse her zaman aynıdır: altyapı ortalama yük için tasarlanmıştır, tepe yük için değil. Kriptoda tepe yük, ortalama yükün 2 katı değildir; 10 ila 50 katıdır. Kriptoyu yatırımcılar için heyecan verici yapan oynaklık, DevOps mühendisleri için korkutucu hale getirir.

Codono gibi bir kripto borsa yazılımı üzerine inşa ediyorsanız, zaten üretim ortamında test edilmiş bir temeliniz var. Kendi sunucunuzda barındırılan bir kripto borsasıyla, eşleştirme motorundan veritabanına kadar yığının her katmanını siz kontrol edersiniz. Ancak bu temeli gerçek büyümeyi kaldıracak şekilde ölçeklendirmek, her katmanda bilinçli altyapı kararları gerektirir. Bu kılavuz, bu kararların tam olarak neler olduğunu, önemli olan gerçek rakamlar ve yapılandırmalarla ele alıyor.

Üç Ölçeklendirme Aşaması

Borsa altyapısı ölçeklendirmesi sürekli değildir. Her biri farklı darboğazlara ve çözümlere sahip ayrı evreler halinde gerçekleşir. Hangi aşamada olduğunuzu anlamak, çok erken aşırı mühendislik yapmanızı veya çok geç yetersiz yatırım yapmanızı engeller.

Aşama 1: Başlangıç (1K DAU)

Bu aşamada her şey tek bir sunucuda veya küçük bir kümede çalışır. Veritabanınız, eşleştirme motorunuz, API sunucunuz ve WebSocket sunucunuz aynı makineyi paylaşabilir. Sorun değil. Kimse size aksini söylemesin.

Tipik altyapı: 1-3 sunucu, tek veritabanı örneği, monolitik veya basit mikroservis dağıtımı. Toplam bulut harcaması: ayda 500-2.000 dolar.

İlk ne bozulur: Emir geçmişi ve işlem tablolarında veritabanı sorgu performansı. Birisi 50 alım satım çiftini kapsayan işlem geçmişini ilk kez dışa aktardığında, veritabanınız kilitlenir ve herkes bunu hisseder.

Ne yapmalı: Veritabanı indeksleri ekleyin, bağlantı havuzu (PgBouncer veya ProxySQL) uygulayın, ticker fiyatları ve kullanıcı bakiyeleri gibi sıcak veriler için temel Redis önbelleği kurun. Henüz hiçbir şeyi shardlamayın. Henüz okuma replikası eklemeyin. Sadece tek örneğinizi olabildiğince verimli hale getirin.

Aşama 2: Büyüme (10K DAU)

Artık gerçek eşzamanlı alım satımınız var. Birden fazla alım satım çifti aynı anda aktif. WebSocket bağlantıları ciddi bellek tüketmeye başlıyor. API’niz ihtiyacınız olduğunu bilmediğiniz hız sınırlarına çarpıyor.

Tipik altyapı: 5-15 sunucu, okuma replikalı veritabanı, ayrılmış eşleştirme motoru sunucusu, ayrı WebSocket kümesi. Bulut harcaması: ayda 5.000-15.000 dolar.

İlk ne bozulur: WebSocket bağlantı limitleri, veritabanı yazma verimi, oynaklık ani yükselmelerinde eşleştirme motoru kuyruk derinliği.

Ne yapmalı: Eşleştirme motorunu ayrılmış donanıma taşıyın. Sorgular için veritabanı okuma replikaları ekleyin. WebSocket dağıtımı için düzgün bir pub/sub katmanı uygulayın. Hız sınırlamalı bir API gateway dağıtın. Burası, teknoloji yığını seçimlerinizin gerçekten önem kazanmaya başladığı yerdir.

Aşama 3: Ölçek (100K DAU)

Artık gerçek bir borsa altyapısı işletiyorsunuz. Her bileşen yatay ölçeklendirme, yük devri ve coğrafi dağıtım gerektirir. Ara sıra dağıtım yapan bir geliştiriciye değil, ayrılmış bir DevOps ekibine ihtiyacınız var.

Tipik altyapı: Birden fazla bölgede 50’den fazla sunucu, shardlanmış veritabanları, Kubernetes kümeleri, ayrılmış blockchain düğümleri, çoklu CDN kurulumu. Bulut harcaması: ayda 30.000-80.000 dolar.

İlk ne bozulur: Aşama 2’de çalışan ama bantla tutturulmuş her şey. Veritabanı sharding’i zorunlu hale gelir. İzleme boşluklarınız kesintiye dönüşür. Dağıtım süreciniz darboğaz olur.

Ne yapmalı: Bu kılavuzdaki her şey.

Tıkanıklıkları Sizi Bulmadan Önce Tespit Edin

Herhangi bir şeyi ölçeklendirmeden önce, gerçekte neyin yavaş olduğunu bilmeniz gerekir. Tahmin etmek pahalıdır. Borsa altyapısındaki en yaygın altı darboğaz, performans sorunlarının gerçek nedeni olma sıklıklarına göre sıralanmıştır:

1. Veritabanı yazma verimi — Her emir, işlem, bakiye güncellemesi ve yatırma yazma işlemi üretir. Saniyede 1.000 emirde, işlemler ve bakiye güncellemeleri hesaba katıldığında saniyede 3.000-5.000 veritabanı yazması üretirsiniz.

2. Eşleştirme motoru kuyruk derinliği — Emirler motorun işleyebildiğinden hızlı birikirse, gecikme üstel olarak artar. Sağlıklı bir kuyruk derinliği 100 emrin altındadır. Bir ani yükselme sırasında 10.000’in üzerinde görürseniz, sıkıntıdasınız demektir.

3. WebSocket bağlantı sayısı — Bağlı her kullanıcı açık bir TCP bağlantısı tutar. 10.000 eşzamanlı bağlantıda, yalnızca soket tamponları için ~80MB çekirdek belleği kullanırsınız. 100.000’de ayrılmış WebSocket sunucularına ihtiyacınız vardır.

4. Blockchain düğüm senkronizasyon gecikmesi — Yatırma tespit düğümünüz zincirin ucunun gerisinde kalırsa, kullanıcılar “kayıp yatırma” bildirir ve destek ekibiniz panikler. Ethereum’da 10 blok geride olan bir düğüm, yatırmaların görünmesinin 2 dakikadan fazla ek süre alması demektir.

5. API hız limiti doygunluğu — Bot yatırımcılar API’nizi hesap başına saniyede binlerce istekle dövecektir. Düzgün hız sınırlaması olmadan, birkaç agresif bot tüm kullanıcıların deneyimini bozabilir.

6. Redis bellek baskısı — Agresif önbellek kullanıyorsanız (kullanmalısınız), Redis bellek kullanımı kullanıcı tabanınızla birlikte büyür. Bir tahliye (eviction) fırtınası saniyeler içinde veritabanı aşırı yüklenmesine kademelenebilir.

Optimize etmeden önce profil çıkarın. Her şeyi enstrümante edin. Yüzüncü günde değil, ilk günden itibaren Prometheus metrikleri kurun.

Veritabanı Ölçeklendirme: Karşınıza Çıkacak Duvar

Veritabanı, borsa ölçeklendirme sorunlarının %80’inde darboğazdır. Uygulamanız gereken sırayla çözümlerin ilerlemesi şöyledir.

Bağlantı Havuzu

Uygulamanız muhtemelen her istek için yeni bir veritabanı bağlantısı açıyor. Saniyede 1.000 istekte bu 1.000 bağlantı demektir. Çoğu veritabanı 200-500 aktif bağlantı civarında zorlanmaya başlar. PgBouncer (PostgreSQL) veya ProxySQL (MySQL), uygulamanız ile veritabanı arasında durur ve yeniden kullanılabilir bir bağlantı havuzu tutar.

Havuz boyutunuzu veritabanı sunucunuzdaki CPU çekirdek sayısının 2-4 katına ayarlayın. 16 çekirdekli bir makinede 32-64 bağlantılık havuz olmalıdır. Daha fazlası daha iyi değildir; kilit çekişmesi (lock contention) nedeniyle daha kötüdür.

Okuma Replikaları

Tek veritabanı sunucunuz kapasitesini doldurduğunda, ilk ölçeklendirme hamlesi okuma replikaları eklemektir. Tüm okuma sorgularını (emir defteri anlık görüntüleri, işlem geçmişi, portföy görünümleri, yönetici panoları) replikalara yönlendirin. Yazmaları birincil (primary) üzerinde tutun.

Kritik detay: replikasyon gecikmesi. Asenkron replikasyonda, bir replika birincilin 10-100ms gerisinde olabilir. Bu işlem geçmişi için sorun değildir. Emir vermeden önce bakiye kontrolü için sorundur. Bakiyeleri her zaman birincilden okuyun.

Redis Önbellek Katmanları

Her okumanın veritabanına gitmesi gerekmez. Şunları agresif şekilde önbelleğe alın:

• Ticker verileri (fiyat, 24 saatlik hacim, 24 saatlik değişim): 1 saniyelik TTL
• Emir defteri anlık görüntüleri: 100ms TTL, eşleştirme motorunun bellek içi durumundan yeniden oluşturulur
• Kullanıcı bakiyeleri: Write-through önbellek, her işlem ve para çekmede geçersiz kılınır
• Piyasa yapılandırması (alım satım çiftleri, ücret kademeleri, limitler): 60 saniyelik TTL
• Oturum verileri: Kayan süre dolma ile 30 dakikalık TTL

Doğru yapılandırılmış bir Redis önbelleği, veritabanı okumalarının %90’ını ortadan kaldırabilir. Aşama 2’de, bu tek başına okuma replikalarına olan ihtiyacınızı aylarca erteleyebilir.

Sharding Stratejileri

Tek bir birincil, yazma hacminizi kaldıramadığında (tipik olarak sürekli saniyede 10.000 yazmanın üzerinde) shardlamanız gerekir. Borsalar için iki sharding stratejisi işe yarar:

Alım satım çiftine göre sharding. BTC/USDT için tüm emirler, işlemler ve emir defteri verileri shard 1’e, ETH/USDT shard 2’ye gider. Bu, eşleştirme motorunun doğal bölümlenmesiyle uyumludur. Dezavantajı: kullanıcı bakiye sorgularının birden fazla shard’a gitmesi gerekir.

Kullanıcı kimliğine göre sharding. 12345 numaralı kullanıcının tüm verileri shard A’ya gider. Bakiye sorguları hızlıdır, ancak kullanıcılar arası sorgular (küresel emir defteri oluşturmak gibi) scatter-gather gerektirir. Bu, çok sayıda alım satım çifti olan ama çift başına ılımlı hacme sahip borsalar için daha iyi çalışır.

Aşama 3’teki çoğu borsa hibrit kullanır: emir/işlem tablolarını alım satım çiftine göre, kullanıcı/bakiye tablolarını kullanıcı kimliğine göre shardlar ve referans verilerini (piyasa yapılandırmaları, ücret tarifeleri) tek bir shardlanmamış örnekte tutar.

Emir Defterleri için Zaman Serisi Verileri

Geçmiş emir defteri verileri (grafikleri ve analitiği besleyen derinlik anlık görüntüleri) işlemsel veritabanınızda yaşamamalıdır. TimescaleDB, InfluxDB veya ClickHouse gibi bir zaman serisi veritabanı kullanın. Bunlar, yüksek hacimli yalnızca ekleme (append-only) yazmaları ve zaman aralığı sorguları için optimize edilmiştir.

Yoğun bir alım satım çifti saniyede 10.000’den fazla emir defteri güncellemesi üretebilir. Güncelleme başına 50 baytta, tek bir çift için günde 43GB eder. Zaman serisi veritabanları bunu sütunlu depolama ve otomatik veri sıkıştırma ile kaldırır. İlişkisel veritabanınız bunun altında boğulur.

Eşleştirme Motoru Ölçeklendirme: Kutsal Tek Çekirdekli Tasarım

Eşleştirme motoru, çoğu insanın yanlış ölçeklendirmeye çalıştığı bileşendir. Neden böyle olduğu ve bunun yerine ne yapılması gerektiği aşağıda açıklanıyor.

Tek Thread Neden Önemli

Tek bir alım satım çifti için eşleştirme motoru tek thread’li olmalıdır. Bu bir sınırlama değil, bir tasarım gerekliliğidir. Fiyat-zaman önceliği (FIFO) eşleştirmesi, işlemlerin deterministik sıralamasını gerektirir. Çok thread’li eşleştirme, yanlış dolumlara, hayalet likiditeye ve bakiye tutarsızlıklarına neden olabilecek yarış koşulları (race condition) yaratır.

İyi haber: modern donanımda tek thread’li bir motor saniyede 50.000-100.000 emir işleyebilir. Küresel ilk 10 borsayı işletmiyorsanız, çift başına tek thread yeterlidir.

Bellekte Tutulan Emir Defterleri

Emir defteri veritabanında değil, bellekte yaşamalıdır. Veritabanı destekli emir defterleri işlem başına 1-10ms gecikme ekler. Bellek destekli emir defterleri mikrosaniyeler içinde çalışır. Veritabanı kalıcılık ve kurtarma içindir, aktif eşleştirme için değil.

Mimari şöyledir: gelen emirler bellek içi bir kuyruğa gider, eşleştirme motoru bunları sırayla işler, sonuçlar bir olay günlüğü (event log) aracılığıyla asenkron olarak veritabanına yazılır. Motor çökerse, durumu yeniden oluşturmak için olay günlüğünü tekrar oynatır. Buna event sourcing denir ve finansal eşleştirme motorları için standart yaklaşımdır.

Alım Satım Çifti Başına Yatay Ölçeklendirme

Tek bir alım satım çiftinin eşleştirme motorunu (doğruluktan ödün vermeden) yatay olarak ölçeklendiremezsiniz. Ancak farklı alım satım çiftleri için bağımsız eşleştirme motorlarını farklı çekirdeklerde veya sunucularda çalıştırabilirsiniz.

Aşama 2’de tüm motorları çekirdek başına bir motor olacak şekilde tek bir çok çekirdekli sunucuda çalıştırın. Aşama 3’te motorları hacme göre gruplandırılmış ayrılmış sunuculara dağıtın. BTC/USDT ve ETH/USDT’yi olay günlükleri için hızlı NVMe depolamalı yüksek performanslı makinelere koyun. Düşük hacimli çiftleri paylaşılan örneklere yerleştirin.

Codono’nun kripto borsa yazılımı, uygulama kodunu değiştirmeden alım satım çiftlerini belirli motor örneklerine atamanıza izin vererek bu bölümlendirmeyi yönetir.

WebSocket Ölçeklendirme: Ölçekte Gerçek Zamanlı

WebSocket bağlantıları durum bilgilidir, uzun ömürlüdür ve bellek açlığı çeker. Bunları ölçeklendirmek, durum bilgisiz HTTP API’lerini ölçeklendirmekten temelden farklı bir yaklaşım gerektirir.

Bağlantı Havuzu

Her WebSocket sunucusu, mesaj hacmine bağlı olarak 10.000-50.000 eşzamanlı bağlantıyı kaldırmalıdır. Bunun ötesinde, çekirdek düzeyinde soket yönetimi darboğaz olur. Yeni bağlantıları kullanılabilir sunucular arasında dağıtmak için sağlık kontrollü bağlantı havuzları kullanın.

Yük dengeleyicinizi WebSocket yükseltme (upgrade) desteği için yapılandırın. nginx çalışır, ancak bağlantı yükseltme başlıklarıyla açık bir proxy_pass yapılandırması gerekir. HAProxy WebSocket’i yerel olarak işler ve bu katman için genellikle daha iyi bir seçimdir.

Pub/Sub Mimarisi

Temel sorun: BTC/USDT’de bir işlem gerçekleştiğinde, o çifte abone olan her kullanıcıyı bilgilendirmeniz gerekir. 10 WebSocket sunucusuna yayılmış 5.000 kullanıcı BTC/USDT’yi izliyorsa, eşleştirme motoru 5.000 ayrı mesaj gönderemez.

Çözüm, eşleştirme motoru ile WebSocket sunucuları arasında bir pub/sub katmanıdır. Eşleştirme motoru tek bir işlem olayını bir kanala yayınlar. Her WebSocket sunucusu, bağlı istemcilerinin önemsediği kanallara abone olur ve mesajları yerel olarak dağıtır.

Redis Pub/Sub Aşama 2’de işe yarar. Basit, hızlı ve Redis zaten elinizde var. Sınırlaması: Redis Pub/Sub ateşle ve unut (fire-and-forget) mantığındadır. Bir WebSocket sunucusu bir mesajı kaçırırsa (örneğin yeniden başlatma sırasında), o mesaj gitmiştir.

NATS veya NATS JetStream Aşama 3’te daha iyi seçimdir. NATS saniyede milyonlarca mesajı kaldırır, kurtarma için mesaj tekrar oynatmayı destekler ve yerleşik kümelemeye sahiptir. Tam olarak bu kullanım senaryosu için tasarlanmıştır.

Yapışkan Oturumlar

Bir kullanıcının WebSocket bağlantısı koptuğunda ve yeniden bağlandığında, ideal olarak aynı sunucuya ulaşmalıdır. Bu, kullanıcının yeni sunucu yetişene kadar kısaca güncel olmayan bir emir defteri gördüğü “eski veri flaşı” sorununu önler.

Yük dengeleyicinizi makul bir zaman aşımıyla (5-10 dakika) kaynak IP tabanlı yapışkan oturumlar için yapılandırın. Kubernetes kullanıyorsanız, oturum benzeşimi (session affinity) ile bir headless servis kullanın.

Mesaj Sıkıştırma

Ölçekte, WebSocket bant genişliği önem kazanır. Yoğun bir borsa, tüm çiftlerde saniyede 50MB ham WebSocket trafiği üretebilir. Bant genişliğini %60-80 azaltmak için mesaj başına deflate sıkıştırması (RFC 7692) kullanın. Çoğu modern WebSocket istemcisi bunu yerel olarak destekler.

API Gateway Tasarımı: Ön Kapınız

API gateway’iniz yatırımcılardan, botlardan ve ön uç uygulamalarından gelen her HTTP isteğini işler. Hızlı, güvenli ve yatay olarak ölçeklenebilir olmalıdır.

Hız Sınırlama

Hız sınırlamasını birden fazla düzeyde uygulayın:

• Küresel: Tüm kullanıcılarda saniyede 100.000 istek (arka ucunuzu DDoS’tan korur)
• IP başına: Dakikada 1.000 istek (naif kötüye kullanımı durdurur)
• API anahtarı başına: Standart kullanıcılar için dakikada 600 istek, VIP/kurumsal için 6.000 (kademe sistemine uyar)
• Uç nokta başına: Emir verme uç noktaları, yalnızca okuma uç noktalarından daha sıkı limitler alır

Redis destekli bir kayan pencere (sliding window) algoritması kullanın. Token bucket algoritmaları daha basittir ama daha az hassastır. Sayaçları, hız limiti pencerelerinize uyan TTL’lerle saklayın.

Sağlam API entegrasyonları oluşturma konusunda detaylar için Codono, API anahtarı başına yapılandırılabilir kademelerle yerleşik hız sınırlama sunar.

Yanıt Önbellekleme

Kullanıcıya göre değişmeyen uç noktalar için API yanıtlarını gateway düzeyinde önbelleğe alın:

• GET /api/v1/ticker — 1 saniyelik önbellek
• GET /api/v1/depth — 100ms önbellek
• GET /api/v1/trades — 500ms önbellek
• GET /api/v1/markets — 60 saniyelik önbellek

Cache-Control başlıklarını kullanın ki CDN’ler de bu yanıtları uçta (edge) önbelleğe alabilsin. Bu tek başına, okuma ağırlıklı uç noktalarda arka uç yükünüzü %70 azaltabilir.

Yük Dengeleme

Aşama 2’de, round-robin ile tek bir nginx veya HAProxy örneği yeterlidir. Aşama 3’te şunlara ihtiyacınız vardır:

• Sağlık kontrollü Katman 7 yük dengeleme
• Coğrafi yönlendirme (Asyalı kullanıcıları Asya sunucularına yönlendirin)
• Sağlıksız arka uçları otomatik olarak kaldıran devre kesiciler (circuit breaker)
• Sıfır kesintili dağıtımlar için bağlantı boşaltma (connection draining)

AWS ALB, Google Cloud Load Balancer veya ayrılmış bir Envoy proxy kümesi hepsi işe yarar. Önemli olan pasif değil, aktif sağlık kontrolüdür. Bir arka ucu kaldırmak için 5 başarısız isteği beklemeyin; her 5 saniyede bir yoklayın ve yanıt vermeyi durdurduğu anda kaldırın.

Coğrafi Dağıtım

Önemli kullanıcı trafiğiniz olan her bölgede API gateway’leri dağıtın. Tokyo’daki bir yatırımcının Virginia’daki bir API sunucusuna gitmesi, her isteğe 150-200ms gecikme ekler. Bu, emir verme için kabul edilemez.

En az üç bölgede dağıtın: Kuzey Amerika, Avrupa ve Asya. Kullanıcıları DNS tabanlı coğrafi yönlendirme (Route53, Cloudflare) ile en yakın gateway’e yönlendirin. Gateway daha sonra merkezi eşleştirme motorunuza yönlendirebilir; bu gecikme kabul edilebilir çünkü kendi dahili ağınız üzerindedir.

Blockchain Düğüm Altyapısı

Borsanızın desteklediği her blockchain ile etkileşmesi gerekir: yatırmaları izlemek, para çekmeleri yayınlamak ve onayları kontrol etmek. Düğüm altyapısı genellikle bir kesintiye neden olana kadar ihmal edilir.

Özel ve Paylaşılan Düğümler

Paylaşılan düğümler (Infura, Alchemy, QuickNode) Aşama 1’de yeterlidir. Güvenilirdirler, başkası tarafından bakımı yapılır ve zincir başına ayda 50-500 dolara mal olurlar.

Özel düğümler yüksek hacimli zincirler için Aşama 2’de gerekli hale gelir. Nedenleri: paylaşılan sağlayıcılardaki hız limitleri kısıtlayıcıdır (tipik olarak saniyede 100-1.000 istek), düğüm yapılandırmasını özelleştiremezsiniz ve yatırma işlemleriniz için üçüncü bir tarafın çalışma süresine bağımlı olursunuz.

Hacme göre en büyük 3-5 zinciriniz için özel düğümler çalıştırın. Diğer her şey için paylaşılan sağlayıcıları yedek olarak tutun.

Düğüm Yük Dengeleme

Blockchain başına en az iki düğüm çalıştırın. Bunları yalnızca HTTP kullanılabilirliğini değil, senkronizasyon durumunu da doğrulayan sağlık kontrollü bir yük dengeleyicinin arkasına koyun. Sağlık kontrollerine yanıt veren ama zincirin ucundan 50 blok geride olan bir düğüm, kapalı bir düğümden daha kötüdür; sessizce yatırmaları kaçırır.

Sağlık kontrolü mantığı: düğümün en son blok numarasını sorgulayın, bir referansla (başka bir düğüm veya blok gezgini API’si) karşılaştırın ve N bloktan fazla gerideyse düğümü sağlıksız olarak işaretleyin (N, zincirin blok süresine bağlıdır).

Yedek Olarak Çoklu Sağlayıcılar

Özel düğümleriniz olsa bile, paylaşılan sağlayıcılara yük devri yapılandırın. Bir Geth yükseltmesi sırasında iki Ethereum düğümünüz de çökerse, Infura veya Alchemy yatırma işlemlerinizi çalışır durumda tutar. Bunu otomatik yük devirli bir öncelik listesi olarak uygulayın:

1. Birincil özel düğüm
2. İkincil özel düğüm
3. Paylaşılan sağlayıcı A (Alchemy)
4. Paylaşılan sağlayıcı B (Infura)

Codono’nun güvenlik özellikleri, yerleşik düğüm sağlığı izleme ve blockchain sağlayıcıları arasında otomatik yük devri içerir.

CDN ve Statik Varlık Optimizasyonu

Alım satım arayüzünüz, grafikleriniz ve statik varlıklarınız üretimde asla kaynak (origin) sunucularınıza gitmemelidir. CDN’i agresif şekilde kullanın.

Şunları uzun önbellek TTL’leriyle bir CDN’in arkasına yerleştirin: JavaScript paketleri (dosya adında içerik karması, 1 yıllık önbellek), CSS dosyaları, TradingView grafik kütüphanesi, yazı tipleri, görseller ve favicon’lar. Önbellek bozma (cache-busting) için sorgu parametreleri değil, dosya adı karma kullanın (bazı CDN’ler sorgu parametrelerini kaldırır).

Alım satım arayüzü özelinde, kullanıcının konumundan bağımsız olarak ilk sayfa yüklemesinin hızlı olması için birden fazla CDN bölgesine dağıtın. API çağrıları arka ucunuzdan uzaktaki kullanıcılar için biraz daha yavaş olacaktır, ancak arayüzün algılanan performansı anlık olmalıdır.

Karmalı varlıklarda immutable ayarlayın. Bu, gereksiz yeniden doğrulama isteklerini önler:

Cache-Control: public, max-age=31536000, immutable

Gözlemleme ve Uyarı Sistemleri: Borsaya Özgü Yaklaşım

Genel altyapı izleme gereklidir ama yeterli değildir. Yatırımcıların iyi bir deneyim yaşayıp yaşamadığını söyleyen borsaya özgü metriklere ihtiyacınız vardır.

Önemli Olan Metrikler

Emir eşleştirme gecikmesi (p50, p95, p99). Bu, emir gönderiminden eşleşme sonucuna kadar geçen süredir. Hedefler: p50 < 1ms, p95 < 5ms, p99 < 10ms. p99 50ms’i aşarsa yatırımcılar fark eder ve şikayet eder. 200ms’i aşarsa arbitraj botları gider.

Dolum oranı. Tamamen doldurulan piyasa emirlerinin yüzdesi. Sağlıklı bir emir defterinin dolum oranı %95’in üzerindedir. %80’in altında, likidite motorunuzun ilgilenilmesi gerekir.

Para çekme işlem süresi. Kullanıcı talebinden blockchain yayınına kadar. Hedef: otomatik para çekmeler için 5 dakikanın altında, manuel inceleme için 2 saatin altında. p95’i takip edin; birkaç yavaş para çekme, orantısız miktarda destek talebi üretir.

WebSocket mesaj gecikmesi. İşlem gerçekleşmesinden mesajın son bağlı istemciye teslimine kadar geçen süre. Hedef: mesajların %99’u için 100ms’in altında. Bunu yalnızca pub/sub katmanını değil, uçtan uca ölçün.

Blockchain düğüm senkronizasyon farkı. Düğümünüzün en son bloğu ile zincirin ucu arasındaki fark. Hızlı zincirler (Solana, BSC) için 3 bloğu, yavaş zincirler (Bitcoin, Ethereum) için 2 bloğu aşarsa alarm verin.

Prometheus ve Grafana Kurulumu

Prometheus, borsa izleme standardıdır. Her bileşenden özel metrikler dışa aktarın:

# Eşleştirme motoru metrikleri
exchange_order_latency_seconds{pair="BTC_USDT",type="limit"}
exchange_orders_processed_total{pair="BTC_USDT"}
exchange_order_book_depth{pair="BTC_USDT",side="bid"}

# WebSocket metrikleri
exchange_ws_connections_active{server="ws-01"}
exchange_ws_messages_sent_total{pair="BTC_USDT"}

# Blockchain metrikleri
exchange_node_sync_delta{chain="ethereum"}
exchange_deposit_processing_seconds{chain="ethereum"}
exchange_withdrawal_broadcast_seconds{chain="bitcoin"}

Üç kitle için Grafana panoları oluşturun: operasyon ekibi (altyapı sağlığı), alım satım ekibi (piyasa kalitesi metrikleri) ve yönetim ekibi (günlük hacim, yeni kayıtlar ve gelir gibi iş metrikleri).

Uyarı Yönlendirme

Her uyarı birini gece 3’te uyandırmamalıdır. Uyarılarınızı kademelendirin:

• P1 (hemen uyandır): Eşleştirme motoru çöktü, veritabanı birinciline ulaşılamıyor, sıcak cüzdan bakiye anomalisi, para çekme işleme durdu
• P2 (çalışma saatlerinde uyandır): Replikasyon gecikmesi > 5 saniye, düğüm senkronizasyon farkı > 10 blok, API hata oranı > %1
• P3 (talep aç, uyandırma): Disk kullanımı > %80, sertifika 14 gün içinde bitiyor, önbellek isabet oranı %90’ın altında

Kubernetes ile Otomatik Ölçeklendirme

Kubernetes, Aşama 2 ve sonrasında borsa altyapısını ölçeklendirmek için doğal platformdur. Ancak her bileşen aynı şekilde otomatik ölçeklenmemelidir.

Horizontal Pod Autoscaler (HPA)

Durum bilgisiz bileşenler için HPA yapılandırın:

• API gateway pod’ları: CPU (hedef %60) ve istek oranına göre ölçeklendirin
• WebSocket sunucu pod’ları: Bağlantı sayısına göre ölçeklendirin (pod başına hedef 10.000)
• Blockchain izleyici pod’ları: Kuyruk derinliğine göre ölçeklendirin (işlenecek bekleyen işlemler)
• İşlem geçmişi/analitik işleyicileri: İş kuyruğu uzunluğuna göre ölçeklendirin

Eşleştirme motorunu HPA ile otomatik ölçeklendirmeyin. Her eşleştirme motoru örneği belirli alım satım çiftlerini işler ve yeni bir örnek eklemek çift atamalarının yeniden dengelenmesini gerektirir. Bu, otomatikleştirilecek değil, planlanacak manuel bir işlemdir.

Trafik Tahmini

Kripto alım satımı, öngörülemeyen ani yükselmelerle örtüşen tahmin edilebilir kalıplar izler. Tahmin edilebilir kısım: hacim ABD piyasa saatlerinde (14:00-21:00 UTC), pazartesi günlerinde ve büyük ekonomik duyuru günlerinde zirve yapar. Bu pencereler için önceden ölçeklendirin.

Öngörülemeyen kısım: Bitcoin %10 hareket eder ve hacim 20 kat patlar. Bunun için kısa büyütme pencereleri (30 saniye) ve daha uzun küçültme pencereleri (10 dakika) ile agresif HPA ayarları yapılandırın. 10 dakikalık aşırı ölçeklendirme dolarlar tutar. 10 dakikalık yetersiz ölçeklendirme kullanıcıları kalıcı olarak kaybettirir.

Durum Bilgili Bileşenler için StatefulSet Kullanımı

Şunlar için (Deployment değil) StatefulSet kullanın: eşleştirme motoru, veritabanı örnekleri, Redis kümeleri ve blockchain düğümleri. StatefulSet’ler, durum bilgili bileşenlerin doğru çalışması için ihtiyaç duyduğu kararlı ağ kimlikleri ve kalıcı depolama sağlar.

Felaket Kurtarma ve Çok Bölgeli Dağıtım

Borsanız tek bir kullanılabilirlik bölgesinde çalışıyorsa ve o bölge çökerse, borsanız da çöker. Aşama 2’de, tek bir bölge içindeki kullanılabilirlik bölgeleri arasında dağıtın. Aşama 3’te, bölgeler arasında dağıtın.

Veritabanı Yük Devri

Birincil veritabanınız için otomatik yük devri yapılandırın. Patroni ile PostgreSQL veya Group Replication ile MySQL, 10-30 saniye içinde bir replikayı birincile yükseltebilir. Bu yük devrini ayda bir test edin. Test edilmemiş yük devri, hiç yük devri olmamasından daha kötüdür; size yanlış güven verir.

Kritik detay: yük devrinden sonra, tüm uygulama bağlantılarının yeni birincile yeniden bağlanması gerekir. Hangi örneğin o anda birincil olduğuna işaret eden yüzen bir IP veya DNS kaydıyla bir bağlantı proxy’si (PgBouncer, ProxySQL) kullanın.

Sıcak Yedek Eşleştirme Motoru

Olay günlüğünü gerçek zamanlı olarak tekrar oynatan ancak yeni emirleri işlemeyen bir sıcak yedek eşleştirme motoru tutun. Birincil çökerse, yedeği yükseltin. Kurtarma süresi: 30 saniyenin altında, sıfır emir kaybıyla (çünkü olay günlüğü gerçeğin kaynağıdır).

Event sourcing’in karşılığını verdiği yer burasıdır. Yedeğin durumu birincil ile senkronize etmesine gerek yoktur; durumu aynı olay günlüğünden bağımsız olarak türetir. Her iki örnek de aynı olayları işlerse, aynı duruma ulaşırlar. Determinizm, tek thread’li tasarımla garanti edilir.

Çok Bölgeli Dağıtım

Aşama 3’te, tüm bölgelerde aktif API gateway’leri ve WebSocket sunucuları çalıştırın. Eşleştirme motorunu tek bir birincil bölgede çalıştırın. Uzak bölgelerden alım satım gecikmesi, bölgeler arası ağ atlamasını (50-150ms) içerecektir, ancak bu kabul edilebilir çünkü alternatif (birden fazla bölgede eşleştirme motoru çalıştırmak) tutarlılık kabusları yaratır.

Dağıtım kılavuzu için tek bölgede lansman tamamen uygundur. Çok bölgeli dağıtım bir lansman gereksinimi değil, Aşama 3 optimizasyonudur.

Yük Testi: Gerçekçi Alım Satım Yükü Simülasyonu

Test etmediğiniz şeyi ölçeklendiremezsiniz. Borsalar için çoğu yük testi, gerçek alım satım davranışını modellemediği için gerçekçi değildir.

Gerçekçi Alım Satım Yükü Profilleri

Gerçek alım satım trafiği tekdüze dağılmaz. Şu kullanıcı tiplerini modelleyin:

• Piyasa yapıcılar (kullanıcıların %5’i, emirlerin %60’ı): Sürekli limit emri verme ve iptal etme, piyasa yapıcı başına saniyede 10-50 emir, çoğunlukla iptal-değiştir kalıpları.
• Bireysel yatırımcılar (kullanıcıların %80’i, emirlerin %20’si): Aralıklı piyasa ve limit emirleri, yoğun WebSocket abonelik kullanımı, sık bakiye kontrolleri.
• Botlar (kullanıcıların %15’i, emirlerin %20’si): Ani patlamalı API trafiği, agresif hız limiti testi, yüksek WebSocket abonelik sirkülasyonu.

Yük Testi Metodolojisi

1. Taban çizgisi: Mevcut üretim trafik kalıbınızı 1 saat çalıştırın. Tüm metrikleri kaydedin.
2. Rampa: Bir şey bozulana kadar trafiği her 10 dakikada 2 kat artırın. Nerede ve nasıl bozulduğunu kaydedin.
3. Ani yükselme: Taban çizgisinden anında 10 kat trafiğe çıkın. Ani yükselme bittiğinde toparlanma süresini ölçün.
4. Dayanıklılık: 2 kat taban trafiğini 24 saat çalıştırın. Bellek sızıntıları, bağlantı havuzu tükenmesi ve disk alanı sorunlarına bakın.

Yukarıdaki emir akış kalıplarını modelleyen k6, Gatling veya özel betikler gibi araçlar kullanın. Genel HTTP yük testi araçları emir defteri dinamiklerini anlamaz; gerçekçi limit emirleri, piyasa emirleri ve iptaller dizileri oluşturan betiklere ihtiyacınız vardır.

Ölçekte Maliyet Optimizasyonu

Optimizasyon konusunda bilinçli değilseniz, bulut altyapısı maliyetleri gelirden daha hızlı büyür.

Rezerve Edilmiş Sunucular

Veritabanı sunucularınız, eşleştirme motoru sunucularınız ve birincil Redis örnekleriniz 7/24 çalışır. Bu iş yükleri için rezerve edilmiş sunucular (1 veya 3 yıllık taahhüt) satın alın. Tasarruf: talep üzerine fiyatlandırmaya kıyasla %30-60.

Kritik Olmayan Yükler için Spot Sunucular

Şunlar için spot/preemptible sunucular kullanın: yük testi ortamları, blockchain düğüm senkronizasyonu (yalnızca ilk senkronizasyon), veri analitiği işleyicileri ve hazırlık ortamları. Bu iş yükleri kesintiyi tolere eder. Tasarruf: talep üzerine kıyasla %60-90.

Eşleştirme motorunu, birincil veritabanını veya para çekme işlemeyi asla spot sunucularda çalıştırmayın. Maliyet tasarrufu operasyonel riske değmez.

Doğru Boyutlandırma

Çoğu borsa operatörü CPU’yu aşırı, belleği yetersiz tahsis eder. Sunucu boyutlarınızı üç ayda bir gözden geçirin. Bir sunucunun CPU kullanımı asla %30’u aşmıyorsa, küçültün. Bellek kullanımı düzenli olarak %85’e ulaşıyorsa, takaslamaya (swap) başlamadan önce büyütün.

Veri Yaşam Döngüsü Yönetimi

90 günden eski işlem verilerine nadiren erişilir. Bunları soğuk depolamaya (S3, GCS) taşıyın ve gerektiğinde Athena veya BigQuery ile sorgulayın. Sıcak veritabanınızda yalnızca son 90 günü tutun. Bu, veritabanı depolama maliyetlerini %70 azaltabilir ve güncel veriler için sorgu performansını artırabilir.

Gerçek Metrikler ve Kıyaslamalar

Gerçek borsa operasyonlarına dayanan, her ölçeklendirme aşaması için performans hedefleri şunlardır:

Metrik	Aşama 1 (1K DAU)	Aşama 2 (10K DAU)	Aşama 3 (100K DAU)
Emir/saniye	1.000	10.000-50.000	100.000+
Emir gecikmesi (p99)	< 50ms	< 10ms	< 5ms
WebSocket bağlantıları	500	5.000-20.000	100.000+
WS mesaj verimi	10K mesaj/sn	100K mesaj/sn	1M+ mesaj/sn
API istekleri/saniye	5.000	50.000	500.000+
Veritabanı yazmaları/saniye	500	5.000	50.000+
Yatırma tespit süresi	< 60sn	< 30sn	< 15sn
Para çekme yayın süresi	< 5dk	< 2dk	< 30sn
Çalışma süresi SLA’sı	%99,5	%99,9	%99,95

Bunlar hevesli rakamlar değildir; kullanıcı deneyiminin kabul edilebilir kaldığı minimum eşiklerdir. Bu hedeflerin altında yatırımcılar gider. Üstünde rekabetçisinizdir.

Tümünü Bir Araya Getirmek

Bir kripto borsasını ölçeklendirmek, ilk günden her tekniği uygulamakla ilgili değildir. Her aşamada hangi sorunların çözüleceğini bilmek ve her şeyi yeniden yazmadan kapasite eklemenize izin veren bir mimari kurmakla ilgilidir.

Basit başlayın. Düzgün önbellekleme ve bağlantı havuzuyla tek sunuculu bir dağıtım, çoğu insanın beklediğinden daha fazla yükü kaldırır. Bu yetmediğinde, okuma replikaları ve bir pub/sub katmanı ekleyin. Bu yetmediğinde, veritabanınızı shardlayın ve WebSocket sunucularınızı dağıtın. Bu yetmediğinde, çok bölgeli dağıtıma geçin.

Tüm aşamalarda sabit olan şey: izleme. Ölçemediğiniz şeyi ölçeklendiremezsiniz. Her şeyi ilk günden enstrümante edin. 1K DAU’da topladığınız metrikler, 10K DAU’da tam olarak nereye yatırım yapacağınızı söyleyecektir.

Codono’nun kripto borsa yazılımı ile inşa ediyorsanız, eşleştirme motoru, emir defteri yönetimi ve WebSocket altyapısı zaten üretim ortamında test edilmiştir. Sizin işiniz, çevreleyen altyapıyı (veritabanı, önbellekleme, yük dengeleme ve blockchain düğümleri) büyümenize uyacak şekilde ölçeklendirmektir. Bu, her şeyi sıfırdan kurmaktan çok daha çözülebilir bir sorundur.

Ölçeklenen bir borsa altyapısı kurmaya hazır mısınız? Codono’nun mimarisini keşfedin ve temelin üretim alım satım yükünü kutudan çıkar çıkmaz nasıl kaldırdığını görün.