Architektura - amuradon/trader-journey GitHub Wiki

Kontext

Budu používat několik různých způsobů, jak vydělávat v Crypto - new listing, delisting, Dual Investment, arbitráž, market making, grid, CEX/DEX liquidity mining, pump, memecoin sniper, economic news atd, futures, options, TradingView alerts, futures signals atd. Není možné tohle vše provozovat v jednom systému, protože by to špatně škálovalo. Jednotliví agenti se budou vypínat a zapínat, poběží pro různé tokeny a burzy s různým objemem, takže budou muset různě škálovat. Navíc někteří agenti (new listing, pump) jsou krátkodobé one-time akce.

Požadavky

Rozhodnutí

V podstatě se jedná o master-slave architekturu, kde není pevný počet agentů (slaves), ale vytvářejí se a ničí podle požadavků a je možné vytvářet různě výkonné agenty podle požadavků. Sám jsem si to myslel a ChatGPT mi to potvrdil, použiji Kubernetes a jeho pods a jobs (pro krátkodobé boty), instruované z Javy pomocí Java klient. Kubernetes bude sloužit jako control plane k orchestrování agentů. Agenti samotní jsou data plane a master node s front-endem a back-endem je management plane.

Co se týče konektorů, přemýšlel jsem je deploynout samostatně jako microservice, přes kterou by agenti komunikovalo za použití jednotného interface a konektor by to překládal. Na jednu stranu by to mohlo ušetřit datový průtok, protože pro společné burzy a tokeny by se konzumoval jen jednou, ale na druhou stranu by to zbytečně přidávalo další zpoždění v komunikaci a mohlo způsobovat problémy ve škálování, tudíž minimálně ze začátku konektor bude pouze samostatná sdílená knihovna přímo v agentu. Mohu později dojít k potřebě vytvořit samostatný konektor microservice.

IMG_20250411_094704m

Vzhledem k tomu, že se prakticky jedná pouze o 2 engines minimálně zpočátku umístím vše do jednoho repository. Pokud později bude třeba mohu to rozsekat.