Performance-Sanierung
Object-Cache für das LMS, gezielte Datenbank-Indizes auf den Fortschritts- und Lektions-Tabellen, kritische Endpunkte mit reduzierter Plugin-Last. Antwortzeiten unter Last halbiert.
Eine wachsende WordPress-Plattform mit ueber tausendzweihundert aktiven Mitgliedern, achtzig Kursen, Stripe-gebundenen Abonnements und einer LMS-Integration, die unter Last gerne mal stockte. Heute: ein stabiler Stack, ein monatlicher Bericht zur Plattform-Gesundheit, Bereitschaft für jeden Kurs-Launch.
Die Plattform-Inhaberin hatte ihr Coaching-Geschäft in vier Jahren von null auf eine respektable Membership skaliert - aber die Technik dahinter war mehrfach erweitert worden, ohne dass jemand das Gesamtbild kontrollierte. WordPress, ein LMS-Plugin, eine eigene Mitglieder-Lösung, Stripe-Integration, ein Webinar-Plugin obendrauf.
Symptome: bei Kurs-Launches stockte die Plattform, manche Stripe-Webhooks kamen verzögert an, die Mitglieder-Daten waren ueber drei Tabellen verteilt, und der Zertifikat-Download liess seit einem Plugin-Update auf sich warten - jedes Mal ein Support-Ticket der Mitglieder.
Das Team aus zwei Coachees plus virtueller Assistenz hatte nicht die Tiefe, um das technische Hintergrundgerät selbst zu warten. Sie suchten einen Partner, der die Plattform versteht und sie während wichtiger Launches verlässlich begleitet.
Eine produktive Membership-Plattform kann man nicht stilllegen. Wir haben in kleinen, überprüfbaren Schritten saniert.
Object-Cache für das LMS, gezielte Datenbank-Indizes auf den Fortschritts- und Lektions-Tabellen, kritische Endpunkte mit reduzierter Plugin-Last. Antwortzeiten unter Last halbiert.
Webhook-Endpunkte sauber abgesichert, Idempotenz pro Event, automatische Wiedervorlage bei Fehlern. Seitdem keine vermissten Zahlungsbestätigungen mehr.
Die drei verteilten Mitglieder-Datenquellen zusammengeführt, ein einheitliches Dashboard mit Kursfortschritt, Rechnungen und Zertifikat-Download.
Kursfortschritte sind personenbezogene Daten - entsprechende Löschkonzepte, Auskunfts-Routine und ein angepasster AVV für das LMS-Plugin.
Tägliche, redundante Sicherungen inklusive Mitglieder-Datenbank. Halbjährlicher Restore-Test auf Staging, dokumentiert mit Zeitwerten - gemessen, nicht behauptet.
Standard-Vorbereitung für Kurs-Launches: Lasttest auf Staging, Worker-Profile angepasst, Bereitschaftsfenster mit reaktiver Hotline. Nicht erst bei jedem Launch neu erfunden.
Eine Plattform mit zahlenden Mitgliedern und wiederkehrenden Abrechnungen ist nicht wie eine Webseite zu warten - sondern wie ein laufendes Produkt.
Synthetische Prüfungen auf Login, Kurszugriff, Zahlungs-Webhook-Antwortzeiten. Wenn Stripe einmal langsam ist, sehen wir es, bevor der Support es merkt.
Erst auf Staging mit Kurs-Probelauf, dann live ausserhalb der Coaching-Zeiten. Nie ein Update, das wir nicht vorher mit echtem Kurs-Workflow durchgetestet haben.
Verfügbarkeit, durchschnittliche Lade- und Antwortzeiten, Zahlungs-Gesundheit (erfolgreiche vs. fehlgeschlagene Webhooks), Sicherheitsereignisse, gepflegte Updates.
Im Vorfeld eines Launches stimmen wir Worker- und Caching-Profile ab, am Launch-Tag sind wir mit Sichtbarkeit auf die Server-Metriken aktiv ansprechbar. Kein Selbstlauf, sondern Begleitung.
Direkter Draht zwischen Coaching-Team und uns. Tickets für alles, was dokumentiert werden soll.
Was kommt auf die Plattform zu, welche Launches, welche Erweiterungen - gemeinsam priorisiert.
Vorab abgestimmtes Bereitschaftsfenster mit reaktiver Hotline - definiert, nicht improvisiert.
Wartung als Festpreis, Weiterentwicklung als Stundenkontingent - die Plattform wächst, das Modell wächst mit.
Im Oktober 2024 hat die Plattform-Inhaberin einen neuen Kurs gelauncht und am Launch-Tag eine Mail an die gesamte Liste verschickt - rund achttausend Empfänger gleichzeitig. Erwartete Spitze auf der Anmeldeseite: ein Vielfaches der normalen Last.
Zehn Tage vorher haben wir auf Staging einen Lasttest mit synthetischen Anmeldungen gefahren, dabei einen Engpass im Stripe-Webhook-Worker bei sehr hoher Gleichzeitigkeit gefunden, die Worker-Konfiguration angepasst und das Caching-Profil für die Anmeldeseite härter eingestellt. Live-Stand zwei Werktage vor Launch, eingefroren.
Am Launch-Tag haben zwei von uns die Server-Metriken aktiv beobachtet, vier kurze Hot-Fixes in der Konfiguration vorgenommen (zwei davon proaktiv, bevor die Last die kritische Schwelle erreichte), und die Plattform-Inhaberin auf Slack auf dem Laufenden gehalten. Ergebnis: 412 Neuanmeldungen am ersten Tag, null 5xx-Fehler, keine vermissten Zahlungsbestätigungen. Der nächste Launch läuft seitdem nach demselben Muster.
An einem Kurs-Launch-Tag muss ich früher um sieben Themen gleichzeitig denken. Heute: um sechs. Den Server hat jemand anderes im Blick. Das macht einen Unterschied, den man nicht in Geld misst.
Wir kennen die Stolperstellen von LMS, Stripe-Webhooks und Membership-Plugins unter Last. Erstgespräch unverbindlich, mit konkreter Einschätzung Ihres Stacks.