Wie baut man eine skalierbare Infrastruktur für einen Onlineshop auf

Der Aufbau einer skalierbaren Infrastruktur für einen Onlineshop beginnt heute nur sehr selten mit der Frage, welchen Server man wählen sollte. Diese Frage klingt logisch, führt in der Praxis aber zu einem zu engen Verständnis von Skalierung. Im modernen E-Commerce geht es nicht mehr nur darum, ob der Shop „den Traffic aushält“, sondern darum, ob die gesamte Architektur gemeinsam mit dem Business wachsen kann – ohne zunehmendes Chaos, kostspielige Ausfälle und die Notwendigkeit, die Umgebung bei jedem größeren Umsatzsprung neu aufzubauen. Deshalb sollte die Diskussion über Skalierbarkeit nicht beim Hosting beginnen, sondern bei der Architektur der einzelnen Schichten, der Art der Traffic-Verarbeitung, der Rolle von Cache, der Trennung unterstützender Services, dem Monitoring und der Bereitschaft für saisonale Peaks und internationales Wachstum.

Das ist besonders wichtig in dem Moment, in dem ein Onlineshop aufhört, nur eine einfache Verkaufswebsite zu sein, und zu einem Teil einer größeren digitalen Umgebung wird. In der Praxis muss die Infrastruktur heute nicht nur das Frontend und den Checkout unterstützen, sondern auch Integrationen mit ERP, PIM, Payments, Logistik, Suche, Task-Queues, Analyse-Tools und Personalisierungsmechanismen. Wenn diese Bereiche nicht richtig voneinander getrennt und sauber gesteuert werden, führt ein Anstieg der Nutzerzahl sehr schnell nicht nur zu einer langsameren Shop-Performance, sondern auch zu operativer Überlastung und Wartungsproblemen.

Was eine skalierbare Infrastruktur für einen Onlineshop wirklich bedeutet

Skalierbarkeit im E-Commerce bedeutet nicht nur die Fähigkeit, eine größere Anzahl von Besuchen auf der Website zu verarbeiten. Es ist ein deutlich breiteres Konzept. Eine gut konzipierte Infrastruktur sollte Wachstum in mehreren Dimensionen gleichzeitig ermöglichen: Traffic, Anzahl der Bestellungen, Anzahl der Produkte, Anzahl der Märkte, Komplexität der Prozesse und Anzahl der Integrationen. Anders gesagt: Der Shop sollte eine höhere Last bewältigen können, ohne an Performance zu verlieren, aber auch ohne dass jede neue geschäftliche Anforderung eine improvisierte Erweiterung des gesamten technologischen Backends erfordert. Genau deshalb ist eine reife Architektur heute eher einem flexiblen Ökosystem ähnlich als einem einzelnen zentralen Server, der für alles verantwortlich ist.

In der Praxis ist eine skalierbare Infrastruktur eine Infrastruktur, die das, was für den Kunden kritisch ist, von dem trennen kann, was asynchron verarbeitet oder gecacht werden kann. Schließlich muss nicht jede Operation im Shop sofort in derselben Schicht und im selben Moment ausgeführt werden. Wenn das Mailversandsystem, die Suchindexierung, die Datensynchronisierung, die Feed-Generierung oder Integrationsaufgaben um dieselben Ressourcen konkurrieren wie Warenkorb und Checkout, dann kann selbst ein relativ moderater Lastanstieg genau jene Elemente treffen, die geschäftlich am sensibelsten sind. Die offizielle Dokumentation von Shopware zeigt diese Richtung sehr deutlich und weist getrennt auf Bereiche wie Cache, Session Storage, Lock Storage, Datenbank, Message Queue und Scheduled Tasks hin. In Produktionsumgebungen empfiehlt sie zudem ein dediziertes Queueing-System statt SQL-basierter Queues – aus Gründen der Skalierbarkeit und Observability.

Warum ein einzelner „starker Server“ das Problem nicht löst

Viele Onlineshops wachsen lange in einem Modell, das sich sehr einfach beschreiben lässt: Wenn es langsamer wird, stellen wir eine stärkere Maschine bereit. Dieses Modell funktioniert am Anfang manchmal, wird mit der Zeit aber zu teuer und zu unflexibel. Vertikale Skalierung, also das Hinzufügen von CPU und RAM zu einer einzelnen Umgebung, hat ihre Grenzen. Noch wichtiger ist, dass sie das architektonische Problem nicht löst. Wenn Frontend, Backend, Datenbank, Suchmaschine, asynchrone Tasks und Integrationen weiterhin zu eng miteinander gekoppelt sind, dann sorgt selbst mehr Rechenleistung nicht für echte Planbarkeit. Sie verschiebt das Problem nur für eine gewisse Zeit.

In Cloud-Umgebungen sieht die Logik des E-Commerce-Aufbaus heute anders aus. AWS weist in seinen Architekturmaterialien für E-Commerce darauf hin, dass die Cloud Skalierbarkeit grundsätzlich verändert, weil sie elastisches Autoscaling on demand, Managed Databases mit automatischen Backups und Point-in-Time-Recovery sowie High Availability innerhalb einer Region und über mehrere Regionen hinweg ermöglicht. Das bedeutet natürlich nicht, dass jedes Unternehmen sofort eine global verteilte Umgebung braucht. Es zeigt aber sehr klar, dass moderne Skalierbarkeit auf der richtigen Trennung von Schichten und Services basiert – und nicht auf einem einzelnen „größeren“ Server.

Frontend, CDN und Cache – die erste Verteidigungslinie gegen Überlastung

Eines der wichtigsten Elemente einer skalierbaren Infrastruktur ist die Begrenzung der Anzahl von Situationen, in denen jede Kundenanfrage direkt zum Origin gehen und die vollständige Applikationslogik auslösen muss. Im E-Commerce betrifft ein großer Teil des Traffics Ressourcen, die durch eine Zwischenschicht – also ein CDN und gut geplantes Caching – schneller und günstiger ausgeliefert werden können. Cloudflare beschreibt dieses Modell ganz direkt: Kopien häufig genutzter Inhalte werden in geografisch verteilten Rechenzentren näher am Nutzer gespeichert, was die Last auf dem Origin-Server reduziert und die Seitenperformance verbessert. Zusätzlich stellt die Plattform Mechanismen wie Cache Rules, Tiered Cache und Purge bereit, mit denen sich bewusst steuern lässt, was gecacht werden soll und wie lange.

Das ist viel wichtiger, als oft angenommen wird. Ein skalierbarer Shop sollte nicht die komplette Anwendungsschicht bemühen, um jedes Bild, jede JS-Datei oder jede statische Antwort auszuliefern, die näher am Nutzer verarbeitet werden kann. Cloudflare weist außerdem darauf hin, dass schnelles Laden des Shops direkten Einfluss auf die Conversion hat und dass Verbesserungen der Storefront-Performance durch Edge Caching, Bildoptimierung, Asset-Minifizierung oder serverseitiges Laden externer Skripte unterstützt werden können. In der Praxis bedeutet das, dass die Skalierbarkeit der Infrastruktur bereits auf der Ebene der User Experience beginnt – und nicht erst im Serverraum.

Gleichzeitig sollte man daran denken, dass ein CDN allein die Architektur nicht automatisch „repariert“. Cloudflare weist klar darauf hin, dass HTML und JSON standardmäßig nicht gecacht werden und dass die Effektivität des Cache von Regeln, Headern und der Art abhängt, wie Responses vom Origin gemanagt werden. Das ist ein sehr wichtiger Punkt, weil viele Teams ein CDN als einfache Beschleunigung der Website verstehen, während die Cache-Schicht in Wirklichkeit bewusst geplant werden muss. Ohne das gerät man leicht in eine Situation, in der die Infrastruktur modern aussieht, der schwerste Traffic in der Praxis aber weiterhin direkt auf die Anwendung und die Datenbank trifft.

Datenbank, Suchmaschine und Queues – die Bereiche, die am häufigsten über Stabilität entscheiden

In einem gut skalierenden Onlineshop kann das Backend nicht als eine unteilbare Einheit betrachtet werden. Die offizielle Dokumentation von Shopware zeigt sehr deutlich, dass eine Produktionsumgebung auf mehreren getrennten Komponenten basiert: einer MySQL- oder MariaDB-Datenbank, einer optionalen Suchschicht auf Basis von OpenSearch oder Elasticsearch, einer Cache- und Session-Storage-Schicht mit Redis oder Valkey sowie einer Task-Queue, für die in Produktionsumgebungen eine dedizierte Lösung wie RabbitMQ empfohlen wird, statt auf SQL zu setzen. Allein diese Liste zeigt klar, dass die Skalierung eines Shops nicht darin besteht, einfach „Shopware zu betreiben“, sondern ein ganzes Set spezialisierter infrastruktureller Rollen zu betreuen.

Gerade in diesen Bereichen zeigen sich am häufigsten die echten Bottlenecks. Die Datenbank beginnt zu leiden, wenn zu viele gleichzeitige transaktionale Operationen und Reads auf sie treffen, die Suchmaschine wird bei einer wachsenden Anzahl von Produkten und bei der Indexierung zum Problem, und das Fehlen einer separaten Queue führt dazu, dass Hintergrundaufgaben mit Verkaufsprozessen konkurrieren. Shopware betont zudem die Rolle der Optimierung von Session Storage und Lock Storage und weist auf die Bedeutung eines effizienten Cache-Managements hin. Das sind keine technischen Details ohne Bedeutung. Das sind die Elemente, die darüber entscheiden, ob der Shop während einer Promotion oder eines saisonalen Peaks langsamer wird oder sich weiterhin planbar verhält.

Es lohnt sich auch zu beachten, dass der Plattformanbieter zwischen Minimalanforderungen und einer Umgebung unterscheidet, die tatsächlich für Wachstum bereit ist. Shopware nennt unter anderem minimale Hardwareparameter und unterstützte Stack-Versionen, erweitert die Dokumentation aber gleichzeitig um Bereiche wie Search, Cache, Queue, Observability und Performance Testing. Das ist ein wichtiges Signal: Eine Infrastruktur, die „hochfährt“, muss noch keine Infrastruktur sein, die gut skaliert.

Warum Headless und die Trennung der Schichten Skalierbarkeit immer häufiger unterstützen

Ab einem bestimmten Wachstumsstadium beginnen viele Unternehmen zu erkennen, dass das Problem nicht mehr nur das Backend selbst ist, sondern die Abhängigkeit zwischen dem Frontend und dem Rest der Plattform. Wenn die Storefront zu eng mit dem Core gekoppelt ist, wirkt sich jede größere Veränderung in der User Experience, der Performance, bei A/B-Tests oder bei der Platzierung neuer Funktionen auf einen breiteren Bereich des Systems aus. Genau deshalb werden Headless- und Composable-Architekturen immer häufiger nicht nur zu einem Trend, sondern zu einer Methode für besser planbare Skalierung. Shopware beschreibt die Store API als eine standardisierte Schnittstellenschicht zwischen Client-Anwendungen und dem Plattform-Core, die es ermöglicht, Shop-Funktionen über ein Headless-Frontend per JSON over HTTP zu nutzen.

Dieser Ansatz hat sehr praktische infrastrukturelle Konsequenzen. Die Dokumentation von Shopware Frontends weist darauf hin, dass bei wachsender Anzahl an Customizations ein auf Themes basierender Ansatz aufgrund der Abhängigkeitsmatrix zwischen Core, Theme, Plugins und Extensions zunehmend schwer wartbar werden kann. In solchen Situationen kann eine Headless-Architektur weniger komplex, agiler und besser skalierbar sein. Darüber hinaus wurde Shopware Composable Frontends als Framework für die Erstellung cloud-nativer Custom Storefronts konzipiert, die auf einer HTTP API basieren. Das bedeutet nicht, dass jeder Shop sofort auf Headless umsteigen sollte. Für Organisationen, die mehrere Märkte, Kanäle und Frontend-Szenarien entwickeln, wird die Trennung der Schichten jedoch oft zu einem realen Instrument zur Reduzierung von Komplexität.

In der Praxis ist hier nicht das Wort „headless“ selbst das Entscheidende, sondern das, was es operativ verändert. Wenn das Frontend in größerem Maße unabhängig vom Backend entwickelt, gecacht, ausgerollt und skaliert werden kann, gewinnt die Organisation deutlich mehr Flexibilität bei der Arbeit an Performance und User Experience. Genau deshalb wird skalierbare Infrastruktur immer häufiger als System von Schichten entworfen – und nicht als eine einzige Anwendung, die gleichzeitig alles bedienen muss.

Hohe Verfügbarkeit ist kein Zusatz, sondern eine Voraussetzung für Skalierung

Eines der häufiger übersehenen Themen bei der Planung von Infrastruktur ist die Widerstandsfähigkeit gegen Ausfälle. Ein Shop, der mit Traffic gut zurechtkommt, aber keinen sinnvollen Plan für den Ausfall einer einzelnen Komponente hat, ist noch immer nicht wirklich skalierbar. AWS betont in seinem Architekturleitfaden für E-Commerce, dass High Availability sowohl innerhalb einer Region als auch über Regionen hinweg aufgebaut werden kann und dass Cloud-Services die Kontinuität bei Ausfällen von Servern, Storage oder sogar ganzen Rechenzentren ermöglichen. Aus Business-Sicht bedeutet das etwas sehr Konkretes: Skalierung besteht nicht nur darin, mehr Leistung bereitzustellen, sondern auch darin, das Risiko zu verringern, dass ein Single Point of Failure den Verkauf stoppt.

Im E-Commerce ist das besonders wichtig während Kampagnen, Launches, Black Friday oder internationaler Expansion. In solchen Momenten können selbst kurze Ausfälle nicht nur Umsatzverlust bedeuten, sondern auch höhere Marketingkosten, Fehler in Integrationen und eine schlechtere Customer Experience. Deshalb muss die Resilienz der Umgebung nicht nur die Anwendungsschicht umfassen, sondern auch die Datenbank, Backup-Mechanismen, Queues, Cache, Load Balancing und die Art, wie das System nach einem Incident wiederhergestellt wird. Skalierbarkeit ohne Resilienz ist nur teilweise nützlich, weil das Business die Schwäche der Infrastruktur genau dann am stärksten spürt, wenn die Last steigt.

Monitoring, Observability und Load Testing – ohne sie ist bewusste Skalierung nicht möglich

Einer der häufigsten Fehler im E-Commerce besteht darin, Skalierbarkeit ausschließlich in infrastrukturellen Kategorien zu denken und nicht in Kategorien der System-Observability. Dabei lässt sich nichts gut skalieren, was wir nicht messen können. Google weist seit Jahren auf vier grundlegende Monitoring-Signale für verteilte Systeme hin: Latency, Traffic, Errors und Saturation. Das ist auch für Onlineshops ein sehr nützlicher Rahmen, weil er hilft, das Denken über den Zustand der Umgebung nicht um Dutzende zufälliger Diagramme herum zu organisieren, sondern um einige grundlegende Fragen: Wie lange braucht das System für eine Antwort, wie viel Traffic verarbeitet es, wie viele Fehler erzeugt es und wie nah ist es an der Grenze seiner Ressourcen.

Shopware entwickelt diesen Bereich auf Ebene der Hosting- und Observability-Dokumentation weiter und verweist unter anderem auf OpenTelemetry als Standard für das Sammeln von Distributed Traces, Metrics und Logs sowie auf Integrationsunterstützung für Umgebungen auf Basis des Grafana Stack oder anderer Monitoring-Tools. Das ist wichtig, weil die Skalierung eines Shops in der Praxis nicht darauf beruhen sollte zu raten, welche Schicht das Problem verursacht. White-box Monitoring, über das auch Google schreibt, macht es möglich, ein Applikationsproblem von einem Datenbankproblem, einem Netzwerkproblem oder einer konkreten internen Abhängigkeit zu unterscheiden. Ohne ein solches Wissen reagieren Teams in der Regel zu spät und zu breit.

Ebenso wichtig ist Load Testing. Shopware stellt nicht nur Dokumentation für Performance-Tests mit k6 bereit, sondern empfiehlt sogar, Benchmarks in die Pipelines größerer Systeme einzubinden, und betont dabei, dass sich ein generischer Produktbenchmark nur selten auf ein individuelles, stark angepasstes Projekt übertragen lässt. Das ist eine sehr wertvolle Beobachtung, weil sich Skalierbarkeit in der Praxis nicht zuverlässig auf Grundlage allgemeiner Hosting-Versprechen beurteilen lässt. Man muss einen konkreten Shop testen – mit seinem Katalog, seinem Checkout, seinen Integrationen und den realen User Journeys.

Skalierbarkeit muss wirtschaftlich sinnvoll sein und nicht nur technisch beeindruckend

Im reifen E-Commerce ist gute Infrastruktur nicht die technisch beeindruckendste, sondern diejenige, die das beste Verhältnis von Planbarkeit zu Kosten bietet. AWS weist darauf hin, dass die Migration von E-Commerce-Plattformen in die Cloud die richtige Dimensionierung der einzelnen Stack-Schichten hinsichtlich Performance und Kosteneffizienz erleichtert – unter anderem dank Autoscaling und Managed Services. Das ist wichtig, weil viele Umgebungen heute entweder unter- oder überdimensioniert sind. Die einen leiden unter Traffic-Peaks, die anderen verbrennen das ganze Jahr über Budget für Ressourcen, die tatsächlich nur wenige Wochen benötigt werden.

