Welche Magento-Hosting-Architektur eignet sich für einen stark frequentierten Onlineshop?
by Rahul Basu
August 27,2026
Ein Magento-Shop, der an einem gewöhnlichen Dienstagmittag in weniger als einer Sekunde lädt, kann plötzlich an seine Grenzen kommen, sobald eine Marketingkampagne, eine Erwähnung in der Presse oder ein Black-Friday-Angebot den Traffic verzehnfacht. Die unbequeme Wahrheit für viele Händler lautet: Nicht der Hosting-Tarif war das eigentliche Problem – sondern die zugrunde liegende Architektur. Ein einzelner, leistungsstark konfigurierter Server kann eine beeindruckende Menge an alltäglichem Traffic bewältigen. Doch selbst die größte Menge an CPU-Leistung oder Arbeitsspeicher kann eine Architektur nicht retten, die von Anfang an nicht für Skalierbarkeit ausgelegt wurde.
Eine Magento-Hosting-Architektur ist keine einmalige Entscheidung, die beim Start des Shops getroffen wird. Sie entwickelt sich weiter – von einem einzelnen Server über getrennte Ebenen bis hin zu einer vollständig verteilten Cloud Umgebung. Entscheidend ist, zu erkennen, welche Entwicklungsstufe Ihr Shop tatsächlich benötigt, anstatt die technisch beeindruckendste Variante zu wählen. Genau das unterscheidet einen resilienten Shop von einer unnötig teuren Infrastruktur.
Diese Entwicklung ist keine Hierarchie, die jeder Shop bis zur letzten Stufe durchlaufen muss. Viele erfolgreiche Magento-Shops bleiben dauerhaft bei einer gut optimierten Single-Server- oder Multi-Server-Architektur. Die richtige Architektur ist diejenige, die zum tatsächlichen aktuellen Traffic und zu den Wachstumsplänen des Unternehmens passt – nicht zwangsläufig die technisch komplexeste verfügbare Lösung.
Magento-Architektur mit einem einzelnen Server
Bei einer Architektur mit einem einzelnen Server laufen Webserver, Datenbank, Cache und Suchmaschine auf derselben Maschine. Sie ist am einfachsten zu verwalten und verursacht die geringsten Betriebskosten.Für eine große Anzahl kleiner und mittelständischer Magento-Shops ist sie vollkommen ausreichend – vorausgesetzt, der Server ist passend dimensioniert und professionell optimiert und wird nicht einfach mit den Standardeinstellungen betrieben. Der Nachteil ist ebenso einfach: Jede Ebene greift auf dieselben Ressourcen für CPU, Arbeitsspeicher und Festplattenzugriffe zu. Ein Traffic-Anstieg, der den Webserver belastet, erhöht gleichzeitig den Druck auf die Datenbank, die auf derselben Maschine läuft. Außerdem kann keine einzelne Ebene skaliert werden, ohne den gesamten Server zu skalieren. Ein gut konfigurierter einzelner Server kann dennoch problemlos mehrere hunderttausend Besucher pro Monat unterstützen. Es handelt sich also um eine durchaus leistungsfähige Ausgangsarchitektur und nicht lediglich um eine Übergangslösung. Allerdings gibt es eine klare Leistungsgrenze.Magento-Architektur mit mehreren Servern
Eine Multi-Server-Architektur trennt diese Ebenen auf dedizierte Maschinen auf –typischerweise auf einen Webserver, einen Datenbankserver und eine Caching-Ebene. Jede Komponente wird dabei gezielt für ihre jeweilige Aufgabe dimensioniert und optimiert, anstatt Ressourcen mit allen anderen Komponenten teilen zu müssen. Dies ist normalerweise der erste ernsthafte Skalierungsschritt für einen wachsenden Magento Shop. Gleichzeitig wird das wichtigste Problem einer Single-Server-Architektur gelöst: Ein Anstieg des Web-Traffics entzieht der Datenbank nicht länger die Ressourcen, die sie für die Verarbeitung von Bestellungen benötigt. Darüber hinaus entsteht die Möglichkeit, Redundanz aufzubauen. Da die Webebene getrennt ist, können mehrere Webserver hinter einem Load Balancer betrieben werden. Fällt ein einzelner Server aus, muss dadurch nicht automatisch der gesamte Onlineshop offline gehen – etwas, das bei einer Single-Server-Architektur nicht möglich ist.Magento-Architektur in der Cloud
Eine Cloud-Architektur geht noch einen Schritt weiter. Jede Ebene wird auf einer Cloud Infrastruktur verteilt, sodass sie unabhängig voneinander und bei anspruchsvolleren Konfigurationen sogar automatisch skaliert werden kann. Die eigene Commerce-Dokumentation von Adobe beschreibt dies als aufgeteilte Architektur: Anstatt dass mehrere vollständige Knoten jeweils alle Aufgaben übernehmen, werden die Ressourcen in eine Webebene und eine Serviceebene aufgeteilt. Die Serviceebene umfasst dabei Datenbank-, Cache- und Suchinfrastruktur, wobei beide Ebenen entsprechend ihrer individuellen Auslastung skaliert werden können. Hier wird echte Hochverfügbarkeit realistisch. Es geht nicht mehr nur darum, den Ausfall eines einzelnen Servers zu überstehen, sondern auch darum, plötzliche und unvorhersehbare Traffic-Spitzen ohne manuelles Eingreifen aufzufangen. Natürlich ist dies auch die komplexeste und teuerste der drei Architekturstufen. Deshalb sollte ehrlich geprüft werden, ob ein Shop tatsächlich über einfachere Alternativen hinausgewachsen ist, anstatt eine Cloud-Architektur nur deshalb einzusetzen, weil sie auf den ersten Blick als die sicherste Standardlösung erscheint.Webserver-Ebene
Die Webserver-Ebene verarbeitet eingehende Anfragen und stellt Seiten bereit. Bei einem Traffic Anstieg ist sie normalerweise die erste Ebene, die unter Druck gerät. Die Referenzarchitektur von Adobe empfiehlt, Knoten sowohl für Traffic als auch für Redundanz skalierbar zu machen. Dabei kann ein Knoten als Master für die Ausführung von Cron-Jobs bestimmt werden. Alternativ können dedizierte Verwaltungs- und Worker-Knoten eingesetzt werden, sodass Hintergrundprozesse vollständig von kundenbezogenen Anfragen getrennt bleiben. NGINX ist bei Magento-Bereitstellungen die Standardwahl für diese Ebene. Der Webserver wird insbesondere dafür geschätzt, viele parallele Verbindungen effizient zu verarbeiten, ohne bei hoher Auslastung unverhältnismäßig viele Serverressourcen zu verbrauchen.Datenbank-Ebene
Die Datenbankebene ist häufig die tatsächliche Ursache von Performance Problemen, selbst wenn die sichtbaren Symptome an anderer Stelle auftreten. Für stark frequentierte Websites empfiehlt Adobe unter anderem den Einsatz von Slave-Datenbanken, um eine schnelle Wiederherstellung und zuverlässige Backups zu ermöglichen. Innerhalb von Adobe Commerce wird außerdem empfohlen, Datenbanken für Bestellungen und Warenkörbe getrennt von den übrigen Katalog- und Kundendaten zu betrachten. Dadurch konkurrieren Checkout-Aktivitäten nicht direkt mit alltäglichen Browsing-Abfragen um dieselben Datenbankressourcen. MySQL oder MariaDB bleiben hier die Standardlösungen. Für die tatsächliche Performance sind jedoch die Konfiguration rund um die Datenbank – insbesondere die Indexierungsstrategie, die Optimierung von Abfragen sowie die Verteilung von Lese- und Schreibvorgängen – häufig wichtiger als die Wahl der Datenbank-Engine selbst.Cache-Ebene
Magento unterstützt standardmäßig mehrere Engines für das Full-Page-Caching, darunter File, Memcache, Redis und Varnish. Für alles, was über eine sehr einfache Umgebung hinausgeht, wird Varnish im Allgemeinen als Full-Page-Cache empfohlen. Ein Varnish-Cluster kann entsprechend dem Traffic eines Shops skaliert werden. Die Dimensionierung der Instanzen richtet sich dabei nach der tatsächlichen Anzahl der benötigten zwischengespeicherten Seiten. Bei stark frequentierten Websites kann ein Varnish-Master außerdem dafür sorgen, dass Cache-Leerungsanfragen jeden Webknoten höchstens einmal erreichen, anstatt wiederholt an denselben Knoten gesendet zu werden. Redis übernimmt typischerweise die Speicherung von Sitzungsdaten und zusätzliche Caching-Ebenen neben Varnish. Adobe empfiehlt außerdem, gegebenenfalls eine separate Redis-Instanz speziell für Sitzungen einzusetzen und diese so zu dimensionieren, dass sie den erwarteten maximalen Cache problemlos aufnehmen kann.Suchinfrastruktur
Die Produktsuche und Katalognavigation werden auf einer dedizierten Suchmaschine ausgeführt – in aktuellen Magento- und Adobe-Commerce-Bereitstellungen beispielsweise mit Elasticsearch oder OpenSearch – anstatt direkt die primäre Datenbank abzufragen. Das ist wichtiger, als es zunächst erscheinen mag. Ein großer und umfangreich filterbarer Produktkatalog erzeugt eine kontinuierliche und erhebliche Belastung der Suchinfrastruktur. Wird diese Belastung von der zentralen Datenbank ferngehalten, lässt sich die Performance von Checkout und Produktnavigation während hoher Traffic-Phasen wesentlich besser schützen.Content Delivery Network (CDN)
Ein Content Delivery Network speichert statische Inhalte wie Bilder, CSS-Dateien und JavaScript an sogenannten Edge-Standorten, die näher am jeweiligen Kunden liegen. Dadurch verkürzt sich die Ladezeit und gleichzeitig reduziert sich die Anzahl der Anfragen, die überhaupt den Ursprungsserver erreichen. Für Magento-Shops, die Kunden in mehreren Regionen bedienen, gehört ein CDN zu den besonders effektiv umsetzbaren Architekturentscheidungen. Es reduziert die Latenz für Kunden in größerer Entfernung und verringert gleichzeitig die Belastung der Webserver-Ebene während Traffic-Spitzen.Load Balancing
Sobald mehr als ein Webserver eingesetzt wird, muss eine Komponente den eingehenden Traffic auf die verschiedenen Server verteilen. Diese Aufgabe übernimmt der Load Balancer. Gleichzeitig bildet er die Grundlage für Redundanz. Wenn ein Webknoten ausfällt oder für Wartungsarbeiten vorübergehend deaktiviert werden muss, leitet ein korrekt konfigurierter Load Balancer den Traffic automatisch an die verbleibenden funktionierenden Knoten weiter, ohne dass Kunden den Ausfall bemerken müssen.Monitoring
Architekturentscheidungen sind nur so gut wie die Transparenz, die ein Team über die tatsächliche Performance dieser Architektur besitzt. Proaktives Monitoring – beispielsweise die Echtzeitüberwachung von Antwortzeiten, Fehlerraten, Datenbankauslastung und Cache-Trefferraten – verwandelt ein sich entwickelndes Problem in ein lösbares Problem, bevor es zu einem Ausfall kommt, den Kunden bemerken. Je stärker die Architektur verteilt ist, desto wichtiger wird dies. Schließlich gibt es mehr einzelne Komponenten, deren Performance unabhängig voneinander nachlassen kann.Disaster Recovery
Keine Architektur kann das Risiko eines Ausfalls vollständig beseitigen –Hardware kann ausfallen, Bereitstellungen können fehlschlagen und ganze Regionen können gelegentlich von tatsächlichen Ausfällen betroffen sein. Ein professioneller Disaster-Recovery-Plan umfasst daher:- Regelmäßige und automatisierte Backups
- Einen getesteten und dokumentierten Wiederherstellungsprozess
- Für Shops mit hohen Ausfallkosten eine sekundäre Umgebung oder Region, die im Ernstfall übernehmen kann
Wann sollte ein Magento-Shop über einen einzelnen Server hinausgehen?
Es gibt keine einzelne Besucherzahl, die diese Entscheidung automatisch auslöst. In der Praxis treten jedoch mehrere Anzeichen häufig gemeinsam auf, wenn ein Shop tatsächlich aus einer Single-Server-Architektur herausgewachsen ist. Dazu gehören deutlich längere Antwortzeiten während normaler Spitzenzeiten – nicht nur bei außergewöhnlichen Traffic-Spitzen –, eine erkennbare Konkurrenz zwischen Datenbank und Webserver um gemeinsame Ressourcen, eine schlechtere Checkout- oder Such-Performance während Verkaufsaktionen oder Kampagnen sowie steigende wirtschaftliche Kosten möglicher Ausfallzeiten. Die skalierte Architektur von Adobe, die in größeren Commerce-Cloud Tarifen verfügbar ist, zeigt, wohin diese Entwicklung führen kann: eine auf mindestens sechs Knoten aufgeteilte Architektur mit drei Knoten für die Webebene und drei Knoten für die zentrale Datenbank und Services. Beide Ebenen können unabhängig voneinander skaliert werden. Zusätzlich ermöglicht die Webebene horizontales Autoscaling. Neue Knoten werden hinzugefügt, wenn die CPU-Auslastung über einen längeren Zeitraum ungefähr 75 % erreicht und gleichzeitig ein deutlicher Anstieg des Traffics festgestellt wird. Sobald sich die Auslastung wieder stabilisiert, können Knoten entfernt werden. In Performance-Benchmarks mit Adobe Commerce Cloud 2.4.5 unterstützte diese Kombination aus horizontaler Skalierung der Web- und Datenbankebene mehr als 208.000 Bestellungen pro Stunde und 2 Millionen Seitenaufrufe pro Stunde. Das zeigt, welches Leistungsniveau eine entsprechend verteilte Architektur erreichen kann – auch wenn nur wenige Shops tatsächlich mit Traffic-Zahlen dieser Größenordnung planen müssen.Magento-Hosting-Architektur nach Entwicklungsstufe des Shops
Die folgende Übersicht zeigt, wie sich die Architektur eines Magento-Shops typischerweise weiterentwickelt, wenn Traffic und technische Komplexität zunehmen.| Kleiner Shop | Wachsender Shop | Stark frequentierter Shop | Unternehmen | |
| Architektur | Einzelner Server | Mehrere Server | Cloud mit verteilten Ebenen | Skalierte Cloud mit Autoscaling |
| Webebene | Gemeinsam mit Datenbank und Cache | Dedizierter Webserver | Mehrere Webknoten + Load Balancer | Automatisch skalierende Webebene |
| Datenbank | Gemeinsam auf einem Server | Dedizierter Datenbankserver | Master/Slave, getrennte Datenbanken | Unabhängig skalierte Serviceebene |
| Cache | Datei oder einfaches Redis | Redis + Varnish | Optimierter Varnish-Cluster | Mehrere Redis-Instanzen + Varnish |
| Typischer Traffic | Bis ca. 100.000 Besucher/Monat | Bis ca. 500.000 Besucher/Monat | 500.000+ Besucher/Monat | Mehrere Millionen Seitenaufrufe/Monat |
Wie Ingold Solutions die Magento-Hosting-Architektur umsetzt
Als Magento-Agentur, die Händler in unterschiedlichen Entwicklungsphasen begleitet, setzt Ingold Solutions auf eine Magento-Hosting-Infrastruktur auf Basis von Microsoft Azure. Die Infrastruktur wird entsprechend der tatsächlichen Anforderungen eines Shops dimensioniert – von Single-Server-Tarifen für bis zu etwa 360.000 Besucher pro Monat bis hin zu vollständig verwalteten Umgebungen mit Varnish- und Redis-Caching, Elasticsearch, NGINX, fortschrittlicher Datenbank-Clusterung, Load Balancing und CDN-Auslieferung für Shops, die über die Möglichkeiten eines einzelnen Servers hinausgewachsen sind. Jeder Managed-Tarif umfasst proaktives Monitoring, stündliche Backups, Disaster-Recovery Planung und eine dokumentierte Netzwerkverfügbarkeitsgarantie von 99,95 %. Dabei wird die Infrastruktur von zertifizierten Ingenieuren betreut und nicht lediglich von einer allgemeinen Support-Warteschlange. Denn die in diesem Leitfaden beschriebenen Architekturentscheidungen funktionieren in der Praxis nur dann zuverlässig, wenn ihre Performance kontinuierlich überwacht wird. Die aktuellen Hosting-Tarife und technischen Spezifikationen finden Sie auf der Seite Microsoft Azure Fully Managed Magento 2 Cloud Hosting. Alternativ können Sie direkt mit dem Team besprechen, welche Architektur zu Ihrem aktuellen und erwarteten Traffic passt.Fazit – Die Architektur sollte zum Shop passen, nicht zum Anspruch
Die beste Magento-Hosting-Architektur ist nicht automatisch die technisch fortschrittlichste Lösung. Sie ist diejenige, die exakt auf den tatsächlichen Traffic, die Wachstumsperspektive und die gewünschte Ausfallsicherheit eines Shops abgestimmt ist. Ein gut optimierter einzelner Server, eine sinnvoll getrennte Multi-Server-Umgebung und eine vollständig verteilte Cloud-Architektur mit automatisch skalierbaren Ebenen sind allesamt sinnvolle Lösungen – abhängig davon, in welcher Entwicklungsphase sich ein Shop tatsächlich befindet. Die richtige Einschätzung zu treffen, anstatt automatisch die technisch beeindruckendste Architektur zu wählen, ist häufig der entscheidende Unterschied zwischen Hosting-Kosten, die wirtschaftlich sinnvoll sind, und einer Infrastruktur, die ein Problem löst, das der Shop in Wirklichkeit noch gar nicht hat.Häufig gestellte Fragen
Eine Magento-Hosting-Architektur beschreibt, wie die Infrastruktur eines Shops – Webserver, Datenbank, Cache und Suchfunktion – aufgebaut und auf Server verteilt wird.
Sie reicht von einem einzelnen Server, auf dem alle Komponenten gemeinsam betrieben werden, über Multi-Server-Umgebungen mit getrennten Ebenen bis hin zu vollständig verteilten Cloud-Architekturen mit unabhängig skalierbaren Ebenen und automatischer Skalierung.
Es gibt keine einzelne Architektur, die für jeden Magento-Shop vorgeschrieben ist. Die passende Lösung hängt von Traffic und Komplexität ab.
Ein korrekt dimensionierter einzelner Server eignet sich für viele kleine und mittelgroße Shops. Wachsende Shops wechseln typischerweise zu getrennten Web- und Datenbankservern. Stark frequentierte und große Shops benötigen häufig eine verteilte Cloud-Architektur mit unabhängig skalierbaren Ebenen.
Nicht unbedingt.
Magento kann auf einem einzelnen, korrekt optimierten Server für eine große Bandbreite an Shop-Größen problemlos betrieben werden.
Mehrere Server werden dann sinnvoll, wenn die gemeinsam genutzten Ressourcen eines einzelnen Systems während normaler Spitzenzeiten die Performance begrenzen. Die Entscheidung sollte also nicht allein deshalb getroffen werden, weil eine Multi-Server-Architektur technisch verfügbar ist.
Eine Multi-Server-Architektur wird typischerweise dann sinnvoll, wenn:
- Antwortzeiten während regulärer Spitzenzeiten schlechter werden
- Datenbank und Webebene unter hoher Last sichtbar um Ressourcen konkurrieren
- Checkout oder Suche während Kampagnen und Verkaufsaktionen langsamer werden
- Die möglichen Kosten von Ausfallzeiten inzwischen höher sind als die zusätzlichen Kosten und die höhere Komplexität einer getrennten Infrastruktur
In solchen Fällen kann die Aufteilung auf dedizierte Ebenen einen deutlichen Performance- und Verfügbarkeitsvorteil bieten.
