fi

Kuinka se toimii?

Tarvitsetko apua yrityksille?

Ota yhteyttä ja pyydä tarpeisiisi räätälöity FinMV-tarjous.

Monoliittinen vai mikropalvelu?

Yrityksesi teknisen johtajan on valittava projektiarkkitehtuurivaihtoehto suunnitellessaan rahoitusalustan lanseerausta. Mitä arkkitehtuurivaihtoehtoja hänellä on tarjolla ja mikä on parempi valita?

Aloita yksinkertaisimmasta arkkitehtuurista, joka pitää rajat selkeinä

Uudella sijoitusalustalla on yksi tiimi, yksi käyttöönotto ja yksi tietokanta. Hajautetun järjestelmän kustannukset maksetaan tässä vaiheessa kokonaan yleiskuluina: verkkokutsuja siellä, missä funktiokutsu riittäisi, lopullista johdonmukaisuutta siellä, missä transaktio riittäisi, ja operatiivista kuormaa, jolle kenelläkään ei ole henkilöstöä.

Siksi toteutus on oletusarvoisesti modulaarinen: käyttöönotto, tarjoukset, sijoitukset, maksut, asiakirjat, palvelu ja raportointi elävät selkeiden rajojen takana yhden käyttöönotettavan järjestelmän sisällä. Modulaarisuuden tekee siitä ei kansiorakenne, vaan se, että jokaisella moduulilla on sopimus, omat tiedot ja omat testit.

Palvelu erotetaan silloin, kun siihen on syy

Moduulista tulee erillinen palvelu, kun siihen on konkreettinen syy, ja nämä syyt ovat liiketoiminnallisia, eivät muotiin liittyviä:

  • skaala — järjestelmän osan on kasvettava tai kaaduttava itsenäisesti muista riippumatta
  • turvallisuus — raja tarvitsee vahvemman eristyksen kuin yhden prosessin sisäinen moduuli tarjoaa
  • vaatimustenmukaisuus — sääntelyviranomainen tai auditointi vaatii tehtävien tai tietojen erottamista
  • käyttöönotto — osa on julkaistava eri tahdissa tai eri tiimin toimesta
  • integraatiot — ulkoinen järjestelmä sanelee oman saatavuus- ja kuormaprofiilinsa
  • organisaatio — eri tiimien on omistettava eri asioita ilman jokaisen julkaisun koordinointia

Koska rajat ja sopimukset ovat jo olemassa, palvelun erottaminen on suunniteltu toimenpide, ei uudelleenkirjoitus. Siinä on koko ajatus: vaihtoehto pysyy avoimena ja edullisena.

Asynkronisuutta siellä, missä se on perusteltua

Työ, jonka ei tarvitse estää käyttäjää — tilitysten täsmäytys, asiakirjojen luonti, palveluntarjoajien takaisinkutsut, raportointi — kulkee jonojen kautta. Viestivälittäjät kuten RabbitMQ tai Kafka tulevat mukaan kuvaan, kun kuormitus tai integraatioiden topologia sen perustelee, ei oletuksena. PostgreSQL pysyy tietuejärjestelmänä; Redistä käytetään siellä, missä nopeaa välimuistia tai koordinointia todella tarvitaan.

Mitä emme tee

Emme myy monoliittia emmekä myy mikropalveluita. Molemmat ovat vastauksia kysymyksiin, joita kukaan ei ole vielä esittänyt. Emme myöskään rakenna hajautettua järjestelmää saadaksemme alustan näyttämään vakuuttavalta — arkkitehtuuriteatteri on kallis ylläpitää ja vaikea siirtää eteenpäin.

Arkkitehtuurisi valitaan skaalasi, sääntelyvelvoitteidesi, integraatioidesi ja sitä ylläpitävän tiimin koon perusteella — ja se on suunniteltu niin, että se voi muuttua niiden mukana.