Trading platforması üçün order management system development işinin əsas məqsədi sifarişləri sadəcə göndərmək deyil; hər sifarişin hansı anda, hansı səbəblə və hansı xarici icra hadisəsi nəticəsində hansı vəziyyətə keçdiyini sübut edilə bilən şəkildə idarə etməkdir. OMS order lifecycle üçün authoritative layer olmalıdır: mobil tətbiq, web terminal, dealer paneli, FIX gateway və ya liquidity bridge fərqli məlumat göndərsə belə, daxildə eyni canonical order modeli və dəyişməz hadisə tarixi qalmalıdır.
Bu, pricing engine, liquidity bridge, pre-trade risk və reconciliation sistemlərini əvəz etmir. Qiymət mühərriki quote yaradır, bridge route seçir, risk sistemi sifarişi qəbul etməzdən əvvəl yoxlayır, reconciliation isə xarici qeydlərlə fərqləri aşkar edir. OMS isə qəbul edilmiş niyyəti, göndərilmiş təlimatları, icra hadisələrini və müştəriyə göstərilən lifecycle vəziyyətini birləşdirir.
OMS üçün başlanğıc nöqtəsi: identifier-lər və dəyişməz event jurnalı
Bir broker order lifecycle management system yalnız brokerin order ID-si ilə qurulmamalıdır. Hər order və request üçün ayrıca identifier strategiyası lazımdır:
- InternalOrderId: OMS-in dəyişməyən əsas açarı.
- RootOrderId: replace zəncirinin ilk biznes orderinə bağlanan identifier.
- ClientRequestId: istifadəçinin submit, cancel və ya amend əməlini idempotent edən unikal açar.
- RevisionId: qəbul olunmuş hər yeni order versiyası üçün nömrə.
- VenueOrderId / ExternalOrderId: venue, broker və ya liquidity provider tərəfindən qaytarılan identifikator.
- ExecutionId: hər fill, correction və trade-bust hadisəsini təkrarsız tanıyan açar.
- CorrelationId: API request, gateway mesajı, queue consumer və operator əməlini bir trace-də birləşdirən texniki açar.
Bu açarlarla birlikdə append-only event store saxlanmalıdır. Məsələn, OrderSubmitted, RiskAccepted, RouteRequested, VenueAcknowledged, ExecutionReceived, CancelRequested, ReplaceAccepted, TradeCorrected və RecoveryReconciled ayrıca hadisələrdir. Hadisəni sonradan “update” etməyin; səhv məlumatı düzəltmək üçün onu referens edən yeni correction və ya reversal event yazın.
Event qeydi minimum olaraq event ID, order ID, event type, source, source message ID, qəbul vaxtı, source timestamp, raw payload-a istinad və payload hash saxlamalıdır. Operatorun manual düzəlişi də istifadəçi, rol, səbəb kodu və əvvəlki/yeni dəyərlərlə audita düşməlidir. Bu yanaşma həm insident araşdırmasını, həm də projection-ların yenidən qurulmasını mümkün edir.
State machine: “status” tək sütun olmamalıdır
Sadə NEW → FILLED → CANCELED sxemi real bazar davranışını izah etmir. OMS-də ən azı üç ayrı anlayışı model edin: order-in iqtisadi icra vəziyyəti, əməliyyat request-lərinin vəziyyəti və müştəriyə göstərilən summary status.
Praktik əsas vəziyyətlər
- Draft / ValidationPending / RiskRejected: hələ marketə göndərilməmiş niyyət və daxili yoxlama nəticəsi.
- PendingNew / Working: venue cavabı gözlənilir və ya order aktivdir.
- PartiallyFilled / Filled: cumulative fill quantity əsasında iqtisadi icra vəziyyəti.
- PendingCancel / Canceled: cancel sorğusu qəbul olunub, lakin hələ təsdiqlənməyib; sonra cancellation nəticəsi gəlir.
- PendingReplace / Replaced: amend sorğusu in-flight-dir və ya yeni revision qüvvəyə minib.
- Rejected / Expired / DoneForDay: orderin daha artıq icrası gözlənilməyən nəticələri.
- SuspendedForRecovery: outage zamanı statusu təxmin etmədən, xarici həqiqət mənbəyi ilə sync gözləyən daxili əməliyyat vəziyyəti.
Pending cancel, canceled demək deyil; pending replace də yeni qiymət və ya həcmdə orderin artıq işlədiyini göstərmir. FIX Trading Community state-change nümunələrində pending statusların icra statusu ilə eyni vaxtda mövcud ola biləcəyi və status precedence qaydalarının lazım olduğu göstərilir. Xüsusilə cancel gözlənilərkən yeni fill gələ bilər. Buna görə UI “cancel requested” yazmalı, lakin fill-ləri dərhal əks etdirməlidir.
Partial fill, cancel və replace məntiqi
Hər execution event üçün OMS LastQty, LastPx, CumQty, LeavesQty və average price projection-ını idarə etməlidir. Əsas invariant-lar aydındır: cumulative quantity mənfi ola bilməz; normal fill yalnız açıq quantity-ni azaldır; accepted revision üçün leaves quantity adətən order quantity minus cumulative quantity-dir. Lakin trade bust və correction hadisələri cum quantity-ni geriyə dəyişə bilər. Bu səbəbdən fill-ləri sadəcə “toplamı artır” kimi yazmaq yetərli deyil: hər fill ayrıca iqtisadi hadisə və execution ID ilə saxlanmalıdır.
Cancel/replace üçün köhnə orderi silib yenisini yaratmaq təhlükəlidir. Biznes baxımından bir root order, bir neçə revision və bir neçə request ola bilər. Replace request əvvəlki qəbul olunmuş revision-a bağlanmalı, eyni anda gələn iki amend request isə per-order serializasiya qaydası ilə işlənməlidir. Əgər venue bir request-i gec qəbul edirsə və arada fill gəlirsə, yeni requested quantity artıq cum quantity-dən aşağı ola bilməz. Sistem bunu venue-yə göndərməzdən əvvəl yoxlamalı, venue rejection-ını isə ayrıca event kimi saxlamalıdır.
Out-of-order, duplicate və gecikmiş mesajlar
Trading execution event processing “exactly once delivery” fərziyyəsinə güvənməməlidir. Praktik dizayn at-least-once input, idempotent application prinsipidir. Consumer əvvəl source, execution ID və event type əsasında deduplication yoxlamalı, sonra event jurnalına atomik şəkildə yazmalı və yalnız bundan sonra projection yeniləməlidir.
Mesajlar ardıcıllıqla gəlməyə də bilər: fill venue acknowledgement-dən əvvəl, cancel reject isə fill-dən sonra çata bilər. Source sequence number varsa onu saxlayın, amma arrival order-i biznes həqiqəti kimi qəbul etməyin. Event-i qəbul edin, onun bağlı olduğu order/revision mövcud deyilsə quarantine və ya pending-association queue-yə qoyun, heç vaxt səssizcə itirməyin. Mümkün olduqda snapshot sorğusu və ya execution replay ilə boşluğu bağlayın.
Outage sonrası recovery: statusu uydurmayın
OMS restart zamanı son database snapshot-a etibar etməklə kifayətlənməməlidir. Recovery proseduru belə olmalıdır:
- Order acceptance və ya riskli client action-ları kontrollu şəkildə dayandırın.
- Event journal-dan projection-ları yenidən qurun və son işlənmiş source offset-ləri yoxlayın.
- Hər aktiv route üçün venue open-order snapshot, execution download və ya session recovery mexanizmini işə salın.
- Xarici məlumatı local event-lərlə müqayisə edin; missing fill, unknown order, quantity mismatch və duplicate execution-ları exception kimi yaradın.
- Fərqləri auditli recovery event-ləri ilə tətbiq edin; hər reconciliation fərqini avtomatik “normal” saymayın.
- Yalnız açıq orderlər, exposure, risk limitləri və client projection-ları yoxlanandan sonra traffic-i mərhələli açın.
Müştəri ekranında “working” görünən orderin əslində venue-də filled olması ən bahalı status səhvlərindəndir. Buna görə client timeline raw protocol mesajları deyil, izah edilə bilən biznes hadisələri, fill-lər, pending request-lər və source time-ları göstərməlidir.
Alıcı üçün OMS hazırlama checklist-i
- Order, request, revision, venue order və execution üçün ayrı identifier-lər varmı?
- Cancel və replace ayrıca request lifecycle kimi modellənirmi?
- Duplicate fill, correction, bust və out-of-order event test ssenarilərinə daxildirmi?
- Event jurnalından order projection-ını tam rebuild etmək mümkündürmü?
- Operator override-ları reason code və immutable audit record ilə qorunurmu?
- Recovery zamanı venue snapshot-ları və exception queue-ları varmı?
- API və UI “pending” statusu ilə “final” nəticəni dəqiq fərqləndirirmi?
POLADO trading məhsullarında OMS-i routing, risk, client portal və back-office ilə sərhədləri aydın olan authoritative lifecycle qatı kimi dizayn edir. FinTech və trading sistemləri xidməti çərçivəsində order modelini, inteqrasiya contract-larını və operational ekranları birlikdə planlaşdırmaq mümkündür. Dayanıqlı release, recovery runbook və monitorinq ehtiyacları üçün texniki dəstək və konsaltinq, sıx order timeline-ları və dealer workflow-ları üçün isə UI/UX və məhsul dizaynı komandası ilə işləmək olar. Mövcud bridge və ya broker API-lərinizə uyğun OMS sərhədlərini qiymətləndirmək üçün POLADO ilə konsultasiya planlaşdırın.