bg

Как работи?

Нуждаете се от помощ за бизнеса?

Свържете се с нас за персонализирана оферта за FinMV, съобразена с вашите нужди.

Монолитни или микросервизни?

Техническият директор на вашата компания, когато планира стартирането на финансова платформа, ще трябва да избере опция за архитектура на проекта. Какви опции за архитектура са на разположение за него и коя е по-добре да избере?

Започнете с най-простата архитектура, която запазва границите

Новата инвестиционна платформа има един екип, едно разгръщане и една база данни. Разходът за разпределена система на този етап отива изцяло в допълнителни разходи: мрежови извиквания там, където би стигнало извикване на функция, крайна съгласуваност там, където би стигнала транзакция, и оперативно натоварване, за което няма хора.

Затова по подразбиране реализацията е модулна: onboarding, оферти, инвестиции, плащания, документи, обслужване и отчетност живеят зад ясни граници в рамките на една разгръщаема система. Модулна я прави не структурата на папките, а фактът, че всеки модул има свой договор, свои данни и свои собствени тестове.

Услуга се отделя тогава, когато за това има основание

Модулът става отделна услуга при конкретно основание, и тези основания са бизнес, а не модни:

  • мащаб — част от системата трябва да расте или да отказва независимо от останалите
  • сигурност — границата се нуждае от по-силна изолация, отколкото дава модул в рамките на един процес
  • съответствие (compliance) — регулатор или одит изискват разделяне на правомощия или данни
  • разгръщане — част се пуска с друга периодичност или от друг екип
  • интеграции — външна система налага своя профил на наличност и натоварване
  • организация — различни екипи трябва да управляват различни неща без съгласуване на всеки релийз

Тъй като границите и договорите вече съществуват, отделянето на услуга е планирана операция, а не пренаписване. В това е смисълът: възможността остава отворена и остава евтина.

Асинхронност там, където си заслужава

Работа, която не трябва да блокира потребителя — съгласуване на разплащания, генериране на документи, callback-и от доставчици, отчетност — минава през опашки. Брокери на съобщения като RabbitMQ или Kafka се появяват, когато това е оправдано от натоварването или топологията на интеграциите, а не по подразбиране. PostgreSQL остава система на записа; Redis се използва там, където наистина е нужен бърз кеш или координация.

Какво не правим

Ние не продаваме монолит и не продаваме микроуслуги. И двете са отговори на въпроси, които все още не са зададени. Също така не изграждаме разпределена система само за да изглеждаме солидни: архитектурният театър е скъп за поддръжка и труден за предаване.

Архитектурата се избира въз основа на вашия мащаб, регулаторните ви задължения, интеграциите ви и размера на екипа, който ще я експлоатира — и е проектирана така, че да може да се променя заедно с тях.