In che modo un'azienda come Amazon evita i colli di bottiglia che accedono al livello del database?

However, if multiple users are being served by separate servers and both try to add the same item to their cart, for which there is only one remaining, there must be some "source of truth" for the quantity left for that item.

Non proprio. Questo non è un problema che richiede una soluzione tecnica perfetta al 100%, perché entrambi i casi di errore hanno una soluzione aziendale che non è molto costosa:

• Se dici erroneamente a un utente che un articolo è esaurito, perdi una vendita. Se vendi milioni di oggetti ogni giorno e questo accade forse una o due volte al giorno, si perde nel rumore.
• Se accetti un ordine e mentre lo elabora scopri che hai esaurito l'articolo, devi solo comunicarlo al cliente e dare loro la scelta di aspettare fino a quando non puoi riassortire o annullare l'ordine. Hai un cliente leggermente infastidito. Ancora una volta non è un grosso problema quando il 99,99% degli ordini funziona bene.

In effetti, ho sperimentato di recente il secondo caso, quindi non è ipotetico: è quello che succede e come Amazon lo gestisce.

È un concetto che si applica spesso quando si ha un problema che è teoricamente molto difficile da risolvere (sia in termini di prestazioni, ottimizzazione o qualsiasi altra cosa): si può spesso convivere con una soluzione che funziona molto bene per la maggior parte dei casi e accettare che a volte fallisce, purché sia possibile rilevare e gestire gli errori quando si verificano.

Una combinazione di

• hashing
• sharding
• replica
• distribuzione
• alto failover
• negozi di valori-chiave

Non c'è magia, solo situazioni sempre più complesse. Proprio come il DNS, è fatto in scala.

La "versione singola della verità" fa parte di tali sistemi. La generazione di una nuova chiave diventa un'operazione più complessa rispetto alla semplice generazione del numero successivo nella sequenza. Ad esempio esistono altre sequenze. Questo è il tipo di complessità che i sistemi di database distribuiti possono gestire e lo fanno effettuando diverse operazioni da e verso componenti quando si creano nuovi oggetti, rendendoli disponibili agli altri, garantendo che le sequenze siano univoche quando devono essere, chiavi composite, ecc. .

Ho visto il problema "Ultimo articolo disponibile" risolto nel modo seguente:

Aggiorna giornalmente tutti i livelli delle scorte e contrassegna i prodotti in base a livelli alti, bassi, ordinati o esauriti in base ai livelli soglia.

Ovviamente sono gli articoli "scorte basse" che sono problematici

• Articoli con livelli di stock elevati

Non preoccuparti di controllare il livello delle scorte. Basta effettuare l'ordine

• Articoli con bassi livelli di scorte

Avvisa l'utente quando sfoglia "Ultimi a sinistra!". quando vanno a pagare, controllare e ridurre il livello delle scorte. Se non disponibile, aggiorna lo stato dell'articolo.

In questo modo si colpisce il database solo per gli articoli "scorte basse" e lo si fa solo quando il cliente è abbastanza indietro nel processo di acquisto. Il costo è che alcuni clienti non saranno in grado di completare il loro acquisto.

Tuttavia, nella maggior parte dei casi "esaurito" significa solo che stai aspettando un'altra consegna, quindi vuoi comunque accettare l'ordine e magari solo far apparire un avvertimento o limitare le opzioni di consegna. Quindi quei clienti non sono andati persi.

Durante i tempi di caricamento elevati, come le vendite, potresti addirittura spegnere lo stock e inviare semplicemente email ai clienti più tardi, "scusa se siamo rimasti senza X, ti piacerebbe Y"

Essenzialmente, l'obiettivo di qualsiasi piattaforma di e-commerce non viene mai letto dal database. Pubblica sempre le pagine memorizzate nella cache e fai tutto il lato client.

In questo video, Martin Fowler discute i database NoSQL:

link

Uno dei punti (da qualche parte lì dentro), è che posti come Amazon preferiscono mantenere il 99% delle persone felici accettando il loro ordine senza essere in grado di controllare "di sicuro" se è effettivamente disponibile, e magari irritare un piccolo percentuale dovendo dire "mi dispiace, sembra che qualcuno ti abbia battuto".

Il che significa che non esiste una reale gestione per lo scenario che descrivi, solo che Amazon prende il beneficio del dubbio basato sull'ultima lettura di inventario riuscita e se una transazione concorrente è scivolata tra - oopsie.

(btw, è un bel video se sei curioso di NoSQL)