GC.Platform-Architektur
Technische Dokumentation für die Architektur- und Entwicklerteams unserer Kunden. Hier finden Sie, auf welchem Technologie-Stack GC.Platform läuft, wie sie aufgebaut ist, wie sie integriert wird und wie sie skaliert.
Die Architektur in einem Bild
GC.Platform ist eine Mikroservice-Architektur, multi-cloud, vollständig in der Europäischen Union gehostet. Jedes Modul läuft als unabhängiger Dienst mit eigenem Bereitstellungs- und Skalierungszyklus. Der vollständige Überblick der wichtigsten Komponenten:
Das Diagramm zeigt die wichtigsten Komponenten, die den Datenfluss vom Endnutzer bis zu den Produktdaten verarbeiten. Die Modul-Backends (GC.Catalog, GC.Platform API, ERP, CART, AUTH, DASHBOARD, Messaging, AI.Assistant) arbeiten unabhängig und kommunizieren über APIs und Events. Jedes hat einen eigenen App-Service-Plan, sodass es individuell skaliert.
Wir hosten in drei EU-Regionen, in zwei Clouds
GC.Platform läuft im Multi-Cloud-Modell mit drei Cloud-Regionen in der Europäischen Union: Microsoft Azure in Polen, Microsoft Azure in Deutschland und Oracle Cloud in Deutschland. Jede Systemschicht liegt in der Cloud, in der sie am besten funktioniert: Transaktionsdaten und Anwendungen in Azure, Produktdaten (MDM-Schicht) in Oracle Cloud.
Den Datenverkehr Ihrer Plattform-Kunden verarbeitet Cloudflare — die Edge-Schicht, die vor DDoS-Angriffen schützt, den Verkehr in der WAF filtert und statische Inhalte weltweit beschleunigt. Unterhalb von Cloudflare arbeitet Azure Front Door — der Multi-Region-Load-Balancer von Microsoft, der den Verkehr zur nächstgelegenen verfügbaren Anwendungsinstanz leitet und ihn bei Ausfall einer beliebigen Komponente automatisch umleitet.
Jeder Mikroservice von GC.Platform läuft auf mindestens zwei Anwendungsinstanzen in Azure App Service, auf einem eigenen Plan. Transaktionsdaten in Azure SQL laufen im Zone-Availability-Modus — widerstandsfähig gegen Ausfälle einer einzelnen Verfügbarkeitszone. Das ist ein Standardansatz für Enterprise-Architekturen, aber oft übergangen in E-Commerce-Plattformen, die mit „cloudbasiert” werben.
Was unter der Haube steckt
Wir wählen Technologien bewusst — für die konkrete Aufgabe, nicht nach Mode. Der GC.Platform-Stack kombiniert ausgereifte, bewährte Lösungen mit modernen Werkzeugen dort, wo sie einen echten Vorteil bringen.
Backend
- •.NET (aktuelle LTS-Versionen) — Backend-Dienste (GC.Platform API, ERP, CART, AUTH, DASHBOARD, Messaging, AI.Assistant)
- •PHP — Server-side Rendering für GC.Catalog, optimiert für SEO und First-Render-Zeit großer SKU-Kataloge
- •Azure App Service — Anwendungs-Runtime für alle Backends
Frontend
- •GC.Catalog — natives JavaScript ES6+ ohne Framework, SCSS für Stile, Vite als Bundler. Bewusste Entscheidung: Für Automotive-Kataloge liefert eine leichte Interaktivitätsschicht im Browser bessere SEO- und Performance-Ergebnisse als ein schweres SPA-Framework
- •GC.Dashboard — React, für die fortgeschrittene administrative Oberfläche
- •AI.Assistant — React, eingebettete Chat-Komponente in GC.Catalog
Daten
- •Azure SQL Pool — Transaktionsdaten für GC.CART, GC.Messaging, GC.AUTH (jedes Modul mit eigener SQL-Instanz)
- •Oracle Cloud — GC.MDM-Schicht (Master Data Management), wo Struktur und Performance der Produktabfragen entscheidend sind
- •Azure Cognitive Search — Suche über den Produktkatalog, Indexierung und Facetten
- •Azure Cache for Redis — Cache-Schicht für häufig abgefragte Daten
Kommunikation zwischen Diensten
- •Azure Service Bus — Queues und Topics für Geschäftsereignisse (Bestellungen, Statusänderungen, Integrationen)
- •Azure Storage Queues — Queues für Hintergrundaufgaben und asynchrone Verarbeitung
Edge-Infrastruktur
- •Cloudflare — WAF, DDoS-Schutz, CDN-Beschleunigung
- •Azure Front Door — Multi-Region-Load-Balancing
Sicherheit und Identität
- •Microsoft Entra ID — Identitätsverwaltung für das Team, das die Plattform betreibt, MFA erzwungen
- •Azure Key Vault — Geheimnisse, kryptografische Schlüssel, Zertifikate
- •Azure Log Analytics, Application Insights — Logs, Monitoring, Audit
Jedes Modul unabhängig
GC.Platform ist kein Monolith. Jedes Modul — GC.CATALOG, GC.CART, GC.AUTH, GC.MDM, GC.CMS, GC.DASHBOARD, AI.Assistant — ist ein eigener Backend-Dienst auf einem eigenen App-Service-Plan, mit eigenen Instanzen und eigener Verantwortung. Die Kommunikation zwischen Modulen läuft über REST-APIs und über Events auf Azure Service Bus.
Praktische Konsequenz: Wenn der Traffic auf dem Katalog in der Reifenwechsel-Saison steigt, skalieren wir GC.CATALOG. Wenn die Anzahl der Bestellungen steigt, skalieren wir GC.CART. Wenn AI.Assistant mehr Gespräche bearbeitet, skalieren wir genau diesen Dienst. Keine Abschaltungen, keine Unterbrechungen, kein Dominoeffekt auf andere Teile der Plattform.
Jedes Modul hat eine eigene CI/CD-Pipeline in Azure DevOps und kann unabhängig von den anderen bereitgestellt werden. Das bedeutet, dass die Aktualisierung eines Elements kein erneutes Deployment der gesamten Plattform erfordert.
Offene API für ERP-Integration
GC.Platform stellt APIs in einer REST-Architektur bereit. Alle Backend-Dienste (GC.Platform API, ERP API, CART API, AUTH API, DASHBOARD API, Messaging API, AI.Assistant) kommunizieren über denselben Standard — das vereinfacht die Arbeit der Integrationsteams auf Kundenseite.
Integration API — die Schnittstelle, die der Integration mit den ERP-Systemen des Kunden gewidmet ist — hat eine öffentliche Dokumentation. Der Standardumfang der Integration umfasst den Austausch von Preisen, Lagerverfügbarkeit, Bestellungen, Rechnungen und Versandwegen zwischen GC.Platform und dem ERP des Kunden. Der genaue Umfang wird in der Analysephase der Implementierung festgelegt und an die Besonderheiten des ERPs auf Kundenseite angepasst.
Weitere Schnittstellen — interne zwischen GC.Platform-Modulen, Frontend zwischen Client-Anwendungen und Backend, Integrationen mit Branchenpartnern — dokumentieren wir in der Implementierungsphase und stellen sie Ihrem Team im Rahmen der Integrationsarbeiten zur Verfügung.
Systemlebenszyklus nach dem Deployment
Jedes GC.Platform-Deployment umfasst mindestens zwei Umgebungen: Produktion und Staging. Die Staging-Umgebung dient für Integrationstests, die Überprüfung von Updates und das Erproben von Konfigurationsänderungen, bevor sie in die Produktion gehen.
Wir deployen GC.Platform-Updates asynchron — das heißt, es gibt kein starres „Wartungsfenster”, auf das Sie achten müssen. Jedes Modul wird unabhängig aktualisiert, ohne den Betrieb der anderen Komponenten zu unterbrechen. In notwendigen Fällen — z. B. bei einer großen strukturellen Änderung oder einem Update, das eine Datenmigration erfordert — vereinbaren wir ein Wartungsfenster im Voraus, in Absprache mit Ihrem Team.
Das Produktions-Deployment führt unser Team durch, über die CI/CD-Pipeline in Azure DevOps. Jedes Deployment verfügt über eine automatische Rollback-Möglichkeit — bei einem Problem nach dem Deployment können wir das System schnell auf die vorherige, funktionierende Version zurücksetzen. Ohne manuelle Rekonfiguration, ohne Risiko menschlicher Fehler in einer Stresssituation.
Sicherheit auf Enterprise-Cloud-Niveau
Die gesamte Kommunikation — zwischen Client und Plattform sowie innerhalb von GC.Platform — erfolgt über TLS 1.2 oder höher. Daten in Azure-SQL-Datenbanken sind durch Transparent Data Encryption (TDE) verschlüsselt, Schlüssel speichern wir in Azure Key Vault. Das Team, das die Plattform betreibt, meldet sich über Microsoft Entra ID mit Multi-Faktor-Authentifizierung an, jede Produktionsoperation wird protokolliert und ist auditierbar. Die Infrastruktur, auf der GC.Platform läuft, ist nach ISO 27001, SOC 1, SOC 2 und SOC 3 zertifiziert.
Die vollständige Sicherheits-, Datenschutz- und DSGVO-Richtlinie beschreibt die Seite Daten und Sicherheit.
Zurück zu GC.Platform
Die Beschreibung der Module, Anwendungsszenarien und das vollständige Bild der Plattform finden Sie auf der GC.Platform-Seite.