Trading platform order management development zamanı ən riskli səhvlərdən biri sifarişi sadəcə created / filled / cancelled statusları olan bir database qeydi kimi modelləşdirməkdir. Real icra axınında bir sifariş qəbul edilə, qismən icra oluna, ləğv sorğusu gözləyərkən yenidən fill ala, replace sorğusundan imtina edilə və ya brokerdən gecikmiş status yeniləməsi gələ bilər. Buna görə etibarlı sistem sifarişin cari görünüşünü saxlamalı, lakin həqiqəti dəyişməz hadisələr tarixçəsindən qurmalıdır.

Bu yanaşma broker-connected terminallar, daxili dealing alətləri, əməliyyat masası workflow-ları və investisiya platformaları üçün vacibdir. Məqsəd yalnız “düzgün status göstərmək” deyil: istifadəçinin mövqeyi, açıq qalıq həcmi, orta icra qiyməti, audit izi və brokerlə hesablaşma eyni reallığı əks etdirməlidir.

Sifariş bir obyekt yox, həyat dövrü və hadisələr zənciridir

Bir istifadəçi “Buy 1,000” düyməsinə basanda ən azı dörd ayrı şey baş verir: platforma niyyəti qeyd edir, brokerə sorğu göndərir, broker və ya venue sifarişin vəziyyətini emal edir, sonra icra və status mesajları geri qayıdır. Bu addımlar eyni anda baş vermir və mesajlar həmişə ideal ardıcıllıqla gəlmir.

Ona görə modeldə iki anlayışı ayırın:

  • Order intent: istifadəçinin göndərmək istədiyi ilkin parametr dəsti — alət, side, həcm, order type, limit qiyməti, time-in-force və hesab.
  • Execution facts: brokerin qəbul etdiyi, rədd etdiyi, icra etdiyi, dəyişdirdiyi və ya ləğv etdiyi barədə müşahidə edilən faktlar.

İstifadəçi interfeysində bir “sifariş kartı” görünsə də, backend-də bunun arxasında platforma order ID-si, hər sorğu üçün client request ID-si, broker order ID-si, replace zəncirində əvvəlki identifikatorlar və ayrı-ayrı fill-lər üçün execution ID-lər olmalıdır. Brokerin verdiyi order ID-ni platformanın daxili biznes identifikatoru ilə eyniləşdirmək gələcəkdə izahı çətin olan əlaqələndirmə problemləri yaradır.

Praktik order state machine necə görünməlidir?

State machine həm istifadəçiyə göstərilən sadə vəziyyəti, həm də inteqrasiya əməliyyatlarını ifadə etməlidir. Məsələn, aşağıdakı statuslar faydalı başlanğıc nöqtəsidir:

  • Draft / Validation failed: hələ brokerə göndərilməyən və ya yerli risk/format yoxlamasından keçməyən sifariş.
  • Pending submission: outbox-a yazılmış, lakin göndəriş nəticəsi hələ məlum olmayan sorğu.
  • Pending new / Working: brokerin emal etdiyi və ya qəbul edib bazara çıxardığı sifariş.
  • Partially filled: icra olunmuş həcm sıfırdan böyük, lakin qalıq həcm də sıfırdan böyükdür.
  • Pending cancel / Pending replace: ləğv və ya dəyişiklik sorğusu yoldadır; köhnə sifariş hələ icra ala bilər.
  • Filled, Cancelled, Rejected, Expired: terminal order vəziyyətləri.
  • Unknown / Reconciliation required: platformanın etibarlı nəticə çıxara bilmədiyi əməliyyat istisnası.

Bu siyahı broker protokolunun statuslarını kor-koranə UI statusuna çevirmək demək deyil. Məsələn, FIX-də ExecType konkret mesajın nə baş verdiyini, OrdStatus isə sifarişin cari statusunu ifadə edir. Pending replace zamanı gələn fill mesajı mümkündür; belə halda “replace gözləyir” və “qismən icra olunub” eyni order tarixçəsində paralel məna daşıyır. Platforma birini digərinin üzərinə yazmamalıdır.

Qalıq həcmi törəmə məlumatdır

Leaves quantity = accepted order quantity − cumulative executed quantity kimi hesablanmalıdır. Amma replace və korreksiya ssenarilərində accepted quantity dəyişə bilər. Buna görə hər fill üçün ayrıca həcm, qiymət, vaxt, execution ID və mənbə saxlayın; order-level cumQty, leavesQty və averagePrice isə bu faktlardan və brokerin təsdiqlənmiş snapshot-ından alınan proyeksiyalardır.

Partial fill handling: ilk fill son fill deyil

1,000 vahidlik limit sifarişi 250 + 300 + 450 şəklində icra oluna bilər. İstifadəçi ilk 250-dən sonra “250 icra olunub, 750 açıqdır” görməlidir; mövqe və rezervasiya məntiqi də həmin 250-ni nəzərə almalıdır. Yalnız son “Filled” mesajını gözləmək həm yanlış P&L, həm də yanlış risk görünüşü yarada bilər.

Hər trade hadisəsini idempotent şəkildə tətbiq edin. Broker eyni execution report-u yenidən göndərərsə, sistem ikinci dəfə mövqe yaratmamalı və cumulative quantity-ni ikiqat artırmamalıdır. Bu məqsədlə brokerin unikal execution ID-si əsas deduplication açarıdır. Belə ID yoxdursa, müqavilə üzrə müəyyən edilmiş stabil kombinasiyadan istifadə edin; timestamp və qiymət təkbaşına kifayət etmir.

Retry təhlükəsizliyi: “timeout” “rejected” demək deyil

Şəbəkə timeout-u aldıqda platforma brokerin sifarişi qəbul etmədiyini bilmir. Sorğunu kor-koranə yeni identifikatorla yenidən göndərmək iki real sifariş yarada bilər. Etibarlı dizayn üçün:

  1. İstifadəçi əməliyyatı üçün dəyişməz client request ID yaradın.
  2. Sifariş və göndəriləcək mesajı eyni lokal tranzaksiyada saxlayan outbox pattern istifadə edin.
  3. Brokerin idempotency key və ya client order ID mexanizmindən istifadə edin.
  4. Retry-dən əvvəl brokerin order-status endpoint-i, execution feed-i və ya sorğu tarixçəsi ilə nəticəni araşdırın.
  5. “Submission uncertain” vəziyyətini istifadəçidən gizlətməyin; “göndərilir, nəticə təsdiqlənir” kimi aydın mətn göstərin.

Cancel və replace sorğuları da ayrıca əməliyyatlardır. Onların hər birinin öz request ID-si, cavab statusu və original order chain əlaqəsi olmalıdır. Bu prinsip FinTech və trading sistemləri üçün hazırlanmış inteqrasiyalarda müşahidəolunan audit və bərpa ehtiyaclarının əsas hissəsidir.

Cancel/replace yarışları normal haldır

“Cancel” düyməsinə basılması sifarişin dərhal ləğv edilməsi demək deyil. Sorğu brokerə gedənə və broker/venue tərəfindən təsdiqlənənə qədər qalıq həcm icra oluna bilər. Eyni qayda qiymət və ya həcm dəyişən replace əməliyyatına da aiddir.

Məsələn, 1,000 vahidlik sifarişdən 300 vahid fill olub. İstifadəçi qalan hissəni ləğv edir. Cancel sorğusu pending ikən daha 100 vahid fill gəlir. Düzgün nəticə 400 icra, 600 ləğvdir — 300 icra və 700 ləğv deyil. Əgər broker “too late to cancel” qaytarırsa, UI “ləğv uğursuz oldu” deməklə kifayətlənməməli, sifarişin son məlum vəziyyətini də yenidən göstərməlidir.

Replace zəncirində platforma köhnə və yeni client identifier-ləri əlaqələndirməli, icraları düzgün order family-yə bağlamalıdır. Həcm artırılması, azaldılması və ya qiymət dəyişikliyi üçün brokerin semantikası fərqli ola bilər; inteqrasiya adapteri bu fərqləri vahid daxili komandaya çevirməlidir.

Dəyişməz event history və proyeksiya modeli

Ən praktik arxitektura iki qatlıdır:

  • Append-only event ledger: daxil olan webhook, FIX execution report, REST cavabı, operator müdaxiləsi və reconciliation nəticəsi olduğu kimi saxlanılır. Mənbə mesaj ID-si, qəbul vaxtı, broker vaxtı, raw payload-un təhlükəsiz referensi və parsing versiyası qeyd edilir.
  • Order projection: sürətli UI və API oxunuşu üçün cari status, filled/leaves quantity, orta qiymət, son yenilənmə və istisna bayraqları hesablanır.

Raw mesajı həmişə saxlamaq mümkün deyilsə, həssas məlumatları maskalayın və ya şifrələnmiş, giriş nəzarətli audit saxlancına yönləndirin. Əsas prinsip budur: cari order sətrini yeniləmək keçmiş faktı silməməlidir. Bu, gecikmiş callback, trade correction, trade cancel və əməliyyat araşdırması zamanı sistemi izah edilə bilən edir.

İstifadəçiyə hansı status göstərilməlidir?

Texniki protokol ifadələrini birbaşa istifadəçiyə ötürmək əvəzinə, sadə status və dəqiq detallar verin. Məsələn: “Qismən icra olunub — 400/1,000”, “Ləğv sorğusu gözləyir — sifariş hələ icra oluna bilər” və ya “Broker təsdiqi gözlənilir — təkrar sifariş yaratmayın”. Detal panelində qəbul edilən vaxt, son broker yenilənməsi, icra siyahısı, orta qiymət, qalıq həcm və cancel/replace sorğusunun nəticəsi görünməlidir.

Bu məlumat arxitekturası və error state-lər məhsul dizaynının bir hissəsidir. Trading ekranının davranışını yalnız backend deyil, UI/UX və məhsul dizaynı işi də müəyyən edir.

Reconciliation: günsonu yox, davamlı nəzarət mexanizmi

Reconciliation platformanın daxili proyeksiyasını brokerin etibarlı order/execution məlumatı ilə müqayisə edir. Günsonu faylları vacib ola bilər, lakin problem yalnız günün sonunda tapılmamalıdır. İntraday proses açıq sifarişlər, cumQty, leavesQty, terminal status, execution ID-lər və orta qiymət üzrə uyğunsuzluqları aşkarlamalıdır.

Uyğunsuzluq aşkar ediləndə avtomatik olaraq səssiz “düzəliş” etməyin. İstisna yaradın, fərqin mənbəyini qeyd edin, broker snapshot-ını və lokal event-ləri saxlayın, sonra təkrar emal və ya səlahiyyətli operator qərarı ilə proyeksiyanı yeniləyin. Əks halda platforma düzgün görünə, amma audit izi itirilə bilər.

Release-dən əvvəl yoxlama siyahısı

  • Eyni execution report iki dəfə gəldikdə mövqe və filled quantity dəyişmirmi?
  • Submit timeout-dan sonra ikinci order göndərilmədən nəticə araşdırılırmı?
  • Pending cancel zamanı gələn fill doğru hesablanırmı?
  • Replace reject və “too late to cancel” üçün UI son order vəziyyətini yeniləyirmi?
  • Broker mesajları səhv ardıcıllıqda gələndə event tarixçəsi qorunurmu?
  • Reconciliation fərqləri operatorun izləyə biləcəyi queue-ya düşürmü?

POLADO broker API-ləri, market-data qatları, əməliyyat interfeysləri və audit yönümlü backend-ləri bir məhsul kimi planlamağa kömək edir. FinTech yönümlü iş nümunələri üçün FT10 və ESFX layihələrinə baxın. Broker inteqrasiyanız üçün order lifecycle, istisna ssenariləri və reconciliation həcmini müəyyənləşdirmək istəyirsinizsə, texniki konsultasiya ilə başlamaq məqsədəuyğundur.