Deshalb sollte skalierbare Infrastruktur nicht nur für das Peak-Szenario entworfen werden, sondern auch für die alltägliche Wirtschaftlichkeit des Betriebs. Das bedeutet eine bewusste Trennung zwischen Schichten, die konstante Ressourcen benötigen, und solchen, die elastisch sein können; die Nutzung von Cache zur Entlastung des Origin; die Begrenzung synchroner Operationen in kritischen Pfaden; und die Implementierung von Monitoring-Mechanismen, die ein Eingreifen ermöglichen, bevor die Umgebung wirklich an ihre Grenzen kommt. Andernfalls erreicht das Unternehmen sehr leicht einen Punkt, an dem die Infrastruktur teuer, komplex und trotzdem nicht wirklich vertrauenswürdig ist.

Wie eine skalierbare Infrastruktur für einen Onlineshop in der Praxis aussieht

In der Praxis haben die am besten skalierenden E-Commerce-Umgebungen mehrere gemeinsame Merkmale. Das Frontend ist möglichst leichtgewichtig und wird durch ein CDN unterstützt, die Anwendungsschicht ist nicht für alles gleichzeitig verantwortlich, Search und Cache werden als separate Verantwortungsbereiche behandelt, Hintergrundaufgaben werden außerhalb der Datenbank in Queues verarbeitet, und das Monitoring umfasst nicht nur Availability, sondern auch Latency, Errors und Resource Saturation. Hinzu kommen die Kontrolle über Deployment-Änderungen, Load Testing und klar definierte Stellen, an denen das System wachsen kann, ohne dass ein radikaler Umbau notwendig wird. All das zusammen ergibt keinen einzelnen „Server für den Shop“, sondern eine Umgebung, die für Wachstum vorbereitet ist.

Bei Plattformen wie Shopware ist sehr deutlich zu sehen, dass diese Richtung bereits in die Denkweise über modernen E-Commerce eingeschrieben ist. Die offizielle Dokumentation spricht gleichzeitig über Performance, Cache, Redis, Queues, OpenSearch, Observability, Headless Frontends und Performance Tests. Das zeigt, dass die Skalierung eines Onlineshops keine Infrastrukturaufgabe im engen Sinne mehr ist. Es ist eine architektonische Aufgabe, die die technische Schicht mit den geschäftlichen Anforderungen, dem Tempo der Veränderung und der zukünftigen Komplexität der Umgebung verbindet.

Wie man eine Infrastruktur aufbaut, die das Wachstum des Shops in ein oder zwei Jahren nicht ausbremst

Deshalb sollte die Frage, wie man eine skalierbare Infrastruktur für einen Onlineshop aufbaut, nicht auf die Wahl eines Hosting-Anbieters oder einer einzelnen Technologie reduziert werden. Viel wichtiger ist, ob die Umgebung so konzipiert wurde, dass sie gemeinsam mit dem Business wachsen kann, ohne dass sich technische und operative Schulden aufbauen. Ein Shop, der heute den aktuellen Verkauf bewältigen muss, kann morgen mehrere Märkte, eine größere Anzahl an Integrationen, ein fortgeschritteneres B2B, Personalisierung, neue Frontend-Kanäle und eine deutlich höhere Widerstandsfähigkeit gegen Traffic-Spikes benötigen. Wenn die Infrastruktur auf diese Richtung nicht vorbereitet ist, wird sie das Unternehmen schneller einschränken, als Entscheidungsteams normalerweise annehmen.

Aus unserer Perspektive ist deshalb das Wichtigste, Infrastruktur nicht als technisches Backend „zum Betrieb des Shops“ zu verstehen, sondern als Fundament für die Skalierung des gesamten E-Commerce. Das bedeutet eine Architektur aus Schichten, gut geplanten Cache, separate Services für Search und Queues, einen bewussten Umgang mit Headless dort, wo es einen Vorteil bringt, und ein Monitoring, das Entscheidungen auf Basis realer Systemsignale ermöglicht. Erst dann hört Infrastruktur auf, ein notwendiger Kostenblock zu sein, und wird zu einer der wichtigsten Voraussetzungen für planbares Umsatzwachstum.