Altyapı, bir brokerage’da kimsenin sabah 8:29’a kadar düşünmediği; nonfarm payrolls Cuma gününde ise herkesin aklındaki tek şey olan kısımdır. Trade sunucunuzun fiziksel olarak nerede bulunduğu, liquidity provider’larınıza nasıl ulaştığı ve bir bileşen arızalandığında ne olduğu; execution kalitenizi, arbitraja maruziyetinizi, platform sağlayıcınızla ilişkinizi ve — slippage, rejections ve downtime üzerinden — hizmet verdiğiniz her trader nezdindeki itibarınızı sessizce şekillendiren kararlardır.
Buna rağmen çoğu işletmeci bu kararları vermek yerine devralır. Platform sağlayıcısı bir hosting paketi önerir, bridge sağlayıcısı bir data center önerir ve yığın oradan büyür. Bu rehber, brokerage altyapısını bilinçli seçimler bütünü olarak ele alır: bileşenlerin neler olduğu, nerede konumlanmaları gerektiği, latansın gerçekte ne kadara mal olduğu ve uptime’ın nasıl umut edilerek değil, mühendislikle sağlandığı.
Harita: Bir Brokerage Altyapısı Gerçekte Nelerden Oluşur
Vendor markalarını bir kenara bıraktığınızda bir perakende brokerage beş altyapı blokundan oluşur:
- Trading platform sunucusu — MT4/MT5, cTrader, DXtrade veya Match-Trader sunucu bileşenleri: fiyat motoru, emir işleme ve hesap durumu. Stack’in latans açısından kritik kalbi.
- Bağlantı ve agregasyon — platformu liquidity provider’lara bağlayan bridge veya gateway, ayrıca feed’leri birleştiren herhangi bir agregasyon katmanı; bunu Forex Aggregator Açıklandı bölümünde ele almıştık. Platforma ve LP’lere fiziksel olarak mümkün olan en yakın yerde konumlanır.
- CRM, trader’s room ve back office — onboarding, ödemeler, raporlama, partner takibi. Latansa toleranslıdır (burada onlarca milisaniye önemsizdir) ama kullanılabilirlik açısından kritiktir: müşteri portalı çalışmadığında para yatırma işlemleri durur.
- Veri servisleri — raporlama, risk ve entegrasyonlar için platform verilerinin kendi veritabanlarınıza replikasyonu; her şeyi birbirine bağlayan API katmanı, tıpkı MT4/MT5 API for Brokers bölümünde anlattığımız gibi.
- Genel erişim katmanı — website, cashier, client-facing API’ler — burada DDoS koruması ve coğrafi içerik dağıtımı, ham latanstan daha önemlidir.
Tasarım prensibi:her bloğun farklı latans ve kullanılabilirlik gereksinimleri vardır; bu nedenle her biri kendi yerleşimini ayrı ayrı hak eder.Klasik başlangıç hatası, her şeyi “platformun bulunduğu yerde” barındırmaktır — bir pazarlama sitesi için premium colocation fiyatı ödemek — ya da bunun ayna görüntüsü olarak, trade sunucusunu likiditesinden okyanuslar ötede, sıradan bir cloud bölgesine koymaktır.
Coğrafya: NY4 ve LD4 Neden Sürekli Gündeme Geliyor
Kurumsal FX’in fiziksel ağırlık merkezleri vardır. Secaucus, New Jersey’deki Equinix NY4/NY5 kampüsü, Londra dışındaki Slough’daki LD4/LD5 ve Tokyo’daki TY3 gibi birkaç data center; bankalar arası FX ekosistemini oluşturan matching engine’leri, prime broker’ları ve liquidity provider’ları barındırır. LP’niz size bir fiyat verdiğinde, o fiyat bu binalardan birinde doğar.
Bir broker açısından sonuç basittir:bridge ve platform sunucunuz LP’lerinizin altyapısına ne kadar yakınsa, yeniden dağıttığınız fiyatlar o kadar taze ve fill’leriniz o kadar hızlı olur.Aynı tesis içinde, cross-connect ile bağlı olduğunuzda round-trip time kesirli milisaniyelerle ölçülür. Aynı şehirdeki genel bir cloud bölgesinden tek haneli milisaniyeler. Kamu interneti üzerinden başka bir kıtadan 100–300 milisaniye — gerçek piyasanın çoktan hareket ettiği bir ömür.
Maliyet ve ciddiyet açısından artan sırada pratik yerleşim modelleri:
- Hub’lara yakın uzman FX hosting. NY4/LD4 içinde veya bitişiğinde, FX ekosistemine mevcut bağlantısı olan managed server sunan sağlayıcılar — kendi cage’inize taahhüt vermeden yakınlık sağlayan, yeni brokerler için standart giriş noktası.
- Cross-connect’li colocation. Equinix kampüsünde kendi (veya kiralanmış) ekipmanınız ve her LP’ye ile bridge sağlayıcınıza fiziksel cross-connect’ler — kelimenin tam anlamıyla bir fiber patch. “Kurumsal düzeyde bağlantı” ifadesinin somut anlamı budur: internet yönlendirmesi yerine özel, deterministik yollar.
- Hybrid cloud. Likiditeye yakın konumlanmış trade sunucusu ve bridge; CRM, veritabanları ve web varlıkları ise elastikiyetin, managed services’in ve DDoS araçlarının daha iyi ve daha ucuz olduğu büyük bir cloud’da (AWS, Azure, GCP). Bu ayrım — latans açısından kritik olanın hub’ların yakınında metal üzerinde, geri kalan her şeyin cloud’da olması — iyi yönetilen brokerage’lar için varsayılan mimari haline gelmiştir ve yukarıdaki blok bazlı gereksinimlerle birebir örtüşür.
Operatörlerin kaçırdığı bir yerleşim notu:sunucuyu müşterilerinizin bulunduğu yere değil, likiditenizin bulunduğu yere koyun. Güneydoğu Asyalı müşterileri olan ve Londra likiditesi kullanan bir broker yine de execution’ı LD4 yakınında barındırmalıdır — müşteri ile sunucu arasındaki latans arayüz hissini etkiler, ancak sunucu ile LP arasındaki latans fill fiyatlarını etkiler ve müşterilerin hatırladığı şey fill’lerdir. Mesafe boyunca müşteri deneyimi, edge’de (erişim noktaları, platform sağlayıcılarının sunduğu optimize routing) ve duyarlı azınlık için aşağıda anlatılan VPS ile çözülür.
Latans Size Gerçekte Ne Kadar Mal Olur
Latans tek bir sayı değildir; üç farklı iş problemidir:
1. Eski fiyatlar → arbitraj maruziyeti
Yayınladığınız fiyatlar gerçek piyasadan onlarca milisaniye geride kalıyorsa, latency arbitrage yapanlar eski fiyatlarınızı daha hızlı bir feed’e karşı kullanacaktır — etkili olarak sizden dünün fiyatından alım yapıp günde binlerce kez sömürüye yol açarlar. Bu, en pahalı latans problemidir; çünkü book’unuzdan saldırganın kitabına doğrudan, sistematik bir transferdir ve tam da kendi feed tazeliğini ölçmeyen broker’larda yoğunlaşır. Herhangi bir B-side exposure taşıyorsanız, feed latency bir IT metriği değil bir risk parametresidir — bu, A-Book vs B-Book vs Hybrid bölümünde tartıştığımız exposure limitleriyle aynı monitoring konuşmasının parçasıdır.
2. Yavaş fill’ler → slippage, rejections ve şikayetler
Müşteri emri ile LP fill’i arasındaki her milisaniye, piyasanın hareket edebileceği pencereyi genişletir — bu da fast market’lerde slippage (nedenine bakılmaksızın müşterilerin sizi suçladığı), requotes ve rejections olarak görünür. Execution kalitesi istatistikleri itibarla birleşir: trader topluluklarındaki “fill’ler temiz” ile “haberde seni kaydırıyorlar” arasındaki fark çoğu zaman yalnızca altyapı yerleşimidir.
3. Arayüz gecikmesi → algılanan kalite
Müşteri ile sunucu arasındaki round-trip sürelerinin ~150–200 ms’nin üzerine çıkması, execution iyi olsa bile platformu hantallaştırır. Bu ticari açıdan en hafif sorundur ve core’u taşımadan çözülebilenidir: bölgesel erişim noktaları, iyi peering’li ağlar ve müşteri VPS seçenekleri farkı kapatır.
Operasyonel çıkarım: üçünü de ayrı ayrı ölçün. Pazara iletim gecikmesi, emir gidiş-dönüş dağılımı (medyan ve kuyruk) ve bölgeye göre müşteri oturum gecikmesi. Tedarikçiler ortalamaları belirtir; asıl zarar, ayda önem taşıyan beş dakikada 99. yüzdelikte ortaya çıkar.
VPS Sorusu: Brokerler Neden Müşteri Hosting Sunar
Jakarta’daki ev bağlantısı üzerinden EA’ler çalıştıran bir trader’ın emirleri, Londra’daki sunucunuza karşı her işlemde 200+ ms ve istikrarsız bir rota ekler — sonra da suçlamayı sizin execution’a yöneltir. Trade sunucunuzla aynı veri merkezi bölgesindeki bir VPS, bunu tek haneli değerlere indirir ve EA’yı günün her saati çalıştırır.
İşte bu yüzden “X lotun üzerinde ücretsiz VPS” standart bir broker avantajı haline geldi: En aktif, en algoritmik müşterilerinizin ölçülebilir execution deneyimini makul bir maliyetle iyileştirir, bağlantı şikayetlerinden kaynaklanan destek yükünü azaltır ve — tesadüfen değil — hacmi oluşturan tam da bu segmentin işlem aktivitesini artırır. Bunu uzman bir sağlayıcı üzerinden sunun, sunucunuza yakın konumlandırın ve maliyeti değerle orantılı olacak şekilde aktiviteye bağlayın.
Kesintisiz Çalışma Süresi: Önem Taşıyan Günler İçin Mühendislik
Aracı kurum yükü son derece düzensizdir: NFP açıklamaları, merkez bankası kararları ve piyasa şoku günleri; girişlerde, emirlerde ve fiyat akışında katbekat artışlar yaratır — tam da kapalı kalmanın en pahalıya mal olduğu ve en çok hatırlandığı anlarda. Ortalama yük için tasarım yapmak, açıkça başarısızlık için tasarım yapmaktır. Kesintisiz çalışma araç seti:
- Her katmanda yedeklilik — test edilmiş failover’a sahip bekleme durumundaki platform sunucuları, çift bridge veya LP yolu, veritabanı replikasyonu, colocation’da çift güç/ağ ve ikincil DNS. Tek bir LP’ye yapılan tek bir cross-connect, kurumsal bir kostüm giymiş tek hata noktasıdır.
- Tepe yükte test edilmiş kapasite — en kötü tarihsel saatinize ve bir güvenlik katsayısına göre kalibre edilmiş yük testleri; platformda veya müşteri tabanında anlamlı her değişiklikten sonra yeniden çalıştırılır.
- Uçta DDoS koruması — broker’lar rutin gasp amaçlı DDoS hedefleridir; web ve API varlıklarının önünde scrubbing hizmetleri vazgeçilmezdir ve platform erişim uç noktalarınızın da bir azaltma hikâyesine ihtiyacı vardır.
- Müşterinin hissettiklerini izleyen izleme — yalnızca CPU grafikleri değil; sentetik girişler, emir gidiş-dönüş kontrolleri, feed tazelik kontrolleri, cashier işlem testleri. Önce müşterinin görebileceği belirtilere alarm verin.
- Provalı arıza — hiç denenmemiş failover, bir kabiliyetten ziyade bir varsayımdır. Planlı failover tatbikatları, dokümante edilmiş runbook’lar ve isimlendirilmiş olay rolleri, kesintileri kriz olmaktan çıkarıp prosedürlere dönüştürür.
Bunların hepsi önleme tarafının yarısıdır. Dayanıklılığın hayatta kalma tarafı — önlemenin başarısız olduğu durumda ne olur: yedeklerin geri yüklenmesi, iletişim planları, kurtarma süresi hedefleri — başlı başına bir disiplindir; bunu uçtan uca Forex Aracı Kurumları için Felaket Kurtarma ve İş Sürekliliği. Altyapı tasarımı ve DR planlaması, farklı günlerde yapılan aynı konuşmadır.
Kur, Kirala veya Devret: Kim Yönetmeli
Aşamaya göre dürüst yönlendirme:
- Lansman aşaması (white/grey label veya ilk kendi lisansı): her şeyi kiralayın — likidite merkezlerine yakın uzman bir sağlayıcıdan yönetilen platform hosting, CRM ve web için bulut. Kıt kaynağınız odak; bunu kafeslere değil, müşterilere harcayın. Yalnızca verinizi veya platform konfigürasyonunuzu kilitleyen sözleşmelerden kaçının — Vendor Lock-in’den Nasıl Kaçınılır adresinde işaretlediğimiz taşınabilirlik kaygıları, hosting için de yazılım kadar geçerlidir.
- Yerleşik aşama (anlamlı hacim, kendi portföyünüz): düşük gecikmeye duyarlı yolu sahiplenin — kendi aynı lokasyonda barındırılan veya ayrılmış sunucularınız, LP’lere ve bridge’e doğrudan cross-connect’ler ve yürütme yolunun performansından sorumlu bir mühendis (içeride veya dış kaynak). Buluta toleranslı katmanları bırakın.
- Birden fazla marka veya bölgeye ölçekleme: altyapı bir mimari sorusuna dönüşür — her likidite ilişkisine yakın bölgesel yürütme yığınları, bunların üzerinde tek bir konsolide veri ve back-office katmanı. Doğru yapıldığında, markalar pahalı altyapıyı paylaşır; yanlış yapıldığında, her lansman bunu yeniden kurar.
Bütçe gerçekliği kontrolü: yönetilen platform hosting, başlangıç seviyesindeki bir broker için aylık birkaç yüz dolardan birkaç bin dolara kadar çıkar; cross-connect’ler ve yedeklilik içeren ciddi bir aynı lokasyonda kurulum, personel öncesi aylık birkaç bin dolardan düşük beş haneli rakamlara kadar gider. Bir maaş bordrosu günündeki tek bir görünür kesintinin maliyetine — chargeback’ler, müşteri kaybı ve inceleme sitelerindeki kalıcılığıyla — karşılaştırıldığında, üst seviye paketler kendini fiyatlar.
Sık Sorulan Sorular
Equinix NY4 veya LD4’te olmak özellikle gerekli mi?
ile düşük gecikmeli, deterministik bağlantıya ihtiyacınız varsizin likidite sağlayıcılarınıza. FX likiditesinin çoğu NY4 ve LD4 ekosistemlerinde yoğunlaştığından, onlara yakınlık genellikle doğru cevaptır — ancak LP’leri ve müşterileri Asya merkezli olan bir broker için TY3 veya Singapur’u önceliklendirmek daha doğru olabilir. Marka adına değil, likiditenize göre hareket edin.
AWS veya Azure’da trade server çalıştırabilir miyim?
Evet, çalıştırabilirsiniz; bazı kurulumlarda — özellikle cloud-first tasarlanmış platformlarda veya LP’ye yakın kısmı bridge sağlayıcısı yöneten broker’larda — bu kabul edilebilir şekilde çalışır. Dezavantajlar, FX merkezlerine daha az deterministik gecikme ve fiziksel cross-connect’lerin olmamasıdır. Pratik yaklaşım hâlâ şudur: yürütme açısından kritik bileşenleri likiditeye yakın tutun, geri kalan her şeyi bulutta.
Hangi uptime’ı hedeflemeliyim?
%99,9 platform erişilebilirliği hâlâ ayda yaklaşık 43 dakikalık kesintiye izin verir — bu ancak o dakikaların hiçbiri bir haber akışına denk gelmezse kabul edilebilir. Erişilebilirliği özellikle yüksek volatilite pencereleri için tasarlayın ve ölçün; tedarikçileri de sakin hafta sonlarının ortalamasını almak yerine bunu yapan SLA’lerle bağlayın.
Altyapı prop firm’lar için nasıl farklıdır?
Prop firm’lar ağırlığı LP bağlantısından (sim ortamları piyasaya bağlanmaz) feed kalitesine, dashboard erişilebilirliğine ve risk engine throughput’una kaydırır — binlerce hesabın tick tick değerlendirilmesi. Uptime, monitoring ve DDoS disiplinleri değişmeden taşınır; bir piyasa hareketi sırasında down olan challenge platformu, aynı destek yangınlarını ve itibar hasarını yaratır.
Özet
Brokerage altyapısı bilinçli olmayı ödüllendirir. Yürütmeyi likiditenizin bulunduğu yere yerleştirin, diğer her katmana gereksinimlerinin izin verdiği daha ucuz evi verin, üç gecikmeyi ayrı ayrı ölçün ve uptime’ı ayın ortalama saatine değil, en yoğun saatine göre tasarlayın. Bunların hiçbiri gösterişli değildir; mesele de budur: iyi yapılan altyapı görünmezdir — müşteriler için, yorumcular için ve daha yavaş bir hedefe geçen arbitrajcılar için.
Brokerage Altyapı Stratejisi için Danışmanlık Talep Edin
Güvenilir işlem, ölçeklenebilir operasyonlar ve uzun vadeli iş büyümesini destekleyen bir altyapı tasarlamaya yönelik uzman rehberliği alın. Altyapı kararları geri dönülmesi pahalı hale gelmeden önce barındırma mimarisini, platform yerleşimini, likidite bağlantısını, bulut stratejisini, yedekliliği ve operasyonel dayanıklılığı değerlendirmenize yardımcı olacağız.
Birlikte mevcut teknoloji yığınınızı gözden geçirecek ve brokerage’nizin operasyonel hedefleriyle uyumlu bir altyapı stratejisinin ana hatlarını belirleyeceğiz.
