Nejdřív vymezte typ platformy
Slovo trading platforma může znamenat klientské rozhraní, interní obslužný nástroj, datovou vrstvu, správu pokynů nebo jejich kombinaci. Tyto produkty mají odlišné požadavky na dostupnost, latenci, oprávnění a vysvětlení výsledku. Před technickým návrhem je třeba určit uživatele, trhy, typy nástrojů, časové horizonty a hranici mezi zobrazováním informací a provedením akce. Bez toho je snadné optimalizovat špatnou část systému.
Zadání by mělo popsat hlavní cestu uživatele, ale stejně důležité jsou výjimky: přerušené spojení, zastaralá cena, odmítnutý pokyn, částečné provedení a čas, kdy informace z různých zdrojů nesouhlasí. Kdo v takové chvíli rozhoduje a co platforma zobrazuje? První architektonický výstup je mapa odpovědností a stavů, nikoli výběr frameworku nebo vzhledu grafu. Konkrétní právní a licenční omezení se stanovují podle produktu a poskytovatelů.
Market data: původ, čas a úplnost
Cena není izolované číslo. Potřebuje zdroj, identifikaci instrumentu, časovou značku, kontext trhu a informaci o tom, zda je proud aktuální. Pokud se používá několik poskytovatelů, je třeba definovat pořadí jejich výběru, pravidla pro nesoulad a význam historického záznamu. Při zpoždění uživatel nemá vidět zdánlivě živou hodnotu bez upozornění. Kontrola kvality dat je součást produktového chování, nikoli jen technický alarm.
Proud aktualizací může obsahovat mezery, duplicity nebo změny pořadí. Příjemce musí vědět, kdy jeho lokální pohled přestal být spolehlivý a jak získá nový referenční stav. FIX Trading Community popisuje mechanismy snapshotů a inkrementálních aktualizací v prostředí tržních dat; konkrétní způsob obnovy ale závisí na zvoleném feedu a jeho smlouvě. Pilot by měl úmyslně přerušit spojení a ověřit, jak aplikace pozná ztrátu konzistence a co pak ukáže uživateli.
Pokyn není jedno tlačítko
Odeslání pokynu neznamená jeho provedení. Systém musí rozlišit přípravu, validaci, odeslání, přijetí druhou stranou, odmítnutí, částečné plnění, zrušení a konečný stav podle pravidel konkrétního prostředí. Jednotlivé stavy mají jiné dopady na disponibilní prostředky, informace pro uživatele a další povolené akce. Přehled musí být konzistentní i při opožděné odpovědi nebo opakovaném doručení zprávy.
Každý pokyn potřebuje identifikátor, který propojí uživatelskou akci, interní rozhodnutí a zprávy partnera. Při neznámém výsledku se platforma nesmí tvářit, že akce jistě selhala, ani ji bez ověření automaticky opakovat. Vývojáři, provozní tým i vlastník produktu by měli umět na společném stavovém diagramu vysvětlit, jak se systém chová při timeoutu a zpožděném potvrzení. Testy musí zahrnout kombinace zpráv v jiném pořadí než v ideálním scénáři.
Latence má význam jen v kontextu
Požadavek „nízká latence“ je příliš neurčitý. Je třeba určit, odkud kam se čas měří: od přijetí tržní zprávy po obrazovku, od potvrzení uživatele po odeslání pokynu nebo od přijetí odpovědi po aktualizaci stavu. U každé cesty je důležitý typický čas, špička, krajní hodnota i chování při přetížení. Samotné číslo bez metodiky může sloužit spíše marketingu než řízení kvality.
Měření začíná časovými značkami a korelací událostí na všech relevantních hranicích. Optimalizace se pak soustředí na skutečné úzké místo: síť, serializaci, databázi, frontu, vykreslení nebo externí službu. Někdy je důležitější garantovat správný stav a jasné upozornění na zpoždění než snižovat průměr o několik milisekund. Architektonická volba se musí vztahovat k typu produktu, množství dat a ceně chyby.
Bezpečnost, oprávnění a historie
Zobrazení dat, vytvoření pokynu, změna limitu a administrativní zásah jsou různé schopnosti. Oprávnění se vymezují podle role, účtu, nástroje a akce. Kritické změny mohou vyžadovat další potvrzení. Přihlašovací relace, tajemství a přístup partnera mají oddělený životní cyklus. Diagnostické logy nesmějí vytvářet neřízenou kopii citlivých dat; zároveň musí umožnit rekonstruovat průběh konkrétního incidentu.
Auditní záznam má odpovědět na otázku, jaké informace a možnosti byly v daný okamžik dostupné a jaké zprávy systém přijal. Pokud se tržní data později opraví, historie musí zachovat rozdíl mezi tehdy zobrazenou informací a pozdějším správným stavem. Konkrétní požadavky na uchovávání a reporting závisejí na právním a smluvním kontextu. Technický návrh je má podporovat až po jejich ověření, nikoli je na webu předstírat jako hotovou certifikaci.
Provozní dohled a obnova
Platforma potřebuje sledovat více než dostupnost HTTP serveru. Důležité jsou stáří feedu, mezery v sekvenci, čas zpracování pokynu, počet neznámých stavů a rozdíly mezi interní evidencí a partnerem. Každý alarm má mít vlastníka a postup, který se dá provést pod tlakem. Příliš mnoho signálů bez priority může incident naopak zpomalit. Způsob degradace je produktové rozhodnutí: některé akce je bezpečnější dočasně vypnout než zobrazovat nepodloženou jistotu.
Obnova po výpadku zahrnuje znovuzískání tržního stavu, doplnění chybějících zpráv a ověření otevřených pokynů. Pouhá obnova databáze nemusí odpovídat realitě u externího poskytovatele. Pro každý kritický tok je třeba stanovit, co lze přehrát, co se musí znovu dotázat a co vyžaduje člověka. Cvičení obnovy v testovacím prostředí často odhalí předpoklady, které běžný funkční test nevidí.
První pilot a kontrolní otázky
První pilot má propojit malou, ale úplnou cestu: identifikace instrumentu, příjem a zobrazení dat, příprava pokynu, odeslání, potvrzení a dohledatelný výsledek. Současně má simulovat výpadek feedu a neznámý stav pokynu. Tím se ověří technické i uživatelské hranice. Graf s testovacími daty může pomoci vizualizaci, ale sám o sobě neprokazuje bezpečnou obchodní cestu. Po pilotu má být jasné, která část závisí na skutečných rozhraních partnera.
Před odhadem dalšího vývoje získejte dokumentaci a testovací přístup k datům a exekuci, vlastníka licencí, seznam rolí, objem a očekávané časy kritických cest. Zapište pravidla pro neúplné a opožděné informace. Rozhodněte, kdo odpovídá za tržní data, kdo za rozhodnutí o pokynu a kdo řeší reklamaci. To umožní vymezit první produkční rozsah, rozumné měření a postup nasazení bez slibů, které nejsou podložené konkrétním prostředím.
Při srovnání architektonických variant není vhodné zaměňovat klientské rozhraní za celou obchodní platformu. Hotové obchodní jádro, integrační vrstva a vlastní uživatelská aplikace mohou mít různé vlastníky i cykly změn. U každé varianty porovnejte kontrolu nad stavem pokynu, dostupnost testovacího prostředí, licenční hranice, způsob obnovy a náklady na budoucí změnu. Pokud partner neposkytuje dostatečné události pro rekonstrukci průběhu, atraktivní uživatelské rozhraní tuto mezeru neodstraní. Pokud naopak existující služba spolehlivě řeší exekuci, vlastní vývoj celé této části může přidat riziko bez odpovídající hodnoty. Rozhodnutí má vycházet z ověřeného kontraktu a požadovaného provozního modelu. Užitečná je malá zkouška přepnutí mezi zdroji dat a simulace zpožděného potvrzení pokynu. Ukáže, zda se chování všech částí dá vysvětlit uživateli i provoznímu týmu bez improvizace během incidentu.
- Která zpráva je zdrojem pravdy pro cenu, stav pokynu a konečné plnění?
- Jak uživatel pozná, že data jsou opožděná nebo neúplná?
- Co platforma udělá, když odešle pokyn, ale odpověď nepřijde?
- Jak se zpracuje duplicitní nebo pozdě doručené potvrzení?
- Lze rekonstruovat, co bylo zobrazeno v okamžiku rozhodnutí?
- Kdo schvaluje změnu obchodního pravidla nebo limitu?
- Jak se po výpadku sladí interní stav s partnerem?
- Které časy se měří a jaká hodnota je pro uživatele skutečně důležitá?