Ein Frontend-Generator wirkt bei einem einzelnen Test unkompliziert: Formular absenden, Stripe-Code erzeugen, Datensatz speichern, E-Mail senden. Im echten Betrieb können jedoch mehrere Menschen gleichzeitig klicken, ein Browser kann eine Anfrage wiederholen oder eine Stripe-Antwort kann länger dauern. Anfang Juli wurde deshalb die Absicherung paralleler Anfragen zum nächsten klaren Entwicklungsschwerpunkt. Das Ziel lautet, jeden Partnerwunsch genau einmal zu verarbeiten und den aktuellen Zustand verständlich anzuzeigen.
Das Doppelclick-Problem ist nur der einfachste Fall
Ein Benutzer kann versehentlich zweimal auf den Button klicken. Ebenso können mobile Verbindungen eine Anfrage erneut senden oder ein vorgeschalteter Dienst einen Timeout vermuten. Ohne Sperre könnten zwei Prozesse nahezu gleichzeitig prüfen, dass noch kein Code existiert, und anschließend beide einen neuen Promotion Code anlegen.
Eine reine Deaktivierung des Buttons im Browser reicht nicht. Sie verbessert die Bedienung, schützt aber nicht gegen direkte oder wiederholte Serveranfragen. Die Eindeutigkeit muss deshalb serverseitig abgesichert werden.
Eindeutiger Auftrag vor der Stripe-Anfrage
Die geplante Pipeline erzeugt zuerst einen lokalen Auftrag mit eindeutiger Kennung. E-Mail, Kampagne und normalisierte Partnerdaten bilden den fachlichen Bezug. Für dieselbe Kombination darf nur ein aktiver Erstellungsauftrag bestehen.
Erst danach beginnt die Anfrage an Stripe. Kommt parallel eine zweite Anfrage, erkennt sie den vorhandenen Auftrag und wartet oder liefert den bereits bekannten Status. Dadurch wird die kritische Lücke zwischen Prüfung und Erstellung geschlossen.
Status statt endlosem Ladebild
Ein Auftrag durchläuft Zustände wie angenommen, in Bearbeitung, Stripe-Erstellung, lokale Speicherung, Mailversand, abgeschlossen oder Fehler. Das Frontend kann diese Schritte in verständlicher Form anzeigen. Der Benutzer sieht, ob sein Wunsch angenommen wurde, auch wenn die Verarbeitung etwas länger dauert.
Bei einem Timeout darf der Browser nicht automatisch behaupten, die Erstellung sei gescheitert. Der Auftrag kann serverseitig weiterlaufen. Eine spätere Statusabfrage zeigt, ob der Code inzwischen verfügbar ist. So wird ein zweiter Klick unnötig.
Idempotenz gegenüber Stripe
Auch die externe Anfrage braucht einen eindeutigen Bezug. Soweit der jeweilige Stripe-Vorgang es unterstützt, werden Idempotenzschlüssel verwendet. Sie sorgen dafür, dass eine wiederholte technisch gleiche Anforderung nicht mehrfach ausgeführt wird.
Zusätzlich speichert die Suite Stripe-ID und sichtbaren Code unmittelbar nach erfolgreicher Antwort. Fällt danach der Mailversand aus, wird nicht erneut ein Code erzeugt. Stattdessen kann die vorhandene Nachricht später erneut versandt werden.
Queue-Verarbeitung bei hoher Last
Bei sehr vielen gleichzeitigen Anfragen sollen nicht alle Prozesse ungebremst parallel auf Stripe zugreifen. Eine Queue verarbeitet Aufträge in kontrollierten Paketen. Das schützt Serverressourcen, respektiert API-Grenzen und macht Fortschritt messbar.
Für den Benutzer kann eine Position oder eine vereinfachte Warteanzeige ausgegeben werden. Entscheidend ist nicht eine sekundengenaue Prognose, sondern die Gewissheit, dass der Auftrag gespeichert ist. Der Betreiber sieht Queue-Länge, ältesten Auftrag und mögliche Blockaden.
Fehler dürfen keinen unklaren Datensatz hinterlassen
Ein Fehler kann vor, während oder nach der Stripe-Erstellung auftreten. Die Pipeline muss unterscheiden, ob noch kein Code existiert, ob Stripe bereits einen Code geliefert hat oder ob nur die lokale Nachbearbeitung fehlt. Ein pauschales „erneut versuchen“ wäre gefährlich.
Fehlerdatensätze erhalten deshalb Prozessstufe, Zeitstempel und erneute Prüfoption. Ein Administrator kann gezielt fortsetzen, erneut synchronisieren oder einen unvollständigen Auftrag archivieren. Bereits vorhandene Stripe-Codes werden zuerst gesucht, bevor eine neue Erstellung erlaubt wird.
Cron als verlässlicher Hintergrundmotor
Nicht jeder WordPress-Aufruf eignet sich für längere Queue-Arbeit. WP-Cron kann kleine Installationen unterstützen, hängt aber vom Website-Verkehr ab. Für zuverlässige Verarbeitung wird ein echter Server-Cron empfohlen. Die Hilfe trennt dabei Hosting-Panel, Linux-Crontab, externe Cron-Dienste und WP-CLI.
Der Betreiber erhält pro Variante passende Felder und Tests. Eine Abschaltung des normalen WP-Cron ist nur sinnvoll, wenn der Server-Cron nachweislich funktioniert. So wird die technische Empfehlung an den tatsächlichen Betrieb geknüpft.
Planung für hundert gleichzeitige Klicks
Ein Lastszenario mit hundert Anfragen bedeutet nicht, dass hundert Codes in derselben Millisekunde entstehen müssen. Entscheidend ist, dass jede Anfrage eine eindeutige Bestätigung erhält, keine verloren geht und der Server nicht überlastet wird. Die Queue darf Aufträge in kontrollierter Reihenfolge verarbeiten.
Für Betreiber werden Grenzwerte, Batchgröße und Laufzeit sichtbar. Bleibt ein Auftrag ungewöhnlich lange stehen, kann er geprüft werden. Damit wird Skalierbarkeit nicht als abstrakte Zahl behandelt, sondern als beobachtbarer Zustand mit klaren Eingriffsmöglichkeiten.
Recovery statt Neustart
Bleibt ein Auftrag hängen, soll der Administrator ihn nicht löschen und neu beginnen müssen. Eine Wiederaufnahme startet an der letzten sicher bestätigten Stufe. Wurde der Stripe-Code bereits erzeugt, folgen nur lokale Speicherung oder Mailversand. Dieses Recovery-Prinzip senkt das Risiko von Duplikaten und macht Fehlerbehebung schneller, weil der tatsächliche Prozesszustand erhalten bleibt.
Metriken für den Betrieb
Queue-Durchsatz, durchschnittliche Wartezeit und Zahl fehlgeschlagener Aufträge helfen, Engpässe zu erkennen. Die Werte dienen der Diagnose und werden nicht als Erfolgsversprechen dargestellt.
Die Generator-Pipeline ist kein sichtbares Zusatzfeature, sondern eine Voraussetzung für Vertrauen. Ein persönlicher Code darf weder durch hektische Klicks noch durch langsame Antworten doppelt entstehen. Die geplante Verarbeitung macht aus einer einzelnen Formularaktion einen kontrollierten, wiederaufnehmbaren Auftrag.
