Trading platformları ve matching engine'ler için Rust geliştirme şirketleri: Hangi parçalar Rust gerektirir ve özel bir ekip nasıl tutulur

Kendi mühendisleri Rust ile bir matching engine'i ya da emir yolunun başka bir parçasını kurmuş ve onu canlı ortamda çalıştırmaya devam eden bir firma arayın. İmzalamadan önce ekibinize katılacak kişilerle tanışın. Rust, gecikmenin para kaybettirdiği yerlerde kendini amorti eder: matching engine, işlem öncesi risk kontrolleri, borsalara giden gateway'ler ve piyasa verisi işleyicisi. Ekranlar, raporlar ve back-office araçları şirketinizin zaten kullandığı dillerde kalabilir.

Hangi şirketler Rust ile trading platformları ve matching engine'ler konusunda uzmanlaşmıştır?

Bu yazı firmaları sıralamıyor. Uzman, kendi mühendisleri Rust ile bir trading sistemini zaten teslim etmiş ve onu bir müşteri için işleten firmadır. Rust mühendislerini siz imzaladıktan sonra işe almayı planlayan bir firma ise size aslında bir işe alım planı sunuyordur.

Trading kodu çoğu zaman kapalıdır: Genellikle müşteriye aittir ve müşteri onu kendinde tutar; bu yüzden güçlü bir firmanın GitHub'da az trading kodu olabilir. Bunun yerine canlı ortamdaki bir sistemi baştan sona anlatmalarını isteyin: ne yaptığını, hangi parçalarının Rust ile yazıldığını, hızının nasıl ölçüldüğünü, bugün onu kimin işlettiğini ve lansmandan sonra neyin bozulduğunu. Müşterinin adı bir gizlilik sözleşmesi yüzünden açıklanamıyorsa, firmadan o müşteriyle bir görüşme ayarlamasını isteyin.

Ardından insanları kontrol edin. Sisteminiz üzerinde çalışacak mühendislerin adlarını ve Rust deneyimlerini öğrenin, imzalamadan önce onlarla konuşun. Yukarıda bağlantısı verilen özel ekipler hakkındaki yazı genel kontrolleri ele alıyor: açık kod, ücretli bir deneme işi ve bağımsız bir mühendisin incelemesi.

Bir trading platformunun hangi parçaları Rust ile yazılmalı?

Bir emrin yolu üzerindeki parçalar; orada birkaç milisaniyelik bir duraklama, müşterinin aldığı fiyatı değiştirebilir:

• Alış ve satış emirlerini fiyata ve geliş zamanına göre eşleştiren matching engine
• Bir limiti aşan emri piyasaya ulaşmadan durduran işlem öncesi risk kontrolleri
• Emirleri borsalara ya da aracı kurumlara gönderen ve yanıtlarını alan gateway'ler
• Fiyat akışlarını okuyan ve her güncellemeyi bir sonraki adıma ileten piyasa verisi işleyicisi

Rust bu parçalara uygundur, çünkü belleği bir çöp toplayıcı olmadan serbest bırakır. Bazı diller bu iş için bir çöp toplayıcı kullanır ve o, programı kendi seçtiği anlarda duraklatabilir. Dilin resmi kılavuzu olan Rust kitabı (27 Ekim 2026'da okundu), bunun arkasındaki kurallar bütünü olan sahipliğin (ownership) “Rust'ın bir çöp toplayıcıya ihtiyaç duymadan bellek güvenliği garantileri vermesini sağladığını” söylüyor.

Dil tek başına bir sistemi hızlı yapmaz. Bir Rust programı da bellek istemek, başka bir iş parçacığının tuttuğu bir kilidi beklemek ya da ağı beklemek için durabilir. Matching engine tasarımı hakkındaki yazı, bir ekibin bunları emir yolunun dışında nasıl tuttuğunu anlatıyor.

Platformun geri kalanında milisaniyelerle ölçülen bir süre sınırı yoktur: web ve mobil ekranlar, müşteri hesapları, raporlar, back office ve yönetim araçları. Bunlar geliştiricilerinizin ya da tedarikçilerinizin zaten kullandığı dillerde kalabilir. Bunları Rust ile yeniden yazmayı öneren bir firma, bunun size ne kazandıracağını açıklamalıdır.

Platformumuz zaten C++, Java ya da Go ile çalışıyor. Rust ile yeniden yazmalı mıyız?

Genellikle hepsini birden değil. Daha güvenli yol, risk kontrolleri ya da piyasa verisi işleyicisi gibi sınırları net bir bileşeni taşımak ve gerisini olduğu gibi bırakmaktır.

Yeni bileşen, sistemin geri kalanıyla mesaj alışverişi yapan ayrı bir servis olarak çalışabilir. C ya da C++ kodunun doğrudan çağırdığı bir kütüphane olarak da kurulabilir. Rust projesinin unsafe ve düşük seviyeli kod üzerine kılavuzu Rustonomicon, bunun nasıl yapılacağını “Calling Rust code from C” başlıklı bölümde anlatıyor.

Geçişten önce yeni bileşeni, aynı kaydedilmiş emir akışı üzerinde eskisinin yanında çalıştırın ve her sonucu karşılaştırın. Deterministik bir matching engine, aynı sırayla gelen aynı emirler için her zaman aynı sonucu verir. Bu da karşılaştırmayı basitleştirir: İki motor da aynı kuralları uyguluyorsa, her fark ikisinden birindeki bir hataya işaret eder.

Ardından her seferinde bir piyasayı ya da bir enstrüman grubunu taşıyın ve trafiği geri almak için eski bileşeni hazırda tutun.

Bir matching engine için dışarıdan çalışan özel bir Rust ekibinde kimler olur?

Özel bir ekip aylarca ya da yıllarca yalnızca sizin sisteminiz üzerinde çalışır ve üyeleri ancak siz kabul ettiğinizde değişir. Bir matching engine ya da emir yolunun başka bir parçası için ekipte genellikle şunlar bulunur:

• Canlı ortama kod çıkarmış ve bir emrin nasıl yaşadığını bilen Rust mühendisleri: emir türleri, kısmi gerçekleşmeler, değişiklikler ve iptaller
• Tasarımın sorumluluğunu taşıyan ve emir yolundaki her değişikliği inceleyen bir lider mühendis
• Kaydedilmiş emir akışını yeniden oynatan ortamı kuran ve sonuçları kontrol eden bir test mühendisi
• Sunuculardan, ağ ayarlarından ve sürümlerden sorumlu biri

Şirketinizin de bunda bir rolü var. Sizin tarafınızdan biri işlem kurallarını, örneğin fiyat adımlarını, işlem saatlerini, ücretleri ve işlemler durduğunda ne olacağını belirler ve ekibin bunlarla ilgili sorularını uzun gecikmeler olmadan yanıtlar.

Serbest çalışanlar mükemmel mühendisler olabilir, ama onlarla süreklilik daha zordur. Tek başına çalışan bir yüklenicinin emir yolundaki değişikliklerini inceleyecek kimsesi yoktur; o kişi ayrıldığında sisteminiz hakkında bildikleri de onunla birlikte gider. Bir firma birinin yerine başkasını koyabilir ve bilgiyi ekibin içinde tutabilir; sözleşme de bunu ona şart koşabilir.

Bir firma ekibin büyüklüğünü ancak işlem kurallarınızı, piyasalarınızı ve hacimlerinizi gördükten sonra belirleyebilir; bu yüzden önerdiği sayıya nasıl ulaştığını sorun.

Bir matching engine hakkında bir Rust ekibine ne sormalıyız?

Hız rakamlarının nasıl kontrol edileceğini düşük gecikmeli sistemler yapan firmalar hakkındaki yazı ele alıyor. Bu sorular Rust ve emir yolu hakkında:

• Kodunuz unsafe'i nerede kullanıyor ve bu kısımları kim inceliyor?
• Kaydedilmiş emirleri yeniden oynatmanın ötesinde motoru nasıl test ediyorsunuz?
• Emir yolu hangi crate'lere bağlı ve bunları bilinen güvenlik açıklarına karşı nasıl kontrol ediyorsunuz?
• Hangi Rust sürümüyle derliyorsunuz ve ne zaman güncelleyeceğinize nasıl karar veriyorsunuz?
• Önerilen ekipte kim Rust'ı canlı ortama çıkardı, hangi sistemde ve o sistem hâlâ çalışıyor mu?

Rust, belleğin nasıl kullanıldığını kod derlenirken kontrol eder. unsafe olarak işaretlenmiş bir bloğun içinde kod, derleyicinin normalde reddettiği beş şeyi yapabilir; örneğin ham bir işaretçiyi izleyerek belleğe erişebilir. Rust kitabı ayrıca unsafe'in “borrow checker'ı kapatmadığını ya da Rust'ın diğer güvenlik kontrollerinden herhangi birini devre dışı bırakmadığını” ekliyor. İyi bir yanıt, unsafe kodun nerede olduğunu, orada neden gerektiğini ve onu kimin kontrol ettiğini söyler.

Test konusunda bir ekip kullandığı araçların adını verebilmelidir. Rust Fuzz Book'un “Rust kodunun fuzz testi için önerilen araç” dediği cargo-fuzz, bir programı çökerten durumları bulmak için ona büyük miktarda üretilmiş girdi verir. Birden fazla iş parçacığında çalışan kodu test etmek için bir kütüphane olan Loom ise “testleri birçok kez çalıştırır ve her testin olası eşzamanlı yürütmelerini permütasyonla değiştirir”. Böylece yalnızca iş parçacıkları şanssız bir sırayla çalıştığında ortaya çıkan hatalar bulunur.

Crate'ler, Rust'taki paylaşılan kod paketleridir. RustSec Advisory Database, crates.io'da yayımlanan crate'lerle ilgili güvenlik bildirimlerini kaydeder. Aracı cargo-audit, bir projenin her bağımlılığın tam sürümünü listeleyen dosyası Cargo.lock'u “güvenlik açığı bulunan crate'ler için” kontrol eder. Bir emir yolu üzerinde çalışan ekip, bu kontrolün her derlemede çalışıp çalışmadığını size söyleyebilmelidir.

Rust her altı haftada bir yeni bir kararlı sürüm yayımlar ve Rust kitabı “kararlı Rust'ın yeni bir sürümüne yükseltmekten asla korkmanız gerekmemeli” diyor. Yine de bir ekip tüm derlemeleri seçtiği tek bir sürümde tutabilir. Rust'ın kurulum aracı rustup'ın belgeleri, kendini “belirli bir Rust sürümüne ‘sabitlenmiş’” bulan ve bunu deposuna kaydetmek isteyen projeler için bir toolchain dosyasını anlatıyor. Bir emir yolunda sürüm yalnızca bilerek ve testler geçtikten sonra değişmelidir.

Bir Rust ekibiyle yapılan sözleşmede ne yazmalı?

Şu maddeleri sözleşmeye yazın:

• Kod, testler, tekrar oynatma verileri ve derleme betikleri şirketinizin sahibi olduğu depolarda durur
• Derlemeler ve sürümler şirketiniz adına açılmış hesaplarda çalışır
• Emir yolunu kimin değiştirebileceği ve her değişikliği kimin inceleyeceği
• Ekibin kapsadığı saatler ve motor bu saatlerin dışında arızalanırsa kimin müdahale edeceği
• Sözleşme sona ererse elinize ne geçeceği: belgeler, erişimler ve ekibin işi bir sonraki ekibe devretmek için ayıracağı zaman

amBrain nerede devreye girer?

Bu blogu yayımlayan amBrain kendini tek satırda şöyle tanımlıyor: “amBrain, Erivan (Ermenistan) merkezli bir yazılım mühendisliği şirketidir; Rust ile low latency trading platformları, matching engine'ler ve real-time bidding sistemleri geliştirir.” Bir başka satır şöyle: “amBrain, algoritmik trading altyapısı geliştirir: emir gerçekleştirme, piyasa verisi ve işlem öncesi risk kontrolleri.”

amBrain 2019'dan bu yana yazılım geliştiriyor. Ekibini kendi sözleriyle şöyle anlatıyor: “40 kişiye kadar bir ekip, yaklaşık %75'i kıdemli.” Üç formatta çalışıyor: tam teslim, özel ekip ya da sizin ekibinize yerleşen mühendisler. Mülkiyet konusundaki satırı ise şöyle: “Müşteri, yeniden kullanılabilir bileşenlerimiz dışında ürünün ve kodun tam mülkiyetini elinde tutar.”

Bu yazı bir vaka çalışması değildir ve hiçbir müşteri çalışmasını anlatmaz. amBrain'in Rust ile hangi sistemleri kimin için kurduğunu söylemez; amBrain'e ait fiyat, takvim ya da ekip büyüklüğü de vermez. amBrain kısa listenizdeyse, ona da diğer her firmaya yönelttiğiniz soruların aynısını yöneltin.