Als unser Kunde an uns herantrat, war das Problem im Grunde schnell identifiziert: Monatlich inszenierte Produkt-Releases, sogenannte „Drops“.
Im Normalbetrieb lief der Shop völlig unaufgeregt. Doch sobald das Marketing-Team den Startschuss für eine limitierte Kollektion gab, brach innerhalb von Sekunden ein massiver Ansturm über die Server herein. Zehntausende gleichzeitige Zugriffe, hysterisches Neuladen der Produktseiten, glühende Warenkorb-APIs.
Vor unserem Eingriff stand der Kunde vor einer klassischen Sackgasse:
- Reine Private-Cloud-Überdimensionierung: Hätten wir das bestehende Setup auf dem eigenen Blech so weit vergrößert, dass es diese extremen Lastspitzen nativ schluckt, hätte der Kunde für eine 16-spurige Autobahn bezahlt, die 29 Tage im Monat komplett leer steht. Ein finanzielles Desaster.
- Der blinde Reflex Richtung Public Cloud: Den gesamten Stack, inklusive ERP, CRM, Warenwirtschaft und sensibler Kundendatenbank, komplett zu einem US-Hyperscaler umzuziehen, war für uns und den Kunden keine Option. Persistente, datenbanklastige Systeme dort 24/7 zu betreiben, treibt die Fixkosten massiv in die Höhe. Zudem sollen sensible Kundendaten und der Transaktionskern sicher im kontrollierten, deutschen Rechtsraum bleiben.
Unsere Aufgabe war es, diesen Zwiespalt aufzulösen. Wir wollten eine Architektur bauen, die den Checkout unter Volllast absolut stabil hält, dem Kunden aber nur dann Kosten verursacht, wenn es tatsächlich nötig ist.
Unser Ansatz: Klare Trennung von Zustand und Durchsatz
Technik ist immer ein Werkzeug, kein Selbstzweck. Bevor wir die Konfiguration angefasst haben, wurde die Systemlandschaft des Kunden analytisch zerlegt. Die zentrale Frage war: Welche Komponenten müssen geschützt und permanent stabil laufen und welche müssen elastisch geplant werden?
- ERP-System, Lagerbestände, Kundenstammdaten und die Hauptdatenbanken. Diese Systeme brauchen berechenbare I/O-Performance, absolute Datensicherheit und minimale Latenzen untereinander. Keine Experimente.
- Webserver, Frontend-Container, Caching-Layer und Routing-Instanzen. Sie nehmen den ersten Treffer des Traffics ab, validieren Anfragen und leiten nur das Nötigste an das Backend weiter. Sie speichern selbst keine persistenten Daten.
So haben wir das System gebaut
Wir haben eine hybride Architektur implementiert, die über automatisierte Bereitstellungsprozesse gesteuert wird und im Ernstfall innerhalb von Minuten einsatzbereit ist.
1. Die Private Zone
Das Herzstück betreiben wir in einer für den Kunden bereitgestellten Private Cloud. Hier liegen isoliert die relationalen Datenbanken, das ERP und die Schnittstellen zur Marketing-Automation. Diese Umgebung ist dediziert dimensioniert, um das Tagesgeschäft mit ausreichend Performance abzubilden. Während des Drops fassen wir diese Kernzone operativ nicht an und sie bleibt stabil, hochverfügbar und netzwerkseitig nach außen abgeriegelt.
2. Das elastische Schutzschild: Public Cloud via CI/CD
Rund zwei Stunden vor dem angekündigten Event wird über eine fest verdrahtete CI/CD-Pipeline eine Flotte identischer Webserver-, Cache- und Load-Balancer-Instanzen in unserer Public Cloud ausgerollt.
Diese Instanzen spiegeln exakt die Konfiguration des regulären Frontends wider. Kommt die Lastwelle, verteilt der ein Load-Balancer die Last über die hochgefahrenen Instanzen.
3. Rückbau nach dem Peak
Sobald die Transaktionen durchgelaufen sind, die Bestände im Shop abverkauft sind und der Traffic wieder auf das Normalniveau sinkt, fährt das System die Public-Cloud-Instanzen schrittweise und automatisiert herunter. Die temporären Instanzen werden zerstört. Der Shop läuft nahtlos in der Grundkonfiguration unserer Private Zone weiter.
Was das für unseren Kunden unterm Strich bedeutet
Wir haben dem Kunden keine abgehobene Buzzword-Lösung verkauft, sondern ein System hingestellt, das operative Resultate liefert:
- Kein Verbrennen von IT-Budget: Der Kunde zahlt die massive Spitzenleistung für exakt die 4 bis 8 Stunden, in denen das Event läuft.
- Keine Ausfallzeiten bei Kampagnen: Kein Zittern mehr im Team, keine 502-Bad-Gateway-Fehler und keine verärgerten Käufer in den sozialen Medien.
- Echte Datensouveränität: Die Kundendaten, Bestellhistorien und Finanzdaten verlassen zu keinem Zeitpunkt die private Zone. Flüchtige Rechenleistung wird ausgelagert, die Datenhoheit bleibt im Haus.
Das richtige Werkzeug am richtigen Platz
Infrastruktur darf kein Selbstzweck sein. Wer meint, Lastspitzen mit teurem Dauer-Blech im Leerlauf erschlagen zu müssen, verschwendet Kapital. Wer hingegen aus reiner Bequemlichkeit seine sensiblen Kernsysteme unreflektiert in unkontrollierbare Cloud-Modelle kippt, riskiert Latenzen, Sicherheitslücken und unkalkulierbare Rechnungen.
Wir haben für unseren Kunden bewiesen, wie moderne E-Commerce-Architektur aussehen muss: Ein stabiler Kern, kombiniert mit elastischer Cloud-Power an der Front.
