Dokončená integrace a hranice zveřejnění
EXCOIN dokončil zakázku integrace MetaTraderu 5 a 4 prostřednictvím vlastního API. Jméno klienta, smluvní rozsah, konkrétní servery, endpointy, licence a provozní měření nejsou veřejné. Následující podrobný rozbor vychází z technických problémů tohoto typu realizace; uváděné návrhové vzory jsou zobecněné a nelze z nich odvozovat přesnou podobu klientského prostředí. Typický broker chce jednotnou vrstvu pro portál, CRM, reporting a automatizaci, aniž by každý nový produkt znal rozdíly obou platforem.
Cílem není překrýt MT4 a MT5 jedním předstíraně totožným modelem. Obě platformy se liší v rozhraních, obchodních entitách i provozních možnostech. Vlastní API má sjednotit společné pojmy a současně zachovat schopnost vyjádřit funkce dostupné jen v jedné platformě. Každá taková odchylka musí být viditelná v dokumentaci, kontraktu a chybové odpovědi; tiché ořezání funkce by mohlo změnit význam obchodní operace.
Discovery: licence, API a matice schopností
První etapou je přístupový a licenční inventář. MetaQuotes pro MT5 uvádí mimo jiné Web API pro integraci s webovými službami, Manager API pro správu, Gateway API pro vazbu na jiné obchodní systémy a samostatná rozhraní pro reporty či serverová rozšíření. U MT4 popisuje Manager, WebServices, Server, DataFeed a Report API; nové licence MT4 již nenabízí. Z toho neplyne, že každá instalace brokera poskytuje každé rozhraní v požadovaném rozsahu. Přístup, verzi, oprávnění a smluvní právo použití je nutné potvrdit.
Výstupem discovery je matice schopností po konkrétních serverech: zdrojové rozhraní, dostupná metoda, potřebná role, vstupní a výstupní data, obchodní význam, limit, chybový stav a cílový endpoint. Zvlášť se eviduje, co lze číst, co lze měnit a co vyžaduje administrátorské oprávnění. „Kompletní implementace“ znamená pokrytí všech položek této schválené matice a zdokumentování výjimek, nikoli tvrzení, že neomezené veřejné API pokryje vše, co existuje uvnitř MetaTraderu.
Kontrakt custom API podle zákaznických procesů
Veřejný kontrakt navrhujeme kolem úloh klienta, nikoli jako mechanickou kopii funkcí dodavatele platformy. Odděluje správu klientů a účtů, skupiny a oprávnění, symboly a tržní data, pokyny a jejich historii, obchody, pozice, zůstatky a operace na účtu, reporty, administraci a systémové události. Pro každou skupinu vznikne inventář čtení, zápisu, stránkování, filtrování, verzí a citlivosti. Pojmenování endpointů se potvrdí až po mapování skutečných API.
Kontrakt stanoví měnu, přesnost objemu a ceny, časové pásmo, identifikátory účtů a obchodních entit, stavový slovník a způsob převodu chyb. Specifikace OpenAPI je verzovaná spolu s kódem; breaking change vyžaduje migrační plán a období souběhu. Platformně specifické atributy zůstávají explicitní v rozšíření schématu místo jejich ztráty. Klient nesmí z odpovědi poznat falešnou jistotu tam, kde backend zatím pouze přijal požadavek.
Adaptéry MT5 a MT4 a hranice zdroje pravdy
Každá platforma má vlastní adaptér izolovaný za doménovým kontraktem. Adaptér řeší autentizaci, dostupné vendor API, převod dat, limity volání, opětovné spojení a mapování chyb. Sdílená vrstva neobsahuje skryté větve podle platformy uprostřed business logiky; ty se testují v adaptérech. Při změně verze nebo přidání dalšího serveru lze ověřit dopad na jednu hranici místo opakované úpravy portálu, CRM a reportingu.
MetaTrader zůstává autoritativním zdrojem obchodního stavu, pokud konkrétní proces neurčí jinak. Vlastní databáze uchovává korelace, požadavky, projekce pro čtení a auditní události; nesmí se tvářit jako nezávislá pravda o konečném provedení. Projekce obsahují čas posledního potvrzení a verzi zdroje. Nesoulad mezi dvěma stavy vytváří úlohu k reconciliaci, nikoli tichý přepis. Tento princip brání tomu, aby rychlé uživatelské rozhraní zobrazovalo nepodložený konečný výsledek.
Pokyn, obchod, pozice a neznámý výsledek
V návrhu jsou oddělené entity požadavek, pokyn, provedení a pozice. Přijetí pokynu neznamená jeho provedení; částečné plnění, zamítnutí či zrušení musí mít vlastní stav podle skutečných schopností dané platformy a typu účtu. Před zápisem se ověřují oprávnění, parametry instrumentu, obchodní okno, limity a idempotency key. Odpověď API rozlišuje přijetí ke zpracování, potvrzený obchodní výsledek a stav, který je třeba dále zjistit.
Při timeoutu se stejný pokyn bez rozmyslu neopakuje. Vrstva uchová korelační identifikátor, pokusí se zjistit stav u zdroje a až podle něj rozhodne o bezpečném pokračování. Duplicitní webhook, opakovaná klientská žádost a restart workeru jsou běžné testovací scénáře. Reconciliation porovnává požadavky, serverové události a účtový stav včetně časového okna a výjimky pro ruční zásah. Kritériem akceptace je schopnost vysvětlit jeden konkrétní pokyn od požadavku až po konečný stav.
Globální infrastruktura bez iluze nulové latence
Celosvětová dostupnost se navrhuje podle regionů klientů, datových hranic a umístění obchodních serverů. Regionální okraj může poskytovat TLS, ochranu proti zahlcení a směrování; aplikační vrstvy mohou běžet ve více regionech pro čtení a zákaznické služby. Zápisové obchodní operace ale potřebují jasného vlastníka a autoritativní cestu k příslušnému MetaTrader serveru. Není bezpečné slibovat okamžitou konzistenci mezi kontinenty nebo automaticky rozdělit tentýž účet mezi dva aktivní zapisující regiony.
Návrh obsahuje dostupnost jednotlivých komponent, kapacitní limity, fronty, degradovaný režim a postup přesměrování provozu. Čtení může při výpadku ukázat poslední potvrzený stav s časovou značkou; zápis se zastaví, pokud nelze ověřit zdroj pravdy. Regionální failover se testuje včetně DNS/cache, opakování zpráv a obnovy připojení k platformě. Konkrétní SLO, p95/p99 latenci a RTO/RPO lze slíbit až po měření na infrastruktuře a v licenčním prostředí klienta.
Security, identita a oddělení rolí
Zákaznické přihlášení, servisní účty a privilegované role mají odlišné hranice. API používá krátkodobé tokeny s úzkým rozsahem, serverovou autorizaci pro každou operaci a oddělené oprávnění pro správu účtů, obchodní akce, reporting a provozní zásahy. Tajemství jsou mimo kód a logy, přístupy mají vlastníka a revizi. Privilegovaná změna může vyžadovat druhé schválení. Rate limiting se uplatní podle aktéra a rizika operace, nikoli pouze podle IP adresy.
Threat model zahrnuje cizí účet, záměnu MT4/MT5 identifikátoru, replay požadavku, zneužití interní role, únik exportu a kompromitaci adaptéru. Testy ověřují izolaci klientů, scope oprávnění, neplatné podpisy či tokeny, rotaci klíčů a chování při odpojení vendor API. Bezpečnostní kontrolu lze mapovat na OWASP ASVS a relevantní část NIST SSDF, avšak samotné použití těchto rámců není certifikace ani důkaz bezpečnosti konkrétního nasazení.
Auditní stopa a provozní pozorovatelnost
Obchodní auditní událost musí spojit identitu aktéra, účel, cílový účet, původní požadavek v bezpečné podobě, autorizaci, verzi API a adaptéru, odpověď platformy a konečný výsledek. Technický trace a obchodní audit mají odlišný účel i retenční dobu. Do logů neukládáme hesla, plné tokeny ani zbytečný osobní obsah. Události mají jednotný čas, korelační klíč a kontrolu úplnosti, aby šly při reklamaci nebo incidentu rekonstruovat přes více služeb.
Provozní dashboard odděluje zdraví API, konektivitu k MT4/MT5, hloubku front, stáří projekcí, poměr chyb podle endpointu, dobu reconciliace a stav regionálního přesměrování. Alarm má vést k odpovědné osobě a runbooku, ne jen k červenému grafu. Syntetická kontrola používá bezpečný testovací scénář, nikoli reálný obchod. Při incidentu lze dohledat, který release a konfigurační změna předcházely zhoršení.
Testovací strategie a akceptace endpointů
Každý schválený endpoint dostává kontraktový test, test oprávnění, test neplatného vstupu, chybové odpovědi a hranice velikosti nebo stránkování. Kritické zápisy navíc testují duplicitu, timeout, ztracené potvrzení a změnu stavu souběžným procesem. Adaptéry se nejprve ověřují proti simulátoru a poté proti kontrolovanému prostředí klienta; simulátor nesmí být vydáván za důkaz chování skutečného serveru. Testovací data musí pokrýt více účtů, skupin, instrumentů a obchodních režimů.
Akceptační matice obsahuje inventární ID endpointu, zdrojové API a oprávnění, očekávaný obchodní výsledek, důkaz testu a vlastníka výjimky. Součástí je end-to-end cesta založení účtu, čtení dat, obchodního požadavku, historie, reportingu a servisní korekce podle schváleného rozsahu. Provozní zkouška měří zátěž i degradaci a opakuje recovery. Teprve podpis matice umožňuje tvrdit, že byly pokryty všechny endpointy dohodnuté pro danou zakázku.
Migrace, rollout a návrat změny
MT4 a MT5 nemusí mít stejnou historii ani identifikátory. Před přepnutím vzniká mapování účtů, skupin, instrumentů a časových zón, včetně pravidel pro položky bez jednoznačného protějšku. Historická data se validují na vzorku a později kontrolními součty. Pokud část starých dat zůstává pouze v MT4, portál ji musí označit jako historický zdroj; nemá ji tiše vydávat za nový MT5 záznam.
Nasazení začíná čtením, poté vybranými zápisy na omezené skupině účtů a teprve po vyhodnocení širším provozem. Feature flags mohou oddělit region, typ účtu a endpoint, ale nesmějí obcházet autorizaci. Každá etapa má plán návratu: vypnout nový tok, zachovat auditní důkazy, ověřit stav na platformě a vyřešit rozpracované operace. Návrat aplikace sám nevrací již provedený obchod; takový zásah vyžaduje schválený obchodní postup.
Servis a rozšíření po spuštění
Po předání potřebuje broker jasné vlastnictví incidentů, změn vendor API, bezpečnostních aktualizací a kapacity. Servisní model určuje kontakt, závažnosti, reakční postup, okna změn, zálohy, obnovu a pravidelné přezkoumání oprávnění. SLO a případné SLA se sjednávají podle skutečného provozu a možností platformy. Reporty nesmějí směšovat dostupnost vlastní API vrstvy s dostupností externího MetaTrader serveru.
Nový modul se přidává přes stejnou matici schopností: účel, zdroj pravdy, datový kontrakt, oprávnění, bezpečnostní scénáře, monitorování a akceptace. Může jít o klientský portál, CRM workflow, reporting, risk alerty či další integraci, pokud jsou schválené a licenčně dostupné. Verze API chrání existující klienty; staré endpointy mají časově omezený plán ukončení. Dlouhodobá hodnota nevzniká počtem konektorů, ale schopností změnit jednu část bez ztráty kontroly nad obchodním stavem.
Mapa domén a hranice odpovědnosti
Doménový model se kreslí před tím, než vznikne první veřejný endpoint. Registrace osoby, brokerský účet, obchodní účet na konkrétním MT serveru, skupina, instrument, pokyn, deal, pozice a účetní operace nejsou synonyma. Každá entita má vlastní identifikátor, zdroj pravdy, retenční pravidlo a povolené operace. Pokud CRM eviduje osobu a MT server účet, vazba mezi nimi musí být verzovaná a auditovatelná. Automatická oprava chybně spárovaného účtu bez lidského schválení by mohla otevřít přístup k cizím prostředkům.
Vnější API překládá obchodní úlohu na bezpečnou sekvenci volání vendor rozhraní. Hranice není jen technická; rozhoduje, zda výpadek CRM může zastavit obchodování, zda reporting smí číst starší projekci a které změny vyžadují zásah brokera. Tyto závislosti se zapisují do mapy vlastníků. U každé operace je jasné, která služba ji iniciuje, která ji potvrdí, kdo řeší výjimku a kde je důkaz konečného výsledku.
Identita účtu napříč MT4 a MT5
Stejné číselné ID se může objevit na různých serverech a nemusí označovat stejného klienta. Globální identifikátor proto zahrnuje platformu, server a lokální ID; vnější systém používá vlastní stabilní referenci, která se nikdy tiše nepřemapuje. Převod mezi identitou CRM a obchodním účtem je samostatný privilegovaný proces. Změna vlastníka, sloučení klientů a migrace na jiný server potřebují historii, schválení a možnost zpětně určit, kdo měl přístup v daný okamžik.
API nesmí přijmout jen „account=12345“ a pak hledat první shodu. Autorizace porovnává konkrétního aktéra s kanonickým účtem i cílovou operací. Chyba v tomto kroku je závažnější než běžný chybový kód: může zpřístupnit historii, zůstatek nebo umožnit obchod na cizím účtu. Testovací data proto úmyslně obsahují kolidující čísla účtů na více serverech a ověřují, že platforma a tenant jsou povinnou součástí každého rozhodnutí.
Instrumenty, symboly a přesnost
Symbol zobrazený jako EURUSD nemusí mít na dvou serverech stejnou příponu, obchodní hodiny, krok objemu, velikost kontraktu ani cenovou přesnost. Vnější katalog instrumentů proto nepředstírá univerzální mapování podle textového názvu. Uchovává vendor identifikátor, server, typ aktiva, obchodní pravidla a datum jejich platnosti. Změna specifikace instrumentu se promítá do předobchodní validace; starý klientský formulář nesmí spoléhat na parametry načtené před týdnem.
Při převodu objemu a ceny se používají přesné desetinné typy a explicitní pravidla zaokrouhlení. Float v obchodní logice může vyrobit hodnotu, kterou server odmítne, nebo posunout limit. Pokud server nabídne data se zpožděním, rozhraní to uvede; poslední cena není slibem provedení. Kontrola zahrnuje nulový objem, hranice min/max, změnu obchodní seance i instrument pozastavený během otevřeného formuláře.
Předobchodní kontroly a odpověď API
Před odesláním pokynu se ověřuje identita, role, účet, stav instrumentu, typ pokynu, objem, cenové parametry a konkrétní omezení serveru. Některé kontroly jsou lokální a mohou poskytnout rychlou zpětnou vazbu. Konečné rozhodnutí o přijetí však dělá obchodní platforma podle aktuálního stavu. Vnější API proto neslibuje provedení na základě lokální validace. Odpověď rozlišuje chybu zadání, odmítnutí platformou, přijetí ke zpracování a známý konečný výsledek.
Klientský kanál má dostat stejnou sémantiku bez ohledu na MT4 či MT5, ale ne falešně stejná pole. Platformně specifické důvody zamítnutí se mapují na stabilní veřejnou kategorii a současně se zachovají v neveřejné diagnostice. Změní-li se kód chyby vendor rozhraní, kontrakt to nesmí nepozorovaně proměnit v „unknown“. Sada regresních scénářů udržuje mapu významů, ne pouze seznam HTTP statusů.
Opakované požadavky a přesně jednou
V síti nelze spolehlivě poznat, zda po ztracené odpovědi obchod vznikl. Slib „exactly once“ proto musí být převeden na konkrétní invariant: jeden ekonomický úmysl nesmí vytvořit dvě obchodní akce. Vnější vrstva uloží idempotency key a hash relevantních parametrů. Stejný klíč se stejnými parametry vrací známý stav; stejný klíč s jinou částkou či účtem se odmítne. Tento záznam přežije restart i změnu regionu.
Po timeoutu se neprovádí automatické opakování zápisu, dokud není ověřen stav na cílovém serveru. Výsledek může být pending, provedený, zamítnutý nebo skutečně neznámý. U neznámého stavu se eskaluje reconciliace a klient vidí čas posledního ověření. Administrátor nemá tlačítko „zkusit znovu“ bez vysvětlení důsledků; takový zásah může vytvořit další ekonomickou operaci.
Události, historie a částečné plnění
Historie obchodování není jen seznam pokynů. Je třeba odlišit odeslaný požadavek, serverový pokyn, deal, část plnění, konečné vypořádání a pozici. API ukazuje vazby mezi nimi, aby klient i podpora mohli vysvětlit, proč jeden pokyn vedl k více událostem. Částečné plnění, zrušení zbytku a změna pozice mají vlastní čas a původ. Historie z MT4 a MT5 se mapuje podle skutečné semantiky obou platforem.
Při synchronizaci se řeší výpadek v proudu událostí. Adaptér drží checkpoint, ověřuje kontinuitu a po opětovném spojení doplní chybějící interval. Duplicitní událost nesmí dvakrát změnit projekci. Pokud vendor API neumožňuje úplný event stream, doplňuje se pravidelné porovnání snapshotů. U každé projekce je vidět, odkud pochází a kdy byla naposledy potvrzena.
Zůstatek, marže a účetní operace
Zůstatek, equity, volná marže a případné kreditní položky se nesmí směšovat. Hodnoty mají čas, měnu, server, definici a zdroj. Převod do přehledu klienta může být informativní, ale obchodní rozhodnutí se řídí autoritativním stavem platformy. Zápis vkladu, výběru či interní korekce je vysoce citlivá operace: potřebuje víceúrovňovou autorizaci, referenci na externí finanční systém a auditní vazbu na schvalovatele.
Při nesouladu mezi finančním systémem a MT se nespouští tiché „srovnání“ jedním zápisem. Rozdíl se zařadí podle příčiny: časové zpoždění, duplicitní zpráva, ruční zásah, měnový převod nebo chyba integrace. Každá oprava potřebuje důkaz, schválení a reverzní postup. Monitoring hlídá staré nevyrovnané položky i neobvykle vysoký počet korekcí, protože obojí může ukazovat na problém v integraci nebo zneužití.
Backoffice, správa oprávnění a čtyři oči
Administrativní API může měnit skupiny, páky, přístup, obchodní režimy a další parametry s finančním dopadem. Nejde o obyčejné CRUD. Každá změna má obchodní zdůvodnění, předchozí hodnotu, novou hodnotu, schvalující osobu a plán návratu. Pro vybrané akce se oddělí autor změny od schvalovatele. Oprávnění se vztahují na konkrétní server, skupinu a typ operace; globální administrátor je výjimka, která musí být zvlášť sledovaná.
Servisní účet adaptéru nesmí mít více vendor oprávnění, než potřebuje. Při rotaci hesel a certifikátů se zkouší souběh staré a nové konfigurace, restart i rollback. Pravidelná recertifikace přístupů odhalí role, které zůstaly po změně týmu. Auditní událost obsahuje nejen „kdo klikl“, ale také rozhodnutí autorizační vrstvy a verzi politiky, podle níž byl zásah povolen.
Reporty a historická konzistence
Report klienta, interní risk report a regulatorní export mohou nad stejnými daty odpovídat na odlišné otázky. Je třeba určit, zda report ukazuje stav k určitému času, průběžný snapshot nebo finálně uzavřený obchodní den. Změna časového pásma nebo pozdě doručená serverová událost může výsledek přepočítat. Export proto obsahuje rozsah, čas vytvoření, verzi transformace a identifikaci zdroje.
U velkých historií se data stránkují a exporty vznikají asynchronně. Uživatel nemá čekat na neomezený HTTP request, který zatíží obchodní server. Přístup k exportu je časově omezený a kontroluje tenant i roli. Po vypršení se soubor bezpečně odstraní podle retenčního pravidla. Testy ověřují, že reporty z MT4 a MT5 nejsou sesypány do jedné časové řady bez označení původu.
Regionální dostupnost a umístění zápisu
Globální dostupnost neznamená aktivní obchodní zápis do více regionů téhož účtu. Každý účet má autoritativní trasu k platformnímu serveru a pravidlo, co se stane při výpadku cesty. Statické stránky, login a některé čtecí projekce lze rozmístit blíž uživatelům; zápis však musí zachovat pořadí a idempotenci. Přesměrování provozu nesmí vytvořit dvě nezávislé fronty, které obě odešlou stejný pokyn.
Pro každý region se měří síťová latence ke skutečnému MT serveru, dostupnost adaptéru, stáří projekcí a čas potřebný k obnově. V režimu degradace se může zobrazit poslední známý stav s časem, ale obchodní akce se zastaví, pokud nelze potvrdit zdroj pravdy. Failover testuje aktivní i nedokončené operace, nejen zelenou odpověď healthchecku.
Pozorovatelnost, alerty a runbooky
Jedno číslo dostupnosti API neodhalí obchodní incident. Dashboard odděluje úspěšnost čtení, zápisové odmítnutí, neznámé výsledky, lag projekcí, délku front, reconnect adaptéru a počet otevřených reconciliací. Alert se váže na dopad na zákazníka a má jasného vlastníka. Při odpojení vendor API je rozdíl mezi očekávaným servisním oknem a neočekávaným výpadkem, který vyžaduje eskalaci.
Runbook popisuje první kontrolu, bezpečnou akci, hranici automatického zásahu a kontakt na brokera či poskytovatele platformy. Pokud je neznámý výsledek zápisu, nemá provozní tým pouhým restartem vymazat důkazy. Incidentní timeline propojuje release, konfiguraci, alarm a obchodní událost. Po obnově se provede cílená reconciliace a písemné rozhodnutí o každé výjimce.
Zátěž, limity a ochrana vendor serverů
Veřejné API může obsluhovat mnoho klientů, ale vendor rozhraní bývá omezenější. Adaptér proto udržuje kvóty podle operace, serveru a priority. Kritický zápis nesmí stát za hromadou reportů; zároveň není bezpečné obejít limit neomezeným počtem paralelních připojení. Při přetížení se požadavek odmítá nebo frontuje podle kontraktu, s čitelnou informací o důsledku. Kapacitní plán vychází z měření skutečných endpointů.
Zátěžový test musí zahrnovat čtení historie, synchronizaci po výpadku, špičku po otevření trhu a současný zápis. Měří se nejen průměr, ale dlouhý ocas latence, chybovost a doba návratu do normálu. Provozní limit se zapisuje s verzí vendor serveru; upgrade může změnit charakteristiku. Test nesmí neúmyslně spouštět reálné obchody.
Verzování kontraktu a změny platformy
Změna vendor API není automaticky změnou veřejného API. Adaptér izoluje rozdíl, pokud je zachována obchodní sémantika. Když se však význam pole nebo chybového stavu změní, veřejný kontrakt potřebuje novou verzi. Migrační dokument uvádí staré a nové schéma, význam změny, chování klientů během souběhu a datum konce podpory. Není vhodné schovat breaking change do volitelného pole bez kontroly starých spotřebitelů.
Průběžné kontraktové testy běží proti přesně známé verzi adaptéru a licencovanému testovacímu prostředí, kde je to možné. Po upgrade MT serveru se ověřují kritické zápisy, historie, admin operace a reconnect, ne pouze to, že endpoint vrací HTTP 200. Release gate obsahuje kontrolu auditních událostí a rollback plán. Pokud změna mění zdroj pravdy, vyžaduje architektonické rozhodnutí.
Bezpečnostní scénáře nad běžný penetrační test
Nejrizikovější scénáře kombinují několik legitimních komponent: správně podepsaný požadavek na cizí účet, export historie po změně role, administrátorský zásah v nesprávné skupině nebo opakování starého požadavku po failoveru. Testy proto nesmí končit u SQL injection a běžného loginu. Matice oprávnění se ověřuje na každém endpointu a v každém adaptéru, včetně historických serverů a read-only reportů.
Bezpečnostní revize pracuje s konkrétním tokem dat: odkud pochází identita, kde se rozhoduje o oprávnění, co se loguje a jak se rotuje tajemství. Při kompromitaci servisního účtu musí být možné omezit přístup, určit dopad a obnovit provoz bez přepsání obchodní historie. Auditní log má být chráněn proti nepozorované úpravě; jeho retence vychází z reálných povinností brokera.
Předání, servis a zkouška obnovy
Předání obsahuje OpenAPI kontrakt, matici schopností, mapu serverů a rolí, runbooky, proces změny, testovací scénáře a vlastníky výjimek. Dokumentace musí dát novému týmu možnost odpovědět, co se stane při ztraceném potvrzení pokynu a kde zjistí skutečný stav. Bez této znalosti se servis změní v sérii ručních zásahů, které postupně zničí důvěru v data.
Zkouška obnovy obnovuje databázi projekcí, tajemství a spojení s vendor serverem v odděleném prostředí. Porovnává, zda po obnově sedí auditní korelace a zda se nerozběhnou staré zápisové úlohy. Výsledek je protokol s časem a nalezenými nedostatky, nikoli jen „backup exists“. Nové rozšíření pro další produkt přebírá stejné hranice identity, idempotence a pozorovatelnosti.
Výsledek studie a další krok
Dokončení anonymizované zakázky potvrzuje zadavatel, nikoli zde zveřejněné metriky. Pro podobnou novou implementaci by broker dodal přehled licencovaných serverů a API přístupů, role, povolené operace, cílové regiony, nároky na uchování dat a reprezentativní testovací scénáře. Společná discovery pak uzavře seznam endpointů, platformních odchylek, milníků a zkoušek. První technický pilot má ověřit nejrizikovější zápisovou cestu a jednu významnou výjimku.
Pro dalšího klienta lze sestavit etapový plán: read-only projekce, schválené zápisy, backoffice, reporty, globální odolnost a servis. Rozsah se mění podle licencí, bezpečnostních omezení a provozních dat. Právní a regulatorní použitelnost posuzují odpovědní specialisté klienta. EXCOIN zde z důvodu mlčenlivosti neuvádí identitu klienta, dosažené metriky ani garanci stejného výsledku u jiné infrastruktury.
Obecné technické podklady
Tyto odkazy vysvětlují obecné principy. Nedokládají konkrétní neveřejnou implementaci klienta.