Condizioni di gara: risolvere la sincronizzazione dell'inventario in tempo reale

Immagina di avere 1 unità di una scarpa da ginnastica in edizione limitata rimasta. L’utente A è sul tuo sito web. L’utente B è sulla tua app. Entrambi fanno clic su “Acquista” esattamente nello stesso millisecondo (12:00:00.001). Shopify riceve due richieste. Se non gestito correttamente, vende la scarpa due volte. Ora devi inviare un’e-mail a un cliente e annullare l’ordine. Questo è un disastro di pubbliche relazioni.

6. Coerenza finale (la regola dei 2 secondi)

L’amministratore Shopify dice “Stock: 10”. Il tuo ERP (NetSuite) dice “Stock: 8”. Il tuo magazzino (WMS) dice “Stock: 9”. Chi ha ragione? Nessuno. In un sistema distribuito, la coerenza è eventuale. Abbiamo bisogno di un’unica fonte di verità per le azioni “allocate”. Utilizziamo Redis come “tabella di allocazione” autorevole. Solo dopo la spedizione dell’ordine decrementiamo l’ERP.

7. Buffer delle scorte di sicurezza

“Se stock < 5, contrassegna come esaurito.” Questa è una strategia rozza ma efficace per gli articoli ad alto rendimento. Se vendi 100 articoli al secondo, la latenza di sincronizzazione (200 ms) significa che potresti vendere in eccesso di 20 articoli. Soluzione: scorta di sicurezza dinamica. Se la velocità delle vendite > 10/min, aumenta le scorte di sicurezza a 10. Se la velocità delle vendite < 1/min, ridurre il buffer di sicurezza a 0. Ciò massimizza il sell-through proteggendoti dall’inventario negativo.

9. Negozi oscuri e spedizione dal negozio

L’inventario non è solo nel magazzino. È nei negozi al dettaglio. Implementiamo la Sincronizzazione omnicanale. Il “Flagship Store” sulla 5th Avenue è anche “Warehouse #2”. Se il magazzino principale è OOS, il sistema controlla l’inventario del negozio. Indirizza l’ordine al negozio iPad. L’addetto al negozio preleva, imballa e spedisce. Ciò sblocca il 20% in più di inventario che precedentemente era “intrappolato” sugli scaffali.

10. Sincronizzazione logistica dei resi

Quando viene avviato un reso (/returns), l’articolo è tecnicamente “In transito”. Non è “Disponibile per la vendita”. Ma sappiamo che tornerà. Per gli articoli molto richiesti, possiamo abilitare Ordini arretrati. “Disponibile in 5 giorni” (Arrivo Previsto del Reso). Sincronizziamo gli eventi del corriere logistico di restituzione (FedEx Scan) per aggiornare lo stato in Shopify. Ciò recupera le entrate dalle vendite perse.

11. Conclusione: blocco ottimistico e Redis

Non possiamo fare affidamento sul fatto che il database affermi semplicemente “stock = 1”. Abbiamo bisogno di un Blocco distribuito.

“sirena”. sequenzaDiagramma utente partecipanteA partecipante UtenteB partecipante Redis partecipante Shopify

UtenteA->>Redis: blocco SETNX:sku_123 1
Redis-->>UtenteA: OK (blocco acquisito)
UtenteB->>Redis: blocco SETNX:sku_123 1
Redis-->>UtenteB: FAIL (bloccato)

UtenteA->>Shopify: Checkout Crea
Shopify-->>UtenteA: ordine riuscito
UtenteA->>Redis: DEL lock:sku_123

UtenteB->>UI: mostra l'errore "Esaurito".

### 1. Il sistema di prenotazione
Quando un utente aggiunge un articolo ad alta temperatura al carrello, lo prenotiamo in Redis per 10 minuti.
"SET prenotazione:sku_123:user_abc EX 600".
Ciò diminuisce immediatamente lo stock *disponibile*, anche prima che avvenga l'acquisto.
Se non acquistano entro 10 minuti, la chiave scade e le azioni ritornano nel pool.

## Webhook per la sincronizzazione
Quando un ordine *effettua* un ordine, dobbiamo comunicarlo immediatamente ad Amazon e TikTok.
Il webhook `INVENTORY_LEVEL_UPDATE` di Shopify è il nostro trigger.
Inviamo questo evento a un **Event Bus** (Amazon EventBridge).
Le funzioni lambda fan-out aggiornano i mercati esterni in parallelo. (Latenza: <200ms).

## 12. Gestire il "branco tonante"

Quando 50.000 utenti raggiungeranno il sito alle 10:00, il tuo database morirà.
Connettersi a Postgres per ogni controllo dell'inventario è un suicidio.
Redis gestisce 100.000 operazioni al secondo.
Utilizziamo il **Read-Through Caching**.
1. L'app chiede a Redis: "Stock per SKU-123?"
2. Redis dice: "Signorina".
3. L'app chiede a DB: "Lo stock è 100".
4. L'app comunica a Redis: "SET SKU-123 100 TTL 10sec".
Ciò riduce il carico del DB del 99%.
Ma cosa succede se 1.000 richieste non vanno a buon fine *esattamente nello stesso momento*? Colpiscono tutti il ​​DB.
Utilizziamo la **Scadenza anticipata probabilistica** o la **Coalescenza delle richieste** (SingleFlight) per garantire che solo UNA richiesta raggiunga il DB per riscaldare la cache.

## Perché Maison Code ne parla

Noi di **Maison Code** progettiamo **sistemi di lancio ad alta temperatura**.
Siamo sopravvissuti al traffico del Black Friday per i migliori marchi di streetwear.
Sappiamo che l'"eccesso di vendita" non è un "problema operativo"; è un "fallimento dell'architettura".
Costruiamo meccanismi di Locking Distribuito che garantiscono **Strong Consistency** anche su larga scala.
Apprezziamo la tua reputazione. Un ordine annullato è un cliente perso per sempre.

## 14. Conclusione

La sincronizzazione dell'inventario è il problema più difficile nell'e-commerce.
Combatte la fisica (latenza) e la probabilità (condizioni di gara).
Non puoi vincere con "Query semplici".
Sono necessari la memorizzazione nella cache, il blocco e l'accodamento.
È necessario progettare per il fallimento.


<hr style="margin: 1rem 0" />

### Vendi troppo durante i drop?
Implementiamo la sincronizzazione dell'inventario ad alte prestazioni basata su Redis per garantire lo 0% di vendite in eccesso.


**[Assumi i nostri architetti](/contact)**.