Gerçek Zamanlı İkili Opsiyonlar Platformu Kurmanın Zor Kısmı Grafik Değildi

2018’den 2024’e kadar, tek mimar ve tam yığın mühendis olarak, üretim ortamında kullanılacak bir gerçek zamanlı ikili opsiyon ticaret platformu tasarladım ve uyguladım.

Bu tür bir platform ilk bakışta bir grafik, bir zamanlayıcı ve iki buton gibi görünebilir. Ancak en ilginç kısmı bu değil. Zor kısım, fiyatlar sürekli değişirken finansal doğrunun nerede olduğunu belirlemektir; kullanıcılar kısa ömürlü pozisyonlar açar, tarayıcı sekmeleri donabilir, alıntı akışları eskiyebilir ve bakiyelerin hala doğru kalması gerekir.

Kurmuş olduğum sistem, bir istemci ticaret terminali, bir idari SPA, gerçek zamanlı alıntı alma, sipariş yerleştirme, otomatik tasfiye, gerçek/demo/turnuva ticaret modları, ödeme akışları, çekimler, KYC iş akışları, dolandırıcılık karşıtı kontroller, referanslar, turnuvalar, Redis tabanlı yayın, ve Docker ile ayrılmış çalışma süreçlerini içermektedir.

Bu makale mühendislik mimarisine odaklanmaktadır: görselleştirmeyi finansal otoriteden nasıl ayırdım, siparişlerin nasıl kabul edildiği ve tasfiye edildiği, yerleştirme işlemlerini neden senkron tutmam gerektiği ve neden gerçek zamanlı finansal bir sistemin geri bildirimini optimize etmesi gerektiğini, kullanıcı arayüzünün doğruluk kaynağı olmamasını açıklayabilmek için.

Bu, tarihi bir yazılım projesi ile ilgili bir mühendislik mimarisi vaka çalışmasıdır. Yatırım tavsiyesi değildir, ticaret faaliyetlerini teşvik etmez ve ticaret stratejilerini ele almaz.

Ticaret Ekranı Üzerindeki Ürün Yüzeyi Daha Genişti

Açık ticaret terminali yalnızca bir yüzeydi. Arkada daha geniş bir operasyonel platform bulunmaktaydı:

• grafik, açık pozisyonlar, tarih, bakiyeler ve turnuva görünümlerine sahip Vue tabanlı bir ticaret terminali;
• kullanıcılar, semboller, ödemeler, çekimler, KYC kontrolleri, turnuvalar, promosyonlar, referanslar ve istatistikler için bir idari SPA;
• ticaret, profiller, yatırımlar, çekimler, referanslar, turnuvalar ve idari işlemler için Laravel API’leri;
• bir piyasa veri akışına bağlı uzun süreli bir alıntı ayrıştırıcısı;
• son tarihi geçmiş olan pozisyonları kapatan bir sipariş kontrolörü;
• dakika düzeyinde görevleri içeren planlı işler;
• özel gerçek zamanlı etkinlikler için Redis ve Laravel Echo Server;
• geri arama doğrulaması ile ödeme sağlayıcı entegrasyonları;
• gerçek, demo ve turnuva ticareti için ayrı bakiye ve sipariş akışları.

Temel, bir Laravel monoluğuydu, ancak tek bir farklılaşmamış çalışma süreci olarak dağıtılmadı. Bir tutarlı alan modeli korudum ve operasyonel yükleri ayrı süreçlere ayırdım. Web uygulaması, ayrıştırıcı, tasfiye işçisi, zamanlayıcı ve websocket geçidi farklı yaşam döngülerine ve hata modlarına sahipti ancak yine de aynı iş kurallarını paylaşmak zorundaydılar.

Tasarım prensibi basitti:

Alan modelini merkezi tut; onu farklı şekillerde zorlayan çalışma ortamlarını ayır.

Tarayıcı Asla Finansal Otorite Olmadı

Grafik, bir kullanıcının piyasa hareketini anlaması için yeterince gerçek zamanlıydı. Ancak paranın tasfiye edilmesi için yeterince güvenilir değildi.

Bir tarayıcı gecikebilir. Bir websocket mesajı geç gelebilir. Bir dizüstü bilgisayar uykuya geçebilir. Mobil bir bağlantı kopabilir. Bir grafik, görselleştirme için yararlı olan ancak tasfiye için güvenli olmayan bir fiyat gösterebilir.

Bu yüzden fiyat işlemlerini iki ayrı konuya ayırdım:

1. Görselleştirme verisi: ön uç piyasa güncellemelerini alır ve mumları renderlar.
2. Finansal veri: arka uç alıntı ayrıştırıcısı, ticaret motoru tarafından kullanılan sunucu tarafı tıkkelerini ve piyasa durumunu korur.

Kullanıcı hareketi tarayıcıda izleyebilirdi, ancak arka uç, bir ticaretin kabul edilip edilmeyeceğine ve nasıl kapatılacağına karar verdi.

Sistemde kullandığım kural:

Grafik bir projeksiyondur. Arka uç otoritedir.

Bu kural, büyük bir hata sınıfını ortadan kaldırdı. Tasfiye, kullanıcının çevrimiçi olmasına, kullanıcı arayüzünün en son paketi almasına veya tarayıcı zamanlayıcısının doğru zamanda çalışmasına bağlı olmamalıdır.

Çalışma Süresinin Parçalanması: Bir Alan, Beş İş

Platform beş ana operasyonel rolle çalışıyordu.

Web süreci HTTP yollarını, kimlik doğrulamayı, SPA teslimini, ticaret API’lerini, profil işlemlerini, yatırımları, çekimleri, idari API’leri ve ödeme geri aramalarını yönetiyordu.

Alıntı ayrıştırıcısı piyasa veri kaynağına sürekli bir websocket bağlantısı sürdürüyordu, aktif sembollere abone oluyor, alıntı paketlerini ayrıştırıyor, tıkkeleri yazıyor, piyasa durumunu güncelliyordu ve alıntı verisinin güncel olup olmadığını kontrol eden bir kalp atışı yeniliyordu.

Sipariş kontrolörü süresi dolmuş açık pozisyonları tarıyor, süre dolmadan önce ilgili sunucu tarafı tıkkesini buluyor, kazanma/kayıp/iade hesaplıyor, siparişi tarihçeye taşıyor, bakiyeleri ve istatistikleri güncelliyor ve kapanış olaylarını yayımlıyordu.

Zamanlayıcı dönemsellik gösteren operasyonel görevleri yönetiyordu. Laravel zamanlayıcısında, bu, tıklama temizliği, ödeme temizliği, ödeme yeniden hesaplaması, döviz kurları ve kısa dönem istatistiklerine dair dakikalık görevleri içeriyordu; ayrıca turnuva kontrolleri ve GeoIP güncellemeleri gibi daha az sık gerçekleşen görevleri de içeriyordu.

Gerçek zamanlı geçit Redis ve Laravel Echo Server üzerinden iş etkinliklerini ilettiyordu. Bakiye değişiklikleri, sipariş kapama etkinlikleri, turnuva etkinlikleri ve sembol güncellemeleri, yetkilendirilmiş özel kanallar aracılığıyla tarayıcıya ulaştırılıyordu.

Alıntı Alma: Sessizlik Bir Durumdur

Alıntı ayrıştırıcısının dar ama önemli bir görevi vardı:

• piyasa veri akışına bağlanmak;
• aktif ticaret sembollerini yüklemek;
• her aktif sembole abone olmak;
• gelen paketleri ayrıştırmak;
• canlı tıkkeleri yazmak;
• piyasa oturum durumunu güncellemek;
• kalp atışını yenilemek;
• sembol konfigürasyon değişikliklerini tespit etmek ve gerektiğinde yeniden abone olmak.

Kalp atışının önemi büyüktü. Bir ticaret platformunda verilerin olmaması nötr bir durum değildir. Bu bir piyasa durumudur.

Eğer ayrıştırıcı veri almayı durdurursa, platform sağlıklıymış gibi ticaret kabul etmeye veya tasfiye etmeye devam etmemelidir. Eski bir alıntı akışı yalnızca bir altyapı sorunu değil; aynı zamanda finansal doğruluk sorunu olabilir.

Alıntı tazeliğini ticaret kararlarına alındı. Sipariş yerleştirme ve tasfiye, sunucu tarafı piyasa durumu, en son tık verileri ve ayrıştırıcı tazeliğini kullanarak kabul edilip edilmeyeceğine, reddedip reddedilmeyeceğine karar vermek için kullanıldı.

Sipariş Yerleştirme Neden Bilerek Senkrondu

Sipariş yerleştirmeyi yangın ve unutma komutu olarak tasarlamadım.

Kullanıcı “Al” butonuna tıkladığında, arka uç siparişi kabul etmeden önce ticari bir karar veriyordu. Ticaret servisi, sembolü, broker çiftini, ticaret penceresini, sona erme kurallarını, piyasa durumunu, en son tıkı, kullanıcı bakiyesini ve talep edilen modu kontrol ediyordu.

Sadece bu kontroller geçtikten sonra, arka uç ilgili bakiyeyi borç veriyor, açık siparişi oluşturuyor, açılış fiyatını saklıyor ve tarayıcıya yeni bakiyeyi yayımlıyordu.

Açık siparişler tablosunda bir sipariş varsa, sunucu zaten onun arkasındaki piyasa durumunu ve bakiye borcunu kabul etmiş demektir.

Bu, sistemin anlaşılabilirliğini artırdı:

Tasfiye Temel Tutarlılık Problemi İdi

Tasfiye, sistemin en önemli parçasıydı.

Kısa ömürlü bir ikili opsiyon belirli bir yaşam döngüsüne sahiptir:

1. Kullanıcı bir ticaret talep eder.
2. Arka uç sembolü, piyasa, sona erme, mod ve hesap durumunu doğrular.
3. Bakiye borçlandırılır.
4. Açılış fiyatı ve sona erme zamanı ile birlikte açık bir sipariş oluşturulur.
5. Bir arka plan işçisi süresi dolmuş siparişleri bulur.
6. İşçi, sona ermeden önce ilgili sunucu tarafı tıkkesini bulur.
7. İşçi kazanma, kayıp veya iade hesaplar.
8. Sipariş tarihçeye taşınır.
9. Bakiye ve istatistikler güncellenir.
10. Gerçek zamanlı olaylar tarayıcıya bildirilir.

Tarayıcı, kapatma kararının bir parçası olmamıştır. Bağlı, bağlı olmayan, geciken veya tamamen kapalı olabilir. Tasfiye işçisi hala siparişi kapatmalıdır.

İşçinin en önemli sorgulaması, sona erme zamanında sunucu tarafı fiyatını bulmaktı. Gerekli tık kaybolursa veya piyasa durumu geçerli olmazsa, güvenli davranış, tahminde bulunmamak ve iade yapmaktı.

Gerçek Zamanlı Olaylar Teslimat, Ama Doğru Değildi

Platform gerçek zamanlı olayları yoğun bir şekilde kullanıyordu, ancak olay akışı finansal gerçeğin kaynağı değildir.

İş olayı, kalıcı durum değiştikten sonra yayılırdı. Bir sipariş açıldığında, arka uç zaten bakiyeyi borçlandırmıştı. Bir sipariş kapandığında, tasfiye işçisi sonucu zaten kalıcı hale getirmişti. Olay, yalnızca tarayıcıya ne olduğunu bildiriyordu.

Sistem, aşağıdaki olay türleri için ayrı olayları yayınlamaktadır:

• gerçek bakiye değişiklikleri;
• demo bakiye değişiklikleri;
• turnuva bakiye değişiklikleri;
• gerçek opsiyon kapanışları;
• demo opsiyon kapanışları;
• turnuva opsiyon kapanışları;
• sembol ve ödeme güncellemeleri.

Çoğu kanal özel olarak kullanıma sunuldu. Bir kullanıcı yalnızca kendi hesabına uyan kanallara abone olabiliyor ve turnuva kanalları da turnuva katılımını kontrol ediyordu.

Gerçek, Demo ve Turnuva Modlarının Ayrı Finansal Yaşam Dönemlerine İhtiyacı Vardı

Gerçek ticaret, demo ticaret ve turnuva ticareti, kavramları paylaşıyordu: semboller, fiyat verileri, sona erme, tasfiye, tarihçe ve gerçek zamanlı olaylar. Ancak aynı finansal depolamayı paylaşmıyorlardı.

Gerçek siparişler gerçek bakiyeleri ve gerçek tarihçeyi etkiliyordu.

Demo siparişler demo bakiyeleri ve demo tarihçeyi etkiliyordu.

Turnuva siparişleri turnuva katılımcı bakiyeleri, döngüdeki turnuva siparişleri, turnuva tarihçeleri, sıralamalar ve ödülleri etkiliyordu.

Bu ayrım istenmeyen bağlılıkları azalttı. Ayrıca turnuva mekaniğini, gerçek para siparişi yolunu özel bir duruma dönüştürmeden mümkün kıldı.

Turnuva modu kendine ait bir yaşam döngüsüne sahipti: kayıt, giriş maliyeti, başlangıç bakiyesi, isteğe bağlı ek bakiye satın alma, izolasyon ticareti, sıralama güncellemeleri, ödül atama ve son ödül kredi oluşturma.

Dinamik Ödemeler Arka Uç Kontrol Edilen Bir Risk Katmanıydı

Platform, enstrüman ödemelerini bir program dahilinde yeniden hesaplıyordu.

Son zamanlarda yeterli ticaret verisi yoksa, bir enstrüman sabit bir ödeme kullanabilirdi. Eğer yeterli son veri mevcutsa, planlı iş ödemeyi kısa dönem istatistiklerinden yeniden hesapladı ve bunu yapılandırılan minimum ve maksimum değerler arasında sıkıştırdı.

Bu, ödemenin yalnızca ön uçta oluşturulan bir sayı olmadığı anlamına geliyordu. Bu, arka uç kontrol edilen bir operasyonel parametreydi.

Yönetici panelinden sembol durumu, çalışma saatleri, ödeme sınırları ve konfigürasyonlar yönetilebilirdi. Müşteriler, gerçek zamanlı olaylar aracılığıyla ödeme ve sembol güncellemeleri alıyordu.

Ödemeler, Çekimler, KYC ve Dolandırıcılığa Karşı Kontroller Mimaride Değişiklik Yaptı

Gerçek bakiye, mimariyi ticaretten daha geniş bir hale getirir.

Yatırım akışları belirleyici sağlayıcıya özgü başlatma ve geri arama doğrulaması kullanmıştır, daha sonra ortak bakiye-tasfiye mantığına birleşmiştir. Başarılı bir ödeme, bir yatırımı ödeme olarak işaretleyebilir, kullanıcı bakiyesini kredi verebilir, bonus veya ciro kurallarını uygulayabilir, referans sayısını güncelleyebilir ve yeni bakiyeyi yayabilir.

Çekimlerde farklı bir yol izlenmiştir. Bir çekim talebi oluşturmadan önce, platform mevcut bakiyeyi, ciro kısıtlamalarını ve KYC durumunu kontrol etmiştir. Talep oluşturulduğunda, miktar ayrılmış ve kullanıcıya gerçek zamanlı bakiye güncellemesi iletilmiştir.

Platform ayrıca, IP ve kullanıcı ajanı takibi, yasak durumları, özel yayın yetkilendirmesi, doğrulama iş akışları ve idari hesap kontrolleri gibi operasyonel kontroller içermektedir.

Bu sistemler, finansal doğruluktan ayrı olarak değildir. Onlar onun bir parçasıdır. Bir ticaret platformu siparişleri doğru bir şekilde tasfiye edebilir, ancak eğer yatırımlar, çekimler, KYC durumu, bonuslar, referanslar ve idari müdahaleler istikrarlı bakiye durumu geri bağlanmadan finansal doğruluğunu yitirirse, operasyonel olarak başarısız olabilir.

Admin Paneli Sisteminin Bir Parçasıydı

Yönetici SPA, kullanıcıları, profil verilerini, bakiye kontrollerini, yasak kontrollerini, KYC doğrulamalarını, yatırımları, ödeme sistemlerini, çekimleri, sembolleri, çalışma saatlerini, ödeme ayarlarını, ticaret geçmişini, turnuvaları, promosyon kodlarını, referansları ve ortak talepleri yönetiyordu.

Bir prototipte, yönetici paneli bir düşüncelerin sonucu olabilir. Ancak finansal bir platformda, işletim sisteminin bir parçasıdır.

Sembol değişiklikleri ayrıştırıcının davranışını etkiler. KYC değişiklikleri çekimleri etkiler. Ödeme sağlayıcı ayarları yatırımları etkiler. Turnuva ayarları, izole edilmiş bakiyeleri ve sıralamaları etkiler. Yönetici eylemleri, finansal durumu koruyan kuralları geçmeden çalışma davranışına bağlanmalıdır.

Bugün Neleri Değiştirirdim

Mimari işledi, ancak bunu son biçim olarak sunmazdım.

Aynı sistemi bugün yeniden oluşturuyorsam, sunucu tarafı finansal otorite ilkesini korudum ve etrafındaki uygulamayı geliştirdim:

• Tüm bakiye hareketleri için resmi bir defter tanıtmak;
• Ödeme geri aramaları ve tasfiye etrafında daha güçlü idempotans eklemek;
• Olay sözleşmelerini açık ve sürümlü hale getirmek;
• Yüksek hacimli tık analitiğini bir zaman serisi veya analitik depoya taşımak;
• Ayrıştırıcı kalp atışı, tasfiye gecikmesi ve olay teslimatı etrafında yapılandırılmış metrikler eklemek;
• Ticaret motorunu daha belirgin bir sınırlı modül ya da hizmete ayırmak;
• Tasfiye uç noktaları etrafında otomatik testleri genişletmek.

Bu değişiklikler merkezi dersi değiştirmeyecektir. Denetim, operasyon ve evrim üstünde işimizi kolaylaştıracaktır.

Ana Ders

Gerçek zamanlı finansal sistemlerin merkezi mühendislik dersi, nasıl hızlı bir şekilde bir grafik çizildiği ile değil, gerçeğin nerede bulunduğu ile tanımlanır.

Bir grafik gerçek zamanlı olabilir, ancak parayı tasfiye edemez.

Bir tarayıcı yanıt verebilir, ancak finansal gerçeklik kaynağı olamaz.

Bir arka uç siparişleri hızlı bir şekilde kabul edebilir, ancak piyasa durumunu, sembol kurallarını, sona erme kısıtlamalarını, alıntı tazeliğini ve hesap bakiyesini kontrol etmeden bunu yapamaz.

Bir tasfiye işçisi pozisyonları otomatik olarak kapatabilir, ancak dayanıklı tarih, bakiye güncellemeleri, istatistikler ve gerçek zamanlı bildirimler üretmelidir.

Bir yönetici paneli ikincil görünebilir, ancak üretimde işletim modelinin bir parçasıdır.

Kullanacağım prensip şudur:

Gerçek zamanlı geri bildirim etrafında kullanıcı deneyimini optimize et, ancak finansal çekirdek tasarımını belirleyici durum geçişleri etrafında yap.

Bu prensip, 2018 ve 2024 yılları arasında kurduğum platformu şekillendirdi. Aynı zamanda diğer gerçek zamanlı finansal sistemlere de en iyi şekilde aktarılan kısımdır.

Yazar Hakkında

Rodion Larin, gerçek zamanlı finansal altyapı, fiyatlandırma otomasyonu ve finansal sonuçları doğrudan etkileyen yüksek yük sistemleri üzerine odaklanmış bir finansal sistem mimarı ve mühendislik lideridir.

2018’den 2024’e kadar, sıfırdan üretim ortamında kullanılacak bir gerçek zamanlı ikili opsiyon ticaret platformu inşa etti. Çalışmaları, ticaret terminali, idari platform, alıntı alma, sipariş yerleştirme, belirleyici tasfiye, gerçek zamanlı olay teslimatı, ödeme geri aramaları, çekimler, KYC iş akışları, dolandırıcılığa karşı kontroller, turnuva mekanikleri, referanslar ve Docker ile ayrılmış çalışma süreçlerini kapsamaktadır.

Ayrıca, 1M+ SKU ile çalışan ve yaklaşık 500k günlük fiyat güncellemeleri gerçekleştiren dayanıklı fiyatlandırma mimarileri tasarladı; zarar alanlarının içe alınması, marj koruma, anomali tespiti ve finansal olarak hassas otomasyon ortamlarında hayatta kalma konularına odaklandı.

Kod arşivi: Troodi/BinaryOptionsCMS