Douglas & Temporal.io: Skalierung eines E-Commerce-Giganten vom Monolith zu Microservices

Douglas, einer der führenden Beauty- und Gesundheits-Händler in Europa, betreibt eine Online-Plattform in 19 Ländern, die einen Jahresumsatz von über einer Milliarde Euro generiert. Hinter diesem Erfolg steht eine komplexe technische Infrastruktur, die von mehr als 20 Entwicklungsteams betreut wird. Doch das Herzstück der Plattform – eine monolithische Anwendung – war an seine Grenzen gestoßen und verhinderte das weitere Wachstum.

In diesem Beitrag zeige ich, wie wir den kritischen Bestellprozess von Douglas mithilfe einer Microservices-Architektur und Temporal.io als Workflow-Orchestrierung erfolgreich modernisiert und skalierbar gemacht haben.

Die Herausforderung: Ein Monolith am Limit

Die E-Commerce-Plattform von Douglas basierte auf einer zentralen monolithischen Anwendung (SAP Commerce Cloud), die für die gesamte Orchestrierung der Geschäftsprozesse verantwortlich war. Mit wachsendem Erfolg traten drei kritische Engpässe immer deutlicher zutage:

1. Enorme Lastspitzen: Während Promotions und Peak-Zeiten mussten bis zu 25.000 Bestellungen pro Stunde (oder mehr) verarbeitet werden, was die Compute-Ressourcen des Monolithen stark beanspruchte.
2. Datenbank-Engpass: Die zentrale Datenbank der Anwendung hatte ein hartes Limit von vier Terabyte, das nicht erweitert werden konnte. Jede Bestellung landete in dieser Datenbank, was eine unüberwindbare Skalierungsgrenze darstellte.
3. Langsamer Entwicklungszyklus: Da über 20 Teams an einer gemeinsamen Codebasis arbeiteten, waren Deployments der Kernanwendung ein großer organisatorischer Aufwand und fanden nur alle zwei Wochen statt. Dies bremste die Innovationsgeschwindigkeit erheblich.

Die Vision: Eine zukunftssichere und skalierbare Architektur

Um diese Herausforderungen zu meistern, definierten wir eine klare Vision für die zukünftige Architektur:

• Vollständige Entkopplung: Die gesamte Bestellabwicklung sollte außerhalb der monolithischen Commerce-Anwendung stattfinden.
• Horizontale Skalierbarkeit: Die neue Lösung musste vollständig horizontal skalierbar sein, um zukünftiges Wachstum und noch höhere Lastspitzen abzufangen.
• Agilität für Teams: Die Architektur sollte es den zahlreichen Entwicklungsteams ermöglichen, unabhängig und schnell zu arbeiten und zu deployen.

Die Lösung: Eine schrittweise Migration mit Temporal.io

Ein “Big Bang”-Rewrite des geschäftskritischen Bestellprozesses kam aufgrund des hohen Risikos nicht infrage. Stattdessen planten wir eine schrittweise, risikominimierte Migration, bei der Temporal.io als verteiltes Workflow-System die zentrale Rolle spielte.

Phase 1: Die Orchestrierung mit Temporal extrahieren

Der erste Schritt bestand darin, die Workflow-Orchestrierung aus dem Monolithen herauszulösen. Wir ersetzten die interne “Task Engine” der Commerce Cloud durch Temporal.

• Die bestehende Geschäftslogik verblieb zunächst im Monolithen, wurde aber als Temporal Activities gekapselt. Der Monolith agierte somit als “Worker” im Temporal Cluster.
• Die Workflow-Definitionen selbst liefen in einem neuen, unabhängigen Microservice.

Dieser Ansatz brachte sofortige Vorteile: Die Workflows konnten nun unabhängig vom Monolithen deployed und skaliert werden, und ein Teil der Last wurde bereits auf das Temporal-Cluster verlagert. Um das Risiko weiter zu minimieren, wurde die Umstellung schrittweise ausgerollt: Zuerst für Prozesse mit geringem Risiko und hohem Nutzen (wie der Retourenprozess) und anfangs nur in kleineren Ländern oder für einen Teil der Nutzer mittels Feature-Flags.

Phase 2: Geschäftslogik in Microservices überführen mit dem Strangler Fig Pattern

Nachdem die Orchestrierung erfolgreich migriert war, folgte der zweite, entscheidende Schritt: die Extraktion der eigentlichen Geschäftslogik in eine Microservices-Architektur.

Hierbei nutzten wir das Strangler Fig Pattern. Der Temporal-Workflow diente dabei als “Strangler Facade”, die den Aufruf entweder an die alte Logik im Monolithen oder an die neue Logik in einem Microservice weiterleitete. Schritt für Schritt wurde so eine Funktionalität nach der anderen aus dem Altsystem “herausgewürgt” und durch moderne, unabhängige Services ersetzt, bis der Monolith in diesem Bereich keine Rolle mehr spielte.

Das Ergebnis: Skalierbar, agil und resilient

Die neue Architektur hat die ursprünglichen Herausforderungen vollständig gelöst:

• Horizontale Skalierbarkeit: Sowohl Temporal als auch die Microservices sind von Grund auf horizontal skalierbar konzipiert, wodurch die Plattform für zukünftige Lastspitzen gerüstet ist.
• Aufgelöster Datenbank-Engpass: Bestelldaten werden nun in dedizierten Datenbanken gespeichert, die zu den jeweiligen Microservices gehören. Dies löst nicht nur das 4-TB-Limit, sondern ermöglicht auch, die Daten je nach fachlicher Domäne (z. B. Payment vs. Fulfillment) optimal zu modellieren und bei Bedarf auch NoSQL-Datenbanken zu nutzen.
• Beschleunigte Entwicklung (CI/CD): Die Teams haben nun die volle Verantwortung für ihre Services und können diese dank Continuous-Deployment-Pipelines schnell und unabhängig voneinander ausrollen. Dies steigerte die Entwicklungsgeschwindigkeit massiv.

Fazit

Die Migration des Douglas Bestellprozesses ist ein Paradebeispiel dafür, wie eine geschäftskritische Anwendung unter Volllast modernisiert werden kann. Durch den schrittweisen Ansatz mit Temporal.io und dem Strangler Fig Pattern konnten wir das Risiko minimieren und eine hoch skalierbare, zukunftssichere E-Commerce-Plattform schaffen.

Details zu diesem Projekt präsentiere ich auch in meinem Vortrag auf dem offiziellen Temporal Meetup, den Sie sich hier auf YouTube ansehen können.

Stehen Sie vor ähnlichen Herausforderungen bei der Skalierung oder Modernisierung Ihrer Systeme? Ich helfe Unternehmen, komplexe Geschäftsprozesse zu automatisieren und robuste, skalierbare Architekturen zu entwerfen. Lassen Sie uns sprechen!