GC.Platform architecture
Technical documentation for customer architecture and engineering teams. Here you'll find which technology stack GC.Platform runs on, how it's laid out, how it integrates and how it scales.
Architecture in one picture
GC.Platform is a microservices, multi-cloud architecture, hosted entirely in the European Union. Each module runs as an independent service, with its own deployment cycle and scaling profile. The full picture of the main components:
The diagram shows the main components handling the flow from end user to product data. Module backends (GC.Catalog, GC.Platform API, ERP, CART, AUTH, DASHBOARD, Messaging, AI.Assistant) operate independently, communicating through APIs and events. Each has its own App Service plan, so it scales individually.
We host in three EU regions, on two clouds
GC.Platform runs in a multi-cloud model with three cloud regions in the European Union: Microsoft Azure in Poland, Microsoft Azure in Germany and Oracle Cloud in Germany. Each system layer sits in the cloud it works best in: transactional data and applications on Azure, product data (the MDM layer) on Oracle Cloud.
Traffic from your platform's customers is handled by Cloudflare — the edge layer that protects against DDoS attacks, filters traffic in the WAF, and accelerates static content globally. Below Cloudflare runs Azure Front Door — Microsoft's multi-region load balancer, which routes traffic to the nearest available application instance and automatically reroutes it when any component becomes unavailable.
Every GC.Platform microservice runs on at least two application instances in Azure App Service, on a dedicated plan. Transactional data in Azure SQL runs in Zone Availability mode — resilient to single availability zone failures. This is a standard approach for enterprise architecture, but often skipped in e-commerce platforms that market themselves as “cloud-based”.
What's under the hood
We pick technologies deliberately — for the specific task, not for fashion. The GC.Platform stack combines mature, proven solutions with modern tools where they bring a real advantage.
Backend
- •.NET (current LTS versions) — backend services (GC.Platform API, ERP, CART, AUTH, DASHBOARD, Messaging, AI.Assistant)
- •PHP — server-side rendering for GC.Catalog, optimised for SEO and first-render time of catalogues with large SKU bases
- •Azure App Service — application runtime for all backends
Frontend
- •GC.Catalog — native JavaScript ES6+ without a framework, SCSS for styles, Vite as a bundler. A deliberate decision: for automotive catalogues, a light interactivity layer on the browser side delivers better SEO and performance than a heavy SPA framework
- •GC.Dashboard — React, for the advanced administrative interface
- •AI.Assistant — React, a chat component embedded in GC.Catalog
Data
- •Azure SQL Pool — transactional data for GC.CART, GC.Messaging, GC.AUTH (each module with a separate SQL instance)
- •Oracle Cloud — the GC.MDM (Master Data Management) layer, where the structure and performance of product queries are critical
- •Azure Cognitive Search — search across the product catalogue, indexing and facets
- •Azure Cache for Redis — cache layer for frequently queried data
Inter-service communication
- •Azure Service Bus — queues and topics for business events (orders, state changes, integrations)
- •Azure Storage Queues — queues for background tasks and asynchronous processing
Edge infrastructure
- •Cloudflare — WAF, anti-DDoS protection, CDN acceleration
- •Azure Front Door — multi-region load balancing
Security and identity
- •Microsoft Entra ID — identity management for the team maintaining the platform, MFA enforced
- •Azure Key Vault — secrets, cryptographic keys, certificates
- •Azure Log Analytics, Application Insights — logs, monitoring, audit
Every module independent
GC.Platform is not a monolith. Every module — GC.CATALOG, GC.CART, GC.AUTH, GC.MDM, GC.CMS, GC.DASHBOARD, AI.Assistant — is a separate backend service, on its own App Service plan, with its own instances and its own responsibility. Communication between modules happens via REST APIs and via events on Azure Service Bus.
Practical consequence: when traffic on the catalogue grows during the tyre change season, we scale GC.CATALOG. When the number of orders grows, we scale GC.CART. When AI.Assistant handles more conversations, we scale that specific service. No shutdowns, no interruptions, no domino effects on other parts of the platform.
Every module has its own CI/CD pipeline in Azure DevOps and can be deployed independently of the others. That means updating one element doesn't require redeploying the whole platform.
Open API for ERP integration
GC.Platform exposes APIs in a REST architecture. All backend services (GC.Platform API, ERP API, CART API, AUTH API, DASHBOARD API, Messaging API, AI.Assistant) communicate over the same standard — this simplifies work for the customer's integration teams.
Integration API — the interface dedicated to integration with the customer's ERP systems — has public documentation. The standard integration scope covers exchanging prices, stock availability, orders, invoices, and shipping routes between GC.Platform and the customer's ERP. The detailed scope is agreed in the implementation analysis phase, tailored to the specifics of the customer's ERP.
Other interfaces — internal between GC.Platform modules, frontend between client applications and the backend, integration with industry partners — are documented in the implementation phase and made available to your team as part of integration work.
System lifecycle after deployment
Every GC.Platform deployment includes at least two environments: production and staging. The staging environment serves for integration testing, verifying updates, and trying out configuration changes before they go to production.
We deploy GC.Platform updates asynchronously — meaning there is no rigid “maintenance window” you have to watch out for. Each module is updated independently, without interrupting the other components. In necessary cases — e.g. a large structural change or an update requiring data migration — we schedule a maintenance window in advance, in agreement with your team.
Production deployment is carried out by our team, through the CI/CD pipeline in Azure DevOps. Every deployment has automatic rollback capability — if a problem arises after a deployment, we can quickly revert the system to the previous, working version. No manual reconfiguration, no risk of human error in a stressful situation.
Security at the Enterprise cloud level
All communication — between the client and the platform and inside GC.Platform — runs over TLS 1.2 or higher. Data in Azure SQL databases is encrypted by Transparent Data Encryption (TDE), keys are stored in Azure Key Vault. The team maintaining the platform signs in through Microsoft Entra ID with multi-factor authentication, every production operation is logged and auditable. The infrastructure GC.Platform runs on is certified to ISO 27001, SOC 1, SOC 2 and SOC 3.
The full security, data protection and GDPR policy is described on the page Data and security.
Back to GC.Platform
You'll find the description of modules, use case scenarios and the complete platform picture on the GC.Platform page.