Mit der rasanten Verbreitung autonomer KI-Einkaufsagenten, darunter Systeme auf Basis von Claude Computer Use, OpenAI Operator sowie automatisierte B2B-Beschaffungssoftware, steht die technische Infrastruktur moderner Onlineshops vor neuen Leistungsanforderungen. Während menschliche Kunden mehrere Minuten durch Kataloge navigieren und den Bestellprozess schrittweise durchlaufen, analysieren KI-Agenten Spezifikationen, wählen Anbieter und senden Checkout-Payloads in wenigen Millisekunden. Bei Rabattaktionen, limitierten Produkteinführungen oder Rohstoffpreisschwankungen treffen hunderte automatisierte Anfragen gleichzeitig auf die Kassenendpunkte von WooCommerce.
Die traditionelle WooCommerce-Architektur, die historisch für sequenziellen menschlichen Datenverkehr konzipiert wurde, stößt bei solch hoher Parallelität schnell an ihre Grenzen. Wenn ein Shopsystem bei Bestandsaktualisierungen ausschließlich auf zeilenbasierte MySQL-Transaktionen innerhalb synchroner PHP-FPM-Prozesse setzt, entstehen unweigerlich Deadlocks, Verbindungsabbrüche und Überverkäufe (Overselling): ein kritischer Zustand, bei dem identische physische Lagerbestände zeitgleich an mehrere Käufer veräußert werden.
Herausforderungen der Nebenläufigkeit und Race Conditions in WordPress
Ein Parallelitätskonflikt (Race Condition) tritt auf, sobald zwei oder mehr voneinander unabhängige Prozesse denselben Datensatz zur gleichen Zeit lesen und manipulieren. Betrachten wir ein typisches B2B-Szenario, in dem ein hochpreisiger Industrie-Wechselrichter mit einem verbleibenden Lagerbestand von genau 1 Stück geführt wird und zwei autonome Beschaffungsagenten ihre Bestellungen im Abstand von 5 Millisekunden absenden:
- Thread A (Agent 1) liest den aktuellen Bestand ab:
SELECT stock_quantity FROM wp_wc_product_meta_lookup WHERE product_id = 4520;und erhält den Wert 1. - Thread B (Agent 2) führt nahezu zeitgleich dieselbe Abfrage aus und erhält ebenfalls den Wert 1, da Thread A seine Transaktion noch nicht auf der Festplatte festgeschrieben hat.
- Thread A zieht 1 Stück ab, setzt den Bestand auf 0 und erzeugt den Bestelleintrag.
- Thread B zieht basierend auf seinem vorherigen Lesewert ebenfalls 1 Stück ab (oft mit dem Ergebnis 0 oder -1) und bestätigt den zweiten Kaufvertrag.
Beide Agenten erhalten eine erfolgreiche HTTP-200-Rückmeldung und Zahlungsbestätigung, obwohl das Lager physisch nur über ein einziges Exemplar verfügt. Im B2B-Segment, wo Einzelbestellungen häufig fünfstellige Euro-Beträge umfassen, führt ein solcher Überverkauf zu Vertragsstrafen, Lieferverzögerungen und gravierendem Vertrauensverlust bei Handelspartnern.
Wird zusätzlich ein externes ERP-System (wie SAP, Microsoft Dynamics 365 oder branchenspezifische Warenwirtschaften) angebunden, potenzieren sich die Fehlerquellen. Fehlen verteilte Sperren und transaktionale Schutzmechanismen, weichen die realen Bestände im Lager sofort von den digitalen Beständen im Shop ab. Unsere bewährten Konzepte für belastbare Unternehmensintegrationen finden Sie unter /de/woocommerce-erp-integration/.
Pessimistische versus optimistische Sperren in MySQL
Im relationalen Datenbankdesign existieren zwei grundlegende Strategien zur Steuerung von Nebenläufigkeit: pessimistische und optimistische Sperren.
Pessimistische Sperren (pessimistic locking)
Das pessimistische Verfahren geht davon aus, dass Datenkonflikte unter hoher Last unvermeidlich sind. In der MySQL InnoDB-Engine wird dies über die Klauseln SELECT ... FOR UPDATE oder LOCK IN SHARE MODE gesteuert. Liest Thread A einen Datensatz, sperrt die Datenbank die entsprechende Indexzeile exklusiv:
START TRANSACTION;
-- Bestand abfragen und exklusive Zeilensperre anfordern
SELECT stock_quantity
FROM wp_wc_product_meta_lookup
WHERE product_id = 4520
FOR UPDATE;
-- Geschaeftslogik in PHP: Pruefen, ob stock_quantity >= gewuenschte Menge
UPDATE wp_wc_product_meta_lookup
SET stock_quantity = stock_quantity - 1
WHERE product_id = 4520;
COMMIT;Bis Thread A die Transaktion per COMMIT abschließt oder per ROLLBACK abbricht, müssen alle anderen Threads, die dieselbe Zeile über FOR UPDATE anfordern, in einer Warteschlange verharren.
Vorteile der pessimistischen Sperre:
- Absolute Datenkonsistenz innerhalb einer einzelnen SQL-Instanz.
- Zuverlässiger Schutz vor Überverkäufen bei korrekt aufgebauten ACID-Transaktionen.
Nachteile der pessimistischen Sperre:
- Drastischer Einbruch des Gesamtdurchsatzes bei plötzlichen Lastspitzen.
- Hohe Anfälligkeit für Deadlocks, wenn Warenkörbe mehrere Artikel in unterschiedlicher Reihenfolge sperren.
- Überschreitung des Zeitlimits
innodb_lock_wait_timeout, was zu HTTP-504-Fehlern führt.
Optimistische Sperren (optimistic locking)
Das optimistische Verfahren setzt voraus, dass Konflikte eher selten auftreten. Statt Datensätze während der Verarbeitung zu sperren, wird die Tabelle um eine Versionsnummer (version_id oder ein Zeitstempel) erweitert. Beim finalen Schreibvorgang prüft die Abfrage, ob sich die Version seit dem Lesevorgang verändert hat:
-- Schritt 1: Lesevorgang ohne Datenbanksperre
SELECT stock_quantity, version_id
FROM wp_wc_product_inventory_state
WHERE product_id = 4520;
-- Rueckgabe: stock_quantity = 1, version_id = 84
-- Schritt 2: Bedingte Aktualisierung
UPDATE wp_wc_product_inventory_state
SET stock_quantity = stock_quantity - 1,
version_id = version_id + 1
WHERE product_id = 4520 AND version_id = 84;Wurde der Datensatz zwischenzeitlich von einem anderen Prozess manipuliert (womit version_id auf 85 anstieg), liefert das UPDATE genau 0 betroffene Zeilen (rows affected = 0). Die PHP-Anwendung erkennt die Kollision, bricht die Transaktion ab und fordert den KI-Agenten auf, den Vorgang zu wiederholen oder abzubrechen.
Die Tabelle wp_wc_product_inventory_state in diesem Beispiel ist eine eigene Tabelle für dieses Muster und gehört nicht zum WooCommerce-Kern.
Bei extremen Flash Sales oder massiven Bot-Wellen führt optimistisches Sperren jedoch zu Kaskaden abgelehnter Buchungen (Retry Storms), die Server-CPU und Netzwerkkapazitäten überlasten.
Verteilte Bestandssperren mit Redis und dem Redlock-Algorithmus
Um tausende parallele Transaktionsanfragen von KI-Agenten pro Sekunde abzufangen, ist die Verlagerung von Bestandssperren in relationale MySQL-Tabellen der falsche Weg. Skalierbare E-Commerce-Plattformen entkoppeln die Reservierungslogik von der Hauptdatenbank und nutzen einen schnellen In-Memory-Redis-Cluster.
Die Klasse unten nutzt das Einzelinstanz-Muster aus der Redis-Dokumentation: SET schluessel wert NX PX ttl mit einem Wert, der für jede Sperranfrage eindeutig ist. Freigegeben wird über ein Lua-Skript, das den Schlüssel nur löscht, wenn er noch genau diesen Wert enthält. Redlock ist die Erweiterung dieser Idee auf mehrere Knoten. Die Redis-Dokumentation beschreibt es mit N unabhängigen Mastern (ihr Beispiel nutzt N=5); eine Sperre gilt erst als erworben, wenn der Client sie innerhalb der Gültigkeitsdauer auf einer Mehrheit (N/2+1) setzen konnte. Dieselbe Seite warnt, dass Redis für den TTL-Ablauf keine monotone Uhr verwendet, und empfiehlt Fencing Tokens für lange Operationen (Redis: distributed locks). Für einen Bestandszähler heißt das: Die Sperre allein garantiert keine Korrektheit, was das Unterschreiten von null verhindert, ist das bedingte Dekrement weiter unten. Die folgende PHP-Klasse setzt das um:
<?php
/**
* Manager fuer verteilte Bestandssperren mit Redis in WooCommerce
*/
declare(strict_types=1);
namespace WPPoland\InventoryConcurrencyDE;
final class RedisInventoryLockManager
{
private \Redis $redis;
private int $lockTtlMilliseconds;
public function __construct(\Redis $redis, int $lockTtlMilliseconds = 5000)
{
$this->redis = $redis;
$this->lockTtlMilliseconds = $lockTtlMilliseconds;
}
/**
* Atomare Reservierungssperre fuer ein Produkt anfordern
*/
public function acquireLock(int $productId, string $token): bool
{
$lockKey = sprintf('lock:inventory:product:%d', $productId);
// NX: nur setzen wenn nicht existent; PX: Ablaufzeit in Millisekunden
$acquired = $this->redis->set($lockKey, $token, ['NX', 'PX' => $this->lockTtlMilliseconds]);
return $acquired === true;
}
/**
* Sicheres Freigeben der Sperre ueber ein atomares Lua-Skript
* Verhindert das versehentliche Loeschen fremder Sperren nach TTL-Ablauf
*/
public function releaseLock(int $productId, string $token): bool
{
$lockKey = sprintf('lock:inventory:product:%d', $productId);
$luaScript = <<<LUA
if redis.call("get", KEYS[1]) == ARGV[1] then
return redis.call("del", KEYS[1])
else
return 0
end
LUA;
$result = $this->redis->eval($luaScript, [$lockKey, $token], 1);
return $result === 1;
}
/**
* Atomare Bestandsreduzierung direkt im Redis-Arbeitsspeicher
*/
public function decrementInventory(int $productId, int $quantity): int
{
$stockKey = sprintf('inventory:stock:product:%d', $productId);
$luaScript = <<<LUA
local currentStock = tonumber(redis.call("get", KEYS[1]) or "0")
local decrementAmount = tonumber(ARGV[1])
if currentStock >= decrementAmount then
local newStock = redis.call("decrby", KEYS[1], decrementAmount)
return newStock
else
return -1
end
LUA;
$newStock = (int) $this->redis->eval($luaScript, [$stockKey, $quantity], 1);
return $newStock;
}
}Redis garantiert die atomare Ausführung eines Lua-Skripts: Solange das Skript läuft, ist jede andere Serveraktivität blockiert, seine Effekte sind also entweder noch gar nicht oder bereits vollständig eingetreten (Redis: scripting with Lua). Da Bestandsprüfung und DECRBY im selben Skript stehen, können zwei gleichzeitige Agenten die Prüfung auf die letzte Einheit nicht beide bestehen. Die Kehrseite dieser Garantie: Ein langsames Skript hält alle anderen Clients der Instanz an. Ein Grund mehr, Bestandsskripte kurz zu halten und auf einer eigenen Redis-Instanz getrennt vom Objekt-Cache zu betreiben. Erst nach erfolgreicher In-Memory-Reservierung aktualisiert ein asynchroner Hintergrunddienst die MySQL-Tabellen und meldet die Änderung an das ERP.
Auswirkungen von WooCommerce HPOS auf die Transaktionsleistung
Über ein Jahrzehnt hinweg speicherte WooCommerce alle Bestelldaten in den allgemeinen WordPress-Tabellen wp_posts und wp_postmeta. In Onlineshops mit tausenden Bestellungen pro Tag wuchs wp_postmeta auf zig Millionen Zeilen an. Jeder einzelne Kassiervorgang feuerte dutzende INSERT-Befehle in dieselbe Tabelle, fragmentierte Datenbankindizes und verlängerte die Transaktionsdauer drastisch.
Die Einführung von High-Performance Order Storage (HPOS) stellt einen wesentlichen Entwicklungsschritt dar:
- Dedizierte transaktionale Tabellen: Bestelldaten wandern in spezialisierte Tabellen (
wp_wc_orders,wp_wc_order_addresses,wp_wc_order_operational_data), wodurch Kassiervorgänge vollständig von Beitrags- und Seitentabellen getrennt werden. - Normalisierte relationale Spalten: Kernattribute wie Status, Gesamtsumme, Kunden-ID und Währung liegen in indizierten Spalten statt in unstrukturierten Meta-Keys.
- Umfang und Status: Die WooCommerce-Entwicklerdokumentation nennt keine Latenzwerte für HPOS; sie beschreibt weniger Lese- und Schreiboperationen und weniger stark belastete Tabellen. HPOS ist seit WooCommerce 8.2 (Oktober 2023) stabil und bei Neuinstallationen standardmäßig aktiv, bestehende Shops schalten es manuell ein (WooCommerce: HPOS). Die vier Tabellen heißen
wp_wc_orders,wp_wc_order_addresses,wp_wc_order_operational_dataundwp_wc_orders_meta. HPOS speichert Bestellungen. Lagerbestand und Preise der Produkte bleiben in den Produktdaten, HPOS verkürzt also das Schreiben von Bestellungen, serialisiert aber Bestandsabbuchungen nicht von selbst.
Das folgende Diagramm zeigt den Datenfluss in einer modernen High-Concurrency-Architektur:
+------------------------------------+
| Autonome KI-Einkaufsagenten |
| (Claude, GPT-4o, B2B-Systeme) |
+------------------------------------+
|
v (Parallele HTTPS-Checkout-Anfragen)
+------------------------------------+
| Cloudflare Edge / Nginx Proxy |
| Rate Limiting & WAF-Filter |
+------------------------------------+
|
v
+------------------------------------+
| Redis Locking & State Layer | <--- Atomares Lua-Skript (Redlock)
| (Reservierung im Arbeitsspeicher) | Verhindert Ueberverkaeufe
+------------------------------------+
|
v (Nur bei bestaetigter In-Memory-Reservierung)
+------------------------------------+
| WooCommerce HPOS Tabellen |
| (wp_wc_orders, ACID-Transaktion) |
+------------------------------------+
|
v (Asynchrone Message-Queue: RabbitMQ / Kafka)
+------------------------------------+
| ERP & Lagerverwaltung |
| (SAP, Microsoft Dynamics, Subiekt) |
+------------------------------------+Um die Robustheit Ihrer Codebasis gegen unberechtigte Bot-Zugriffe und Race-Condition-Exploits zu überprüfen, empfehlen wir ein professionelles Sicherheitsaudit gemäß den Richtlinien unter /de/sicherheitsaudit-wordpress/.
Wie WooCommerce-Lagerbestand im Checkout ohne zusätzlichen Code reserviert
Bevor Redis ins Spiel kommt, lohnt sich ein Blick auf das, was der Kern bereits leistet. Unter WooCommerce > Einstellungen > Produkte > Lagerbestand schaltet „Lagerverwaltung“ die Mengenverfolgung ein, und „Ware reservieren (Minuten)“ hält Bestand für unbezahlte Bestellungen zurück. Laut Dokumentation gilt die Reservierung für Bestellungen im Status „Bezahlung ausstehend“, nicht für „In Wartestellung“. Läuft die Zeit ab, wird die Bestellung storniert und der Bestand fließt ins Lager zurück; ein leeres Feld schaltet die Reservierung ab (WooCommerce: Produkteinstellungen).
Der blockbasierte Checkout bringt einen zweiten Zustand mit. Bestellungen im Status „Entwurf“ sind temporäre Datensätze, die der Block-Checkout anlegt, bevor die Bestellung abgeschickt wird, und laut Dokumentation der Bestellstatus bleibt der Bestand reserviert, solange eine Bestellung im Status „Entwurf“ oder „Bezahlung ausstehend“ steht. Eine täglich geplante Bereinigung löscht Entwürfe, die nicht mehr aktiv sind. Wurde der Bestand für eine Bestellung bereits reduziert und wechselt sie später auf „Fehlgeschlagen“, bucht WooCommerce ihn ins Lager zurück (WooCommerce: Bestellstatus).
Bei Agenten-Traffic wirkt sich das auf zwei Arten aus. Ein Agent, der viele Checkouts öffnet und abbricht, bindet Einheiten für das gesamte Reservierungsfenster. Der Wert von „Ware reservieren (Minuten)“ ist deshalb eine geschäftliche Entscheidung und kein Standardwert, den man unbesehen stehen lässt. Und der „Schwellenwert für ‚nicht vorrätig‘“ legt fest, ab welcher Menge ein Produkt als nicht vorrätig gilt; genau diesen Wert sollten strukturierte Daten und jeder Feed für Agenten abbilden.
Wie man Checkout-Anfragen von Agenten in der WooCommerce Store API begrenzt
Agenten, die keinen Browser steuern, sprechen in der Regel mit der Store API, der öffentlichen REST-Schicht hinter den Warenkorb- und Checkout-Blöcken. Ihre Routen liegen im Namespace wc/store/v1; die API verlangt keine Authentifizierung und gibt laut Dokumentation keinen Zugriff auf sensible Shopdaten oder Informationen anderer Kunden (WooCommerce: Store API). Alle Checkout-Endpunkte verlangen einen Nonce Token oder einen Cart Token. GET /wc/store/v1/checkout liefert eine aus dem aktuellen Warenkorb erzeugte Entwurfsbestellung mit dem Status checkout-draft, und POST /wc/store/v1/checkout verarbeitet Bestellung und Zahlung (WooCommerce: Checkout API).
Die Store API bringt eine Ratenbegrenzung mit, die standardmäßig deaktiviert ist. Nach dem Einschalten erlaubt die Standardkonfiguration 25 Anfragen in einem Fenster von 10 Sekunden, gilt nur für POST-Anfragen und liefert die Header RateLimit-Limit, RateLimit-Remaining und RateLimit-Reset, dazu RateLimit-Retry-After, sobald das Limit erreicht ist (WooCommerce: Store API rate limiting):
add_filter( 'woocommerce_store_api_rate_limit_options', function () {
return [
'enabled' => true,
'proxy_support' => false, // true nur hinter einem Proxy unter eigener Kontrolle
'limit' => 25,
'seconds' => 10,
];
} );Mit aktivem proxy_support erkennt der Limiter den Client an der IP aus Weiterleitungs-Headern wie X-Forwarded-For. Aktivieren Sie die Option nur, wenn die Website hinter einem Proxy steht, den Sie kontrollieren, denn diese Header setzt derjenige, der die Anfrage sendet. Begrenzung am Edge (Cloudflare oder Nginx) und der Limiter der Store API ergänzen sich: Der Edge fängt Lastwellen ab, die Store API begrenzt, was jeder einzelne Client bis zu PHP durchbringt.
Idempotenzschlüssel bei der Kommunikation mit ERP-Systemen
In verteilten Systemen mit automatisierten Schnittstellen sind temporäre Netzwerkabbrüche an der Tagesordnung. Wenn ein autonomer KI-Einkaufsagent nach dem Absenden einer Kaufanfrage innerhalb von 3000 ms keine Bestätigung erhält, löst er automatisiert einen Wiederholungsversuch (Retry) aus. Ohne serverseitigen Idempotenzschutz erzeugt dieser Folgeversuch eine Doppelbestellung und belastet den Lagerbestand zweifach.
Die architektonische Lösung besteht in der Durchsetzung von Idempotenzschlüsseln in HTTP-Headern (z. B. Idempotency-Key: c94b21e8-7a12-4f3d-99e2-881b23c4a5f0).
Nachfolgend ein Middleware-Muster für die WordPress REST API:
<?php
/**
* Idempotenz-Middleware fuer automatisierte KI-Kaufanfragen in WordPress
*/
declare(strict_types=1);
namespace WPPoland\ApiGovernanceDE;
final class IdempotencyGuard
{
private \Redis $redis;
public function __construct(\Redis $redis)
{
$this->redis = $redis;
}
public function processRequest(\WP_REST_Request $request): ?\WP_REST_Response
{
$idempotencyKey = $request->get_header('Idempotency-Key');
if (empty($idempotencyKey)) {
return new \WP_REST_Response([
'error' => 'missing_idempotency_key',
'message' => 'Anfragen automatisierter Einkaufsagenten erfordern einen Idempotency-Key Header.'
], 400);
}
$redisKey = sprintf('idempotency:%s', hash('sha256', $idempotencyKey));
$existingState = $this->redis->get($redisKey);
if ($existingState !== false) {
$data = json_decode((string) $existingState, true);
if ($data['status'] === 'processing') {
return new \WP_REST_Response([
'error' => 'request_in_progress',
'message' => 'Die Transaktion wird aktuell verarbeitet. Bitte warten.'
], 409);
}
// Zwischengespeicherte Antwort zurueckgeben ohne erneute Lagerabbuchung
return new \WP_REST_Response($data['response_body'], (int) $data['response_code']);
}
// Status auf 'processing' setzen mit 120 Sekunden TTL
$this->redis->set($redisKey, json_encode(['status' => 'processing']), ['EX' => 120]);
return null;
}
public function finalizeRequest(string $idempotencyKey, array $responseBody, int $responseCode): void
{
$redisKey = sprintf('idempotency:%s', hash('sha256', $idempotencyKey));
$payload = [
'status' => 'completed',
'response_body' => $responseBody,
'response_code' => $responseCode
];
// Antwort fuer 24 Stunden speichern
$this->redis->set($redisKey, json_encode($payload), ['EX' => 86400]);
}
}Die Anwendung von Idempotenzschlüsseln schützt auch die asynchrone Schnittstelle zum ERP. Wiederholte Netzwerkpakete führen dadurch weder zu falschen Bestandsbuchungen noch zu doppelten Lieferscheinen.
Idempotency-Key in agentischen Checkout-Protokollen ACP und UCP
Das oben beschriebene Idempotenzmuster ist keine Hauskonvention; agentische Checkout-Spezifikationen verlangen es. Die Agentic Checkout Spec von OpenAI definiert fünf Endpunkte auf Händlerseite (POST /checkout_sessions, POST /checkout_sessions/{checkout_session_id}, POST .../complete, POST .../cancel und GET /checkout_sessions/{checkout_session_id}) und führt Idempotency-Key unter den Headern auf, die bei jedem Aufruf mitgesendet werden, neben Request-Id, Signature, Timestamp und API-Version. Eine Session durchläuft die Status not_ready_for_payment, ready_for_payment, completed und canceled (OpenAI: Agentic Checkout Spec).
Die REST-Bindung des Universal Commerce Protocol (Version 2026-04-08) wird beim Serververhalten deutlicher. Zustandsändernde Operationen sollen Idempotenz unterstützen (SHOULD). Wird ein Schlüssel mitgesendet, muss der Server (MUST) ihn mindestens 24 Stunden lang zusammen mit dem Ergebnis der Operation speichern, für Duplikate mit identischem Body das gespeicherte Ergebnis zurückgeben und mit 409 Conflict antworten, wenn der Schlüssel mit einem abweichenden Body wiederverwendet wird. Die Checkout-Routen sind POST /checkout-sessions, GET und PUT /checkout-sessions/{id} sowie POST .../complete und POST .../cancel (UCP: checkout REST binding).
Für einen WooCommerce-Adapter folgen daraus zwei Dinge. Die oben gezeigte Middleware speichert nur einen Hash des Schlüssels; um die UCP-Regel zu erfüllen, muss sie zusätzlich einen Hash des Request-Bodys ablegen und bei Abweichung 409 zurückgeben. Und die oben zitierten Seiten der Store-API-Dokumentation beschreiben keinen Idempotency-Key-Header. Die Schicht, die ACP- oder UCP-Endpunkte über WooCommerce bereitstellt, muss die Deduplizierung also selbst übernehmen, bevor sie den Checkout aufruft.
Semantische Schema.org-Daten und Echtzeit-Bestandssignale
KI-Agenten treffen Kaufentscheidungen anhand semantischer Metadaten im HTML-Quelltext oder in API-Feeds. Wenn das strukturierte JSON-LD-Schema ein Produkt als lieferbar ausweist (ItemAvailability: https://schema.org/InStock), der reale Lagerbestand jedoch vor wenigen Sekunden auf null gefallen ist, generiert der Bot vergeblich Kaufanfragen.
In modernen Headless-Architekturen sollten Bestandsaktualisierungen über bidirektionale Echtzeitkanäle (wie Server-Sent Events oder WebSockets) verteilt werden, während das JSON-LD-Markup stets den In-Memory-Status abfragt:
<?php
/**
* Dynamisches Schema.org-Markup auf Basis von Redis-Echtzeitbestaenden
*/
declare(strict_types=1);
namespace WPPoland\StructuredDataDE;
final class RealtimeAvailabilitySchema
{
private \Redis $redis;
public function __construct(\Redis $redis)
{
$this->redis = $redis;
add_filter('woocommerce_structured_data_product_offer', [$this, 'injectDynamicAvailability'], 20, 3);
}
public function injectDynamicAvailability(array $offer, \WC_Product $product): array
{
$productId = $product->get_id();
$stockKey = sprintf('inventory:stock:product:%d', $productId);
$realtimeStock = $this->redis->get($stockKey);
$stockCount = $realtimeStock !== false ? (int) $realtimeStock : $product->get_stock_quantity();
if ($stockCount !== null && $stockCount <= 0) {
$offer['availability'] = 'https://schema.org/OutOfStock';
unset($offer['priceValidUntil']);
} elseif ($stockCount !== null && $stockCount < 5) {
$offer['availability'] = 'https://schema.org/LimitedAvailability';
$offer['inventoryLevel'] = [
'@type' => 'QuantitativeValue',
'value' => $stockCount,
'unitCode' => 'C62' // Einheit: Stueck
];
} else {
$offer['availability'] = 'https://schema.org/InStock';
}
return $offer;
}
}Bei entkoppelten Frontend-Lösungen mit Next.js oder Astro lassen sich Bestandsdaten reaktiv streamen, ohne komplette Webseiten neu zu laden. Technische Details zu unseren Entwicklungsansätzen finden Sie unter /de/leistungen/headless-wordpress/.
Technische Checkliste zur Vermeidung von Überverkäufen
Vor dem Start frequenzstarker Verkaufsaktionen oder der Freigabe des Shops für autonome KI-Agenten sollte das Entwicklungsteam folgende Kernbereiche überprüfen:
Datenbank und HPOS-Setup
- Vollständiges Deaktivieren der Synchronisation mit Legacy-Tabellen
wp_postsin den HPOS-Optionen. - Einrichtung von zusammengesetzten Indizes für Transaktionstabellen in MySQL InnoDB.
- Festlegung eines strikten Limits für
innodb_lock_wait_timeout(5 bis 10 Sekunden), um blockierte PHP-FPM-Threads zu verhindern.
- Vollständiges Deaktivieren der Synchronisation mit Legacy-Tabellen
In-Memory-Reservierungsebene (Redis / Redlock)
- Bereitstellung von Redis-Sentinel oder Redis-Cluster mit AOF-Persistenz (Append Only File).
- Atomare Bestandsprüfung via Lua-Skripte mit automatischer Warenkorb-TTL.
- Physische Trennung der Bestands-Redis-Instanz vom allgemeinen WordPress-Objektcache.
Idempotenz und API-Traffic-Kontrolle
- Verpflichtender
Idempotency-Key-Header für alle bestandsverändernden REST- und GraphQL-Endpunkte. - Konfiguration von Rate-Limiting-Regeln in Cloudflare oder Nginx basierend auf Bot-Signaturen.
- Bereitstellung präziser HTTP-429-Statuscodes mit
Retry-After-Headern bei Überlastung.
- Verpflichtender
Asynchrone ERP-Pipeline
- Pufferung von Bestellaufträgen über Message-Broker (RabbitMQ, Apache Kafka oder AWS SQS).
- At-Least-Once-Zustellung mit Deduplizierungsprüfung im Warenwirtschaftssystem.
- Automatisierte nächtliche Abgleichroutinen (Reconciliation Jobs) zur Behebung von Rundungs- oder Bestandsdifferenzen.
Die Vorbereitung von WooCommerce auf autonome KI-Einkaufsagenten erfordert den Übergang von synchronen Monolithen zu verteilten Systemen. Händler, die auf In-Memory-Sperren, Idempotenz und moderne Schnittstellen setzen, schützen ihre Marge und vermeiden kostspielige Lieferprobleme. Für eine detaillierte Architekturanalyse steht Ihnen unser Team unter /de/kontakt/ zur Verfügung.
