Der Anruf kam um 9:47 Uhr am Black Friday. Ein belgischer Modehändler hatte die größte Aktion des Jahres gestartet, getragen von wochenlangen E-Mail-Kampagnen, Influencer-Kooperationen und bezahlter Werbung. Der Traffic stieg genau wie geplant — und sein PrestaShop-Shop stürzte vollständig ab, noch in der ersten Stunde. Kunden, die auf sorgfältig gestaltete Anzeigen klickten, landeten auf Fehlerseiten statt bei den zeitlich begrenzten Angeboten, die ihnen versprochen worden waren. Die Website erholte sich kurz, lieferte eine Handvoll Seiten und brach erneut zusammen, sobald die wartenden Anfragen die gerade frei gewordene Kapazität überliefen. Als er uns anrief, waren bereits über €40.000 an prognostiziertem Umsatz verloren, und die umsatzstärksten Einkaufsstunden des Jahres liefen davon. Der Hosting-Anbieter beharrte darauf, die Server seien in Ordnung. Der bisherige Entwickler ging nicht ans Telefon. Die Marketinginvestition verpuffte in Echtzeit.

→ Performance-Notfall? Unser Team reagiert sofort

Die geschilderten Symptome deuteten auf einen Ausfall in der Datenbankschicht hin: das typische Muster aus kurzer Erholung und erneutem Zusammenbruch, das auf erschöpfte Verbindungen hinweist, nicht auf eine bloße Sättigung der Ressourcen. Bei normalem Traffic trug die MySQL-Konfiguration die überschaubare Zahl gleichzeitiger Nutzer problemlos. Doch der Traffic am Black Friday vervielfachte die gleichzeitigen Besucher um den Faktor fünfzig, und jeder Besucher löste mehrere Datenbankabfragen für Produkte, den Warenkorb und die Sitzung aus. Das eingestellte Limit von einhundertfünfzig gleichzeitigen Verbindungen hatte in den Planungsgesprächen mit dem bisherigen Entwickler großzügig gewirkt. Unter der echten Feiertagslast war es wenige Minuten nach jeder Erholung aufgebraucht. So entstand ein Kreislauf: Die Datenbank nahm Verbindungen kurz an, war sofort gesättigt und lehnte neue Anfragen ab, bis laufende Verbindungen per Timeout geschlossen wurden und wieder Platz frei wurde.

Die Hosting-Umgebung verschärfte das Problem und verlängerte die Behebung. Er hatte einen Managed-Hosting-Anbieter gerade wegen der bequemen Einfachheit gewählt. Diese Einfachheit bedeutete keinen SSH-Zugang, keine Möglichkeit, die MySQL-Konfiguration direkt zu ändern, und Antwortzeiten des Supports, die sich in Stunden maßen, während der Anbieter selbst am Black Friday unter Anfragen stand. Die PrestaShop-Performance-Einstellungen, die wir über die Admin-Konfiguration anpassen konnten — Caching, Kompilierung, Debug-Modus — waren bereits korrekt gesetzt. Die Datenbank selbst war ordentlich optimiert; der bisherige Entwickler hatte die üblichen Aufräumroutinen eingerichtet. Das Problem saß in der Infrastrukturschicht, in Einstellungen, die die Hosting-Umgebung bewusst vor Änderungen sperrte.

→ Entdecken Sie Infrastrukturgrenzen nicht erst am Black Friday

Unser Notfalleingriff erfolgte auf zwei parallelen Wegen. Zunächst implementierten wir umgehend ein Traffic-Management, um die Datenbanklast zu reduzieren und gleichzeitig die Verkaufskapazität so weit wie möglich aufrechtzuerhalten. Statische Versionen wichtiger Produktseiten wurden auf CDN-Edge-Servern bereitgestellt, sodass Kunden wichtige Aktionsartikel durchstöbern konnten, obwohl die dynamischen Funktionen eingeschränkt waren. Warenkorb- und Checkout-Funktionen wurden priorisiert, indem die begrenzten Datenbankverbindungen auf konversionskritische Vorgänge und nicht auf das Durchsuchen der Seiten umgeleitet wurden. Administratorvorgänge wurden vollständig blockiert, um zu verhindern, dass Mitarbeiteraktivitäten die für Kundenkäufe benötigten Verbindungen belegten. Dank dieser Maßnahmen konnte der Shop mit reduzierter Kapazität weiterlaufen – alles andere als optimal, aber immerhin wurden Umsätze generiert, anstatt nur Fehler zu verursachen.

Der zweite Ansatzpunkt war die Behebung der Ursachen durch eine Eskalation der Infrastruktur. In Zusammenarbeit mit dem Notfallteam des Hosting-Anbieters konnten wir temporäre Konfigurationsänderungen aushandeln, die die maximale Anzahl an Datenbankverbindungen und PHP-Prozessen über die standardmäßigen Grenzwerte hinaus erhöhten. Die Speicherzuweisung für PHP-Prozesse wurde erweitert, um die Speichererschöpfung zu verhindern, die zu den Folgeausfällen geführt hatte. Am frühen Nachmittag – etwa vier Stunden nach dem ersten Ausfall – hatte sich der Shop wieder stabilisiert und lief wieder voll. Die Infrastruktur war vorübergehend umkonfiguriert worden, um den durch die Werbeaktion verursachten Traffic zu bewältigen. Der Umsatz stieg wieder an und erreichte zwar ein niedrigeres Niveau als im regulären Tagesbetrieb, konnte aber dennoch einen erheblichen Teil der zuvor befürchteten Verluste wieder wettmachen.

Die Nachbetrachtung zeigte eine Infrastruktur, die nie richtig auf den Traffic ausgelegt war, den das Marketing erzeugen konnte. Das PrestaShop-Hosting hatte für den normalen Tagesbetrieb und moderate Aktionspeaks gereicht. Große Kampagnen ruhten jedoch auf Kapazitätsannahmen, die niemand mit einem Lasttest geprüft hatte. Das Verbindungslimit der Datenbank von einhundertfünfzig trug bei diesem Abfragemuster grob einhundert gleichzeitige Besucher — weit unter den Tausenden, die eine gelungene Kampagne am Black Friday anzieht. Der Arbeitsspeicher des Hosting-Tarifs konnte die Zahl der PHP-Worker nicht tragen, die hohe Gleichzeitigkeit braucht. Diese Grenzen blieben im Alltag unsichtbar und schlugen erst dann katastrophal durch, als das Marketing genau in der Größenordnung Erfolg hatte, auf die es hingearbeitet hatte.

Die Lösung für die folgenden Saisons beseitigte diese Schwachstellen mit einer Architektur für die Spitzenlast, nicht nur für den Normalbetrieb. Die Datenbank zog auf ein dediziertes MySQL-Hosting um, mit Verbindungslimits, die zu den Traffic-Zielen passten. Die Webserver liefen hinter einem Load Balancing, das sich in Aktionszeiten horizontal skalieren ließ. Redis-Caching senkte die Zahl der Datenbankabfragen um achtzig Prozent und erweiterte die nutzbare Kapazität deutlich. Lasttests bestätigten, dass die neue Architektur zehntausend gleichzeitige Nutzer ohne Einbruch trug — genug, um auch außergewöhnlich erfolgreiche Aktionen aufzufangen, ohne dass die Infrastruktur zum begrenzenden Faktor wird.

Ist Ihr Geschäft bereit für die nächste große Chance?

Die €40.000 an verlorenen Umsätzen am Black Friday dieses Händlers sind nur der direkt messbare Schaden: der Umsatz der Besucher, die in den ausgefallenen Stunden kaufen wollten. Nicht gemessen bleiben beschädigte Kundenbeziehungen durch Fehlerseiten, der Ruf der Marke nach Beschwerden in den sozialen Medien und Werbebudget, das für Traffic verbrannt wurde, der Fehlermeldungen statt eines Einkaufs bekam. Jeder PrestaShop-Shop, der größere Aktionen plant, trägt dasselbe Risiko, solange die Infrastruktur nicht gegen den erwarteten Spitzentraffic geprüft ist. Die Frage ist nicht, ob es Ihnen gelingt, Traffic zu holen — Ihr Marketing arbeitet genau darauf hin. Die Frage ist, ob Ihre Infrastruktur diesen Traffic in Umsatz verwandelt oder in eine Fallstudie darüber, was schiefgeht, wenn die Vorbereitung nicht zur Ambition passt.

→ Prüfen Sie Ihre Infrastruktur vor der nächsten Kampagne