Kontaktujte nás pro personalizovanou nabídku FinMV přizpůsobenou vašim potřebám.
Technický ředitel vaší společnosti bude muset při plánování spuštění finanční platformy zvolit variantu architektury projektu. Jaké možnosti architektury má k dispozici a kterou je lepší zvolit?
Nová investiční platforma má jeden tým, jedno nasazení a jednu databázi. Náklady na distribuovaný systém v této fázi jdou zcela do režijních nákladů: síťová volání tam, kde by stačilo volání funkce, konečná konzistence tam, kde by stačila transakce, a provozní zátěž, na kterou nejsou lidé.
Proto je výchozí implementace modulární: onboarding, nabídky, investice, platby, dokumenty, servis a reporting žijí za explicitními hranicemi v rámci jednoho nasaditelného systému. Modulární ji nedělá struktura složek, ale to, že každý modul má kontrakt, vlastní data a vlastní testy.
Modul se stává samostatnou službou z konkrétního důvodu, a tyto důvody jsou obchodní, ne módní:
Protože hranice a kontrakty už existují, vyčlenění služby je plánovaná operace, ne přepis. V tom je smysl: možnost zůstává otevřená a zůstává levná.
Práce, která nesmí blokovat uživatele — odsouhlasení plateb, generování dokumentů, callbacky poskytovatelů, reporting — probíhá přes fronty. Zprostředkovatelé zpráv jako RabbitMQ nebo Kafka se objevují tehdy, kdy to opodstatňuje zátěž nebo topologie integrací, ne jako výchozí volba. PostgreSQL zůstává systémem záznamu; Redis se používá tam, kde je skutečně potřeba rychlá vyrovnávací paměť nebo koordinace.
Neprodáváme monolit a neprodáváme mikroslužby. Obojí jsou odpovědi na otázky, které ještě nikdo nepoložil. Také nebudujeme distribuovaný systém kvůli solidnímu vzhledu: architektonické divadlo je drahé na provoz a obtížné na předání.
Architektura se volí podle vaší škály, regulatorních povinností, integrací a velikosti týmu, který ji bude provozovat — a je navržena tak, aby se mohla měnit spolu s nimi.
