Vymezte produkt a životní cyklus pokynu
Nejdřív určete, pro koho platforma slouží a které kroky skutečně provádí. Jiné hranice má informační terminál, jiné zadávání pokynů a jiné systém zajišťující směrování k protistraně. Nakreslete cestu od zobrazení ceny přes zadání, kontrolu, odeslání, potvrzení, částečné plnění, změnu, zrušení až po vypořádání či export. U každého stavu uveďte, kdo jej může vytvořit a kdo potvrzuje jeho konečnost. Odpověď „přijato“ nemusí znamenat „provedeno“. Tyto rozdíly mají být viditelné uživateli i podpoře a ověřené s vlastníkem obchodního procesu.
Zaznamenejte obchodní pravidla pro typy pokynů, čas platnosti, měnu, množství, zaokrouhlování a opravu chyby. Konkrétní funkce a regulatorní povinnosti se řídí produktem, trhem a jurisdikcí; nevyvozujte je z obecného technického návodu. Určete, zda platforma pracuje s portfoliem, disponibilním zůstatkem a interním deníkem, nebo tyto informace pouze čte z jiného systému. Jedna operace může být rozpracovaná v několika systémech současně. Proto musí existovat stabilní identifikátor a vysvětlitelný stav, nikoli jen poslední text v uživatelském rozhraní.
Oddělte tržní data od rozhodnutí o obchodu
Cenový feed má vlastní zdroj, licenci, frekvenci, časové značky a pravidla pro zpožděná nebo neplatná data. Uživatel musí vědět, zda vidí aktuální či opožděnou cenu. Definujte, co se stane při výpadku feedu: zastavení zadání, poslední známá hodnota s označením, nebo přechod na jiný zdroj podle schváleného pravidla. Neodvozujte obchodní pravdu z toho, co se zrovna podařilo vykreslit v prohlížeči. Datová služba má kontrolovat duplicity, pořadí, chybějící intervaly a odchylky, které mohou signalizovat nekvalitní vstup.
Historická data pro graf a data použitá při rozhodnutí nemusí mít stejný původ ani požadavek na přesnost. Uložte, z jakého zdroje a s jakým časem pocházela relevantní hodnota při důležité akci, pokud to produkt potřebuje pro vysvětlení. Při více poskytovatelích stanovte pravidlo přepnutí a upozornění na rozdíl. Licence poskytovatele mohou omezit ukládání či zobrazení; smluvní podmínky ověřte před návrhem cache. Testujte reakci na skok, výpadek a pozdě doručenou opravu. Plynulý graf nemá skrývat, že část hodnot byla dopočtena nebo chyběla.
Předobchodní kontroly potřebují jasnou odpovědnost
Před odesláním pokynu stanovte, které kontroly musí proběhnout: oprávnění klienta, dostupnost nástroje, limity množství a částky, platnost parametrů a případně dostatečné krytí. Přesný seznam závisí na produktu a odpovědnosti firmy. Rozlište kontrolu provedenou ve vašem systému od pravidla protistrany; úspěch první nezaručuje přijetí druhou. Stav a důvod zamítnutí musí být srozumitelný a dohledatelný. Kontroly nesmí číst různé zastaralé kopie stejného limitu bez rozhodnutí, který zdroj je autoritativní. Souběžné pokyny vyžadují zvláštní pozornost k rezervaci prostředků.
Pravidla rizika by měla být verzovaná a jejich změna schvalovaná podle dopadu. Pokud operátor upraví limit, zaznamenejte kdo, proč, kdy a na jaké případy změna působí. Ověřte chování při výpadku služby kontrol: systém má bezpečně odmítnout nebo pozastavit akci podle zvoleného režimu, nikoli potichu přeskočit ochranu. Testujte hraniční hodnoty, měnu, časovou platnost a opakovaný požadavek. Změna pravidel může mít větší obchodní dopad než změna obrazovky, proto potřebuje samostatný proces vydání a rychlého návratu.
Integrační vrstva musí rozumět pořadí a opakování
Protokol k protistraně může přinášet vlastní identifikátory, sekvence, potvrzení a obnovu spojení. FIX Trading Community popisuje FIX session jako pořadový proud zpráv s mechanismem opětovného navázání; konkrétní použití závisí na připojované straně. Oddělte doménový stav pokynu od technického stavu spojení. Výpadek socketu není automaticky zamítnutí obchodu. Po obnově je třeba zkontrolovat, které zprávy protistrana přijala a v jakém pořadí. Přímé propojení uživatelské akce s jedinou odpovědí bez interní evidence vytváří nebezpečnou nejasnost při timeoutu.
Každá měnící operace má mít stabilní identifikátor, aby opakování po chybě nevytvořilo nový pokyn. Microsoftův vzor idempotentního příjemce ukazuje, proč opakované doručení nemusí znamenat opakovaný účinek. Ukládejte vazbu mezi interním ID, ID protistrany a zprávami o změně stavu. Definujte, jak se řeší pozdní potvrzení, duplicitní plnění a ruční korekce. Adaptér má protokol překládat, nikoli rozhodovat o obchodním významu bez vlastníka. Pokud je napojeno více protistran, jejich rozdílné stavy převeďte do společného modelu bez ztráty původních detailů.
Audit a rekonciliace jsou součást toku
Uložte sled událostí potřebný k vysvětlení pokynu: původní zadání, přijaté parametry, výsledek kontrol, odeslanou zprávu, potvrzení, plnění a opravy. Auditní záznam musí mít čas, zdroj a vazbu na případ. Přístup k němu omezte podle role a citlivosti. Není nutné kopírovat celé osobní údaje do každého technického logu. Operátor potřebuje přehled, co se stalo a co je další krok; auditor potřebuje důkaz změny a jejího schválení. Tyto pohledy mohou vycházet ze stejných událostí, ale nemusejí ukazovat stejné detaily.
Rekonciliace porovnává interní stav se záznamy protistrany a případně s vypořádáním. Nastavte frekvenci a toleranci pro rozdíl v množství, částce či stavu. Výjimky nesmí zmizet v souhrnném čísle. Každá má mít odpovědnou osobu, termín a dokumentovanou opravu. Zvlášť sledujte pokyny s neznámým výsledkem, částečná plnění a změny po uzávěrce. Ruční zásah nemá přepsat historii; má vytvořit novou dohledatelnou událost. Proces rekonciliace ověřte na testovacích neshodách, nikoli až při ostré závadě.
Výkon měřte na celé cestě, ne jen na obrazovce
Stanovte požadovanou odezvu pro zobrazení dat, potvrzení přijetí pokynu a konečný výsledek odděleně. Čas v prohlížeči, interní frontě a u protistrany se sčítá, ale jednotlivé části mají jiné vlastníky. OpenTelemetry popisuje distribuované stopy, které pomáhají sledovat operaci přes služby. Zachovejte korelační ID a bezpečně redigované diagnostické údaje. Sledujte percentily, fronty a počet případů s neznámým stavem, nikoli jen průměr. Optimalizace jedné API odpovědi nemá smysl, pokud pozdější zpracování stojí minuty bez upozornění uživatele.
Otestujte očekávané špičky, výpadek feedu, zpomalení protistrany, obnovení spojení a současné pokyny nad stejným limitem. Při zátěži musí být stále správný stav a audit; rychlost bez správnosti není přínos. Oddělte části, které mohou čekat, od těch, které musí zastavit další akci. Připravte limity front a plán, jak zpracovat nahromaděné případy po obnovení. Kapacitu měňte podle měření, ne podle dojmu z architektury. Přehled pro podporu má ukazovat, zda se problém týká dat, kontrol, spojení nebo zpracování výsledku.
Nasazení musí být vratné a provoz vysvětlitelný
Změnu zkoušejte na omezené skupině uživatelů, instrumentů nebo typů operací, pokud to obchodní pravidla dovolí. Předem definujte kritéria zastavení: chybné stavy, nevysvětlené rozdíly, nárůst zamítnutí nebo zpoždění. Při návratu k předchozí verzi řešte i data a pokyny vytvořené po nasazení. Nacvičte obnovu ze zálohy a ověřte, že lze znovu spojit interní ID s ID protistrany. Vydání plánujte mimo kritická období, ale nepředpokládejte, že nízký provoz nahrazuje test. Každá změna pravidel a adaptérů potřebuje jasného schvalovatele.
Provozní návod má popsat, jak dohledat jeden pokyn, jak rozlišit výpadek připojení od obchodního zamítnutí a komu eskalovat neshodu. Do monitoringu patří kvalita feedu, stáří front, úspěšnost kontrol, stav spojení a počty otevřených výjimek. Alarm bez rozhodnutí o reakci je jen hluk. Při incidentu zachovejte důkazní data a komunikujte čitelný stav uživatelům. Po opravě vyhodnoťte příčinu a přidejte odpovídající test. Architektura je hotová teprve tehdy, když ji zvládne provozovat tým mimo původní implementaci.
Checklist pro architektonické rozhodnutí
Před stavbou potvrďte hranice produktu, životní cyklus pokynu, vlastníky dat, pravidla rizika, integrační smlouvy a zdroj tržních dat. U každé významné operace popište neznámý výsledek, opakování a rekonciliaci. Stanovte metriku správnosti i odezvy, scénáře testu a podmínky přepnutí. Začněte jednou trasou, kterou lze ověřit od zadání až po evidenci výsledku. Když největší nejistota leží u protistrany, nejprve ověřte její reálné chování, neprodukujte rozsáhlé interní rozhraní podle nepotvrzeného předpokladu.
EXCOIN může navrhnout konkrétní platformu či integrační vrstvu, ale bez znalosti trhu, produktu a připojených stran nelze slíbit latenci, regulatorní soulad nebo výsledek obchodování. Dobrý návrh má jasné hranice a prokazuje správnost na neúspěšném stejně jako na úspěšném pokynu. První milník má dodat model stavů, datové kontrakty, testovací scénáře a ověřený průchod jedné operace. Další rozsah se určí podle naměřeného výkonu a zjištěných výjimek. Tak se investice opírá o skutečné chování systému, nikoli o předčasně zvolený seznam technologií.
Zpětnou vazbu berte z provozu, ne jen z benchmarku
Po prvních týdnech porovnejte naměřené časy s tím, jak práci vnímají uživatelé a podpora. Rychlé vykreslení může skrýt dlouhé čekání na konečné potvrzení; technicky správné zamítnutí může být formulováno tak nejasně, že vede k opakovanému zadání. Zajímejte se o počty pokynů s neznámým výsledkem, ruční dohledávání, nesoulad mezi systémy a kvalitu cenových upozornění. Každou zásadní výjimku proměňte v test a případně v úpravu modelu stavů. Samotný zátěžový test před spuštěním nemůže nahradit pozorování reálného provozu.
Při rozšíření na další trh nebo protistranu nejprve ověřte, zda se mění obchodní význam stavů, časová pravidla a způsob vypořádání. Společný technický adaptér může znovu použít přenos a monitoring, ale nesmí předstírat, že všechna pravidla jsou totožná. Udržujte mapu rozdílů a odpovědné osoby pro její schválení. Pokud nová integrace vyžaduje výjimku, zapište, zda je dočasná, jak se testuje a kdo ji odstraní. Tak se architektura rozšiřuje bez skrytého hromadění speciálních případů, kterým později nikdo nerozumí.