GC.Platform-arkitektur
Teknisk dokumentasjon for kundens arkitektur- og utviklerteam. Her finner du hvilken teknologistabel GC.Platform kjører på, hvordan den er bygget opp, hvordan den integreres og hvordan den skalerer.
Arkitekturen i ett bilde
GC.Platform er en mikrotjenestearkitektur, multi-sky, hostet i sin helhet i Den europeiske union. Hver modul kjører som en uavhengig tjeneste, med egen distribusjons- og skaleringssyklus. Det fullstendige bildet av hovedkomponentene:
Diagrammet viser hovedkomponentene som håndterer flyten fra sluttbrukeren til produktdataene. Modul-backendene (GC.Catalog, GC.Platform API, ERP, CART, AUTH, DASHBOARD, Messaging, AI.Assistant) opererer uavhengig og kommuniserer via API og hendelser. Hver har sin egen App Service-plan og skalerer individuelt.
Vi hoster i tre EU-regioner, på to skyer
GC.Platform kjører i en multi-sky-modell med tre skyregioner i Den europeiske union: Microsoft Azure i Polen, Microsoft Azure i Tyskland og Oracle Cloud i Tyskland. Hvert systemlag ligger i den skyen der det fungerer best: transaksjonsdata og applikasjoner i Azure, produktdata (MDM-laget) i Oracle Cloud.
Trafikken fra plattformens kunder håndteres av Cloudflare — kantlaget som beskytter mot DDoS-angrep, filtrerer trafikk i WAF-en og akselererer statisk innhold globalt. Under Cloudflare kjører Azure Front Door — Microsofts multi-regions load balancer, som dirigerer trafikken til nærmeste tilgjengelige applikasjonsinstans og automatisk ruter den om hvis en komponent skulle bli utilgjengelig.
Hver mikrotjeneste i GC.Platform kjører på minst to applikasjonsinstanser i Azure App Service, på en egen plan. Transaksjonsdata i Azure SQL kjører i Zone Availability-modus — motstandsdyktig mot feil i én enkelt tilgjengelighetssone. Dette er en standardtilnærming for enterprise-arkitektur, men ofte oversett av e-handelsplattformer som markedsfører seg som «skybaserte».
Hva som er under panseret
Vi velger teknologier bevisst — for den konkrete oppgaven, ikke etter mote. GC.Platform-stabelen kombinerer modne, utprøvde løsninger med moderne verktøy der de gir en reell fordel.
Backend
- •.NET (gjeldende LTS-versjoner) — backend-tjenester (GC.Platform API, ERP, CART, AUTH, DASHBOARD, Messaging, AI.Assistant)
- •PHP — server-side rendering for GC.Catalog, optimalisert for SEO og første rendertid for kataloger med store SKU-baser
- •Azure App Service — applikasjonsruntime for alle backender
Frontend
- •GC.Catalog — native JavaScript ES6+ uten rammeverk, SCSS for stiler, Vite som bundler. En bevisst beslutning: for bilkataloger gir et lett interaktivitetslag på klientsiden bedre SEO- og ytelsesresultater enn et tungt SPA-rammeverk
- •GC.Dashboard — React, for det avanserte administrasjonsgrensesnittet
- •AI.Assistant — React, en chat-komponent innebygd i GC.Catalog
Data
- •Azure SQL Pool — transaksjonsdata for GC.CART, GC.Messaging, GC.AUTH (hver modul med en separat SQL-instans)
- •Oracle Cloud — GC.MDM-laget (Master Data Management), der struktur og ytelse for produktsøk er avgjørende
- •Azure Cognitive Search — søk på tvers av produktkatalogen, indeksering og fasetter
- •Azure Cache for Redis — cachelag for ofte forespurte data
Kommunikasjon mellom tjenester
- •Azure Service Bus — køer og topics for forretningshendelser (bestillinger, tilstandsendringer, integrasjoner)
- •Azure Storage Queues — køer for bakgrunnsoppgaver og asynkron behandling
Kant-infrastruktur
- •Cloudflare — WAF, anti-DDoS-beskyttelse, CDN-akselerasjon
- •Azure Front Door — multi-regions load balancing
Sikkerhet og identitet
- •Microsoft Entra ID — identitetshåndtering for teamet som vedlikeholder plattformen, MFA påtvunget
- •Azure Key Vault — hemmeligheter, kryptografiske nøkler, sertifikater
- •Azure Log Analytics, Application Insights — logger, overvåking, revisjon
Hver modul uavhengig
GC.Platform er ikke en monolitt. Hver modul — GC.CATALOG, GC.CART, GC.AUTH, GC.MDM, GC.CMS, GC.DASHBOARD, AI.Assistant — er en separat backend-tjeneste, på sin egen App Service-plan, med sine egne instanser og sitt eget ansvar. Kommunikasjonen mellom modulene foregår via REST-API og via hendelser på Azure Service Bus.
Praktisk konsekvens: når trafikken på katalogen vokser i dekksesongen, skalerer vi GC.CATALOG. Når antallet bestillinger vokser, skalerer vi GC.CART. Når AI.Assistant håndterer flere samtaler, skalerer vi akkurat den tjenesten. Ingen nedstengninger, ingen avbrudd, ingen domino-effekter i andre deler av plattformen.
Hver modul har sin egen CI/CD-pipeline i Azure DevOps og kan distribueres uavhengig av de andre. Det betyr at oppdatering av ett element ikke krever ny distribusjon av hele plattformen.
Åpent API for ERP-integrasjon
GC.Platform eksponerer API-er i en REST-arkitektur. Alle backend-tjenester (GC.Platform API, ERP API, CART API, AUTH API, DASHBOARD API, Messaging API, AI.Assistant) kommuniserer med samme standard — dette forenkler arbeidet for integrasjonsteamene hos kunden.
Integration API — grensesnittet dedikert til integrasjon med kundens ERP-systemer — har offentlig dokumentasjon. Standard omfang for integrasjonen dekker utveksling av priser, vareantall, bestillinger, fakturaer og transportruter mellom GC.Platform og kundens ERP. Det detaljerte omfanget fastsettes i analysefasen av implementeringen, tilpasset særpregene ved kundens ERP.
Andre grensesnitt — interne mellom GC.Platform-modulene, frontend mellom klientapplikasjoner og backend, integrasjonsgrensesnitt mot bransjepartnere — dokumenteres i implementeringsfasen og gjøres tilgjengelige for teamet ditt som del av integrasjonsarbeidet.
Systemets livssyklus etter implementering
Hver GC.Platform-implementering omfatter minst to miljøer: produksjon og staging. Staging-miljøet brukes til integrasjonstester, verifisering av oppdateringer og uttesting av konfigurasjonsendringer før de utrulles i produksjon.
Vi ruller ut GC.Platform-oppdateringer asynkront — det betyr at det ikke finnes et stivt «vedlikeholdsvindu» du må passe på. Hver modul oppdateres uavhengig, uten avbrudd i de øvrige komponentene. I nødvendige tilfeller — f.eks. en stor strukturell endring eller en oppdatering som krever datamigrasjon — avtaler vi et vedlikeholdsvindu på forhånd, i samråd med teamet ditt.
Produksjonsdistribusjon utføres av teamet vårt, via CI/CD-pipeline i Azure DevOps. Hver distribusjon har automatisk rollback-mulighet — i tilfelle problemer etter en utrulling kan vi raskt rulle systemet tilbake til den forrige, fungerende versjonen. Ingen manuell rekonfigurasjon, ingen risiko for menneskelige feil i stressende situasjoner.
Sikkerhet på Enterprise-skynivå
All kommunikasjon — mellom klient og plattform og inne i GC.Platform — skjer via TLS 1.2 eller høyere. Data i Azure SQL-databaser er kryptert via Transparent Data Encryption (TDE), nøkler oppbevares i Azure Key Vault. Teamet som vedlikeholder plattformen, logger inn via Microsoft Entra ID med flerfaktorautentisering, alle operasjoner i produksjon logges og er reviderbare. Infrastrukturen GC.Platform kjører på er sertifisert i henhold til ISO 27001, SOC 1, SOC 2 og SOC 3.
Den fullstendige sikkerhets-, personvern- og GDPR-policyen er beskrevet på siden Data og sikkerhet.
Tilbake til GC.Platform
Beskrivelsen av modulene, brukstilfeller og det fullstendige bildet av plattformen finner du på GC.Platform-siden.