Stellen Sie sich vor, Sie haben noch 1 Einheit eines limitierten Sneakers übrig. Benutzer A ist auf Ihrer Website. Benutzer B ist in Ihrer App. Beide klicken genau in derselben Millisekunde (12:00:00.001) auf „Kaufen“. Shopify erhält zwei Anfragen. Bei unsachgemäßer Handhabung verkauft es den Sneaker doppelt. Sie müssen nun einem Kunden eine E-Mail senden und seine Bestellung stornieren. Das ist eine PR-Katastrophe.

6. Eventuelle Konsistenz (Die 2-Sekunden-Regel)

Ihr Shopify-Administrator sagt „Lagerbestand: 10“. Ihr ERP (NetSuite) sagt „Bestand: 8“. Ihr Lager (WMS) sagt „Bestand: 9“. Wer hat recht? Keiner von ihnen. In einem verteilten System ist Konsistenz eventuell. Wir benötigen eine Single Source of Truth für den „zugewiesenen“ Bestand. Wir verwenden Redis als maßgebliche „Zuordnungstabelle“. Erst nach dem Versand der Bestellung dekrementieren wir den ERP-Wert.

7. Sicherheitsbestandspuffer

„Wenn der Lagerbestand < 5 ist, markieren Sie ihn als „Nicht vorrätig.“ Dies ist eine grobe, aber effektive Strategie für Artikel mit hohem Durchsatz. Wenn Sie 100 Artikel pro Sekunde verkaufen, bedeutet die Latenz der Synchronisierung (200 ms), dass Sie möglicherweise 20 Artikel zu viel verkaufen. Lösung: Dynamischer Sicherheitsbestand. Wenn die Verkaufsgeschwindigkeit > 10/min ist, erhöhen Sie den Sicherheitsbestand auf 10. Wenn die Verkaufsgeschwindigkeit < 1/min ist, reduzieren Sie den Sicherheitspuffer auf 0. Dies maximiert den Durchverkauf und schützt Sie gleichzeitig vor negativen Beständen.

9. Dark Stores und Ship-from-Store

Der Bestand befindet sich nicht nur im Lager. Es ist in den Einzelhandelsgeschäften erhältlich. Wir implementieren Omnichannel Sync. Der „Flagship Store“ in der 5th Ave ist auch „Warehouse #2“. Wenn das Hauptlager OOS ist, prüft das System den Lagerbestand. Es leitet die Bestellung an das Store-iPad weiter. Der Filialmitarbeiter kommissioniert, verpackt und versendet. Dadurch werden 20 % mehr Lagerbestände freigeschaltet, die zuvor in den Regalen „gefangen“ waren.

10. Synchronisierung der Retourenlogistik

Wenn eine Rücksendung eingeleitet wird („/returns“), befindet sich der Artikel technisch gesehen „In Transit“. Es ist nicht „zum Verkauf verfügbar“. Aber wir wissen, dass es zurückkommt. Für stark nachgefragte Artikel können wir Nachbestellungen aktivieren. „Verfügbar in 5 Tagen“ (Erwartete Ankunft der Rücksendung). Wir synchronisieren die Ereignisse des Logistikdienstleisters für Rücksendungen (FedEx Scan), um den Status in Shopify zu aktualisieren. Dadurch werden Einnahmen aus entgangenen Umsätzen ausgeglichen.

11. Fazit: Optimistic Locking & Redis

Wir können uns nicht darauf verlassen, dass die Datenbank einfach „Bestand = 1“ angibt. Wir brauchen eine Distributed Lock.

„Meerjungfrau Sequenzdiagramm Teilnehmer BenutzerA Teilnehmer BenutzerB Teilnehmer Redis Teilnehmer Shopify

BenutzerA->>Redis: SETNX lock:sku_123 1
Redis-->>BenutzerA: OK (Sperre erworben)
BenutzerB->>Redis: SETNX lock:sku_123 1
Redis-->>UserB: FAIL (gesperrt)

BenutzerA->>Shopify: Checkout erstellen
Shopify-->>BenutzerA: Bestellerfolg
BenutzerA->>Redis: DEL lock:sku_123

BenutzerB->>UI: Fehler „Nicht vorrätig“ anzeigen

„

1. Das Reservierungssystem

Wenn ein Benutzer einen Artikel mit hoher Nachfrage in den Warenkorb legt, reservieren wir ihn in Redis für 10 Minuten. „SET Reservierung:sku_123:user_abc EX 600“. Dadurch verringert sich der verfügbare Bestand sofort, noch bevor der Kauf erfolgt. Wenn sie nicht innerhalb von 10 Minuten kaufen, verfällt der Schlüssel und die Aktien fließen zurück in den Pool.

Webhooks für die Synchronisierung

Wenn eine Bestellung tatsächlich erfolgt, müssen wir Amazon und TikTok sofort informieren. Der Webhook „INVENTORY_LEVEL_UPDATE“ von Shopify ist unser Auslöser. Wir leiten dieses Event an einen Event Bus (Amazon EventBridge) weiter. Fan-out-Lambda-Funktionen aktualisieren parallel externe Marktplätze. (Latenz: <200 ms).

12. Umgang mit der „donnernden Herde“

Wenn um 10 Uhr morgens 50.000 Benutzer die Website besuchen, stirbt Ihre Datenbank. Für jede Bestandsprüfung eine Verbindung zu Postgres herzustellen, ist Selbstmord. Redis verarbeitet 100.000 Vorgänge pro Sekunde. Wir verwenden Read-Through-Caching.

App fragt Redis: „Lagerbestand für SKU-123?“
Redis sagt: „Miss“.
App fragt DB: „Lager ist 100“.
App teilt Redis mit: „SET SKU-123 100 TTL 10 Sek.“ Dadurch wird die DB-Last um 99 % reduziert. Was aber, wenn 1.000 Anfragen genau zur gleichen Zeit fehlschlagen? Sie alle trafen die DB. Wir verwenden Probabilistic Early Expiration oder Request Coalescing (SingleFlight), um sicherzustellen, dass nur EINE Anfrage die Datenbank erreicht, um den Cache aufzuwärmen.

Warum Maison Code dies bespricht

Bei Maison Code entwickeln wir High-Heat Launch Systems. Wir haben den Black-Friday-Verkehr für Top-Streetwear-Marken überstanden. Wir wissen, dass „Overselling“ kein „Ops Probem“ ist; es ist ein „Architekturfehler“. Wir entwickeln verteilte Sperrmechanismen, die auch im großen Maßstab starke Konsistenz garantieren. Wir schätzen Ihren Ruf. Eine stornierte Bestellung ist für immer ein verlorener Kunde.

14. Fazit

Die Bestandssynchronisierung ist das größte Problem im E-Commerce. Es kämpft gegen Physik (Latenz) und Wahrscheinlichkeit (Rennbedingungen). Mit „Simple Queries“ kann man nicht gewinnen. Sie benötigen Caching, Sperren und Warteschlangen. Sie müssen auf das Scheitern vorbereitet sein.

Verkaufen Sie während Drops zu viel?

Wir implementieren Redis-basierte High-Performance Inventory Sync, um 0 % Überverkäufe zu garantieren.

Stellen Sie unsere Architekten ein.