no

Hvordan det fungerer?

Trenger du hjelp til bedriften?

Kontakt oss for et personlig FinMV-tilbud skreddersydd til dine behov.

Monolitisk eller mikroservice?

Den tekniske direktøren for bedriften din, når den planlegger lanseringen av en finansiell plattform, må velge et alternativ for prosjektarkitektur. Hvilke arkitekturalternativer er tilgjengelige for ham, og hvilken er bedre å velge?

Begynn med den enkleste arkitekturen som holder grensene tydelige

En ny investeringsplattform har ett team, én utrulling og én database. På dette stadiet går kostnaden ved et distribuert system utelukkende til overhead: nettverkskall der et funksjonskall ville holdt, endelig konsistens der en transaksjon ville holdt, og en driftsbelastning ingen har bemanning til.

Derfor er standardimplementeringen modulær: onboarding, tilbud, investeringer, betalinger, dokumenter, service og rapportering lever bak eksplisitte grenser i ett distribuerbart system. Det som gjør den modulær, er ikke mappestrukturen, men at hver modul har en kontrakt, eier sine egne data og dekkes av sine egne tester.

En tjeneste skilles ut når det finnes en grunn

En modul blir en egen tjeneste når det finnes et konkret grunnlag, og disse grunnlagene er forretningsmessige, ikke motepregede:

  • skala — en del av systemet må kunne vokse eller feile uavhengig av resten
  • sikkerhet — grensen trenger sterkere isolasjon enn det en modul i én enkelt prosess gir
  • compliance — en tilsynsmyndighet eller revisjon krever oppdeling av ansvar eller data
  • utrulling — en del må lanseres med et annet intervall eller av et annet team
  • integrasjoner — et eksternt system dikterer sin egen tilgjengelighets- og gjennomstrømningsprofil
  • organisasjon — forskjellige team må eie forskjellige ting uten å koordinere hver eneste utgivelse

Fordi grensene og kontraktene allerede finnes, er utskillelse av en tjeneste en planlagt operasjon, ikke en omskriving. Det er hele poenget: muligheten forblir åpen og forblir billig.

Asynkront der det lønner seg

Arbeid som ikke skal blokkere en bruker — avstemming av oppgjør, dokumentgenerering, tilbakekall fra leverandører, rapportering — går gjennom køer. Meldingsmeglere som RabbitMQ eller Kafka dukker opp når gjennomstrømning eller integrasjonstopologi rettferdiggjør det, ikke som standard. PostgreSQL forblir systemet for registrering; Redis brukes der rask caching eller koordinering er reelt nødvendig.

Hva vi ikke gjør

Vi selger ikke en monolitt, og vi selger ikke mikrotjenester. Begge er svar på spørsmål ingen har stilt ennå. Vi bygger heller ikke et distribuert system bare for å få en plattform til å se solid ut — arkitekturteater er dyrt å drifte og vanskelig å overlevere.

Arkitekturen velges ut fra din skala, dine regulatoriske forpliktelser, dine integrasjoner og størrelsen på teamet som skal drifte den — og den er utformet slik at den kan endres når disse endrer seg.