Πώς αποτρέπετε το oversell όταν 1 εκατομμύριο χρήστες αρπάζουν 1000 κωδικούς;

Question

IT Interview Practice · Accepted Answer

Κρατήστε τον counter του stock σε **ένα ατομικό (atomic) σημείο** και μειώστε τον ατομικά — ένα Redis `DECR` (ή ένα Lua script) που επιστρέφει την υπολειπόμενη τιμή. Αν το αποτέλεσμα είναι `< 0`, αυτό το request έχασε· η βάση δεδομένων *ποτέ* δεν είναι το concurrency gate. Όλα τα υπόλοιπα αφορούν το να απορρίπτετε τα άλλα 999.000 requests φθηνά. ## Αρχιτεκτονική ```text 1M clients ─▶ CDN/edge (waiting room, drop bots) ─▶ LB │ Stateless API pods │ Redis: DECR stock (Lua: check+dec+record) │hit>=0 │miss<0 ▼ ▼ enqueue order ─▶ DB reject "sold out" ``` ## Στοιχεία και ροή - **Το waiting room / admission control** στο edge είναι η πρώτη γραμμή άμυνας. Δεν αφήνετε 1 εκατομμύριο connections να χτυπήσουν το API σας· μια σελίδα ουράς (στυλ Cloudflare Waiting Room) δέχεται χρήστες σε ελεγχόμενες παρτίδες. Αυτό μετατρέπει ένα spike σε μια σταθερή ροή. - **Το atomic decrement του Redis** είναι η μοναδική πηγή αλήθειας για το stock. Το `DECR stock:sale123` είναι atomic — δύο requests δεν μπορούν και τα δύο να διαβάσουν "1 απομένει". Ένα **Lua script** το κάνει σε ένα round trip: ελέγχει το υπόλοιπο, μειώνει, και καταγράφει `SADD winners:{sale} {user}` ώστε ένας χρήστης να μην μπορεί να κερδίσει δύο φορές. Το Lua τρέχει single-threaded στο Redis, οπότε ολόκληρο το check-and-set είναι ένα atomic βήμα. - **Order queue → DB**: οι νικητές (αποτέλεσμα `>= 0`) σπρώχνονται σε μια ουρά· ένας worker γράφει το order στην Postgres ασύγχρονα. Η βάση δεν βλέπει ποτέ 1 εκατομμύριο ταυτόχρονα writes — μόνο ~1000 writes νικητών. - **Το μονοπάτι απόρριψης** επιστρέφει "sold out" ακαριαία στους χαμένους. Η γρήγορη απόρριψη είναι feature: απελευθερώνει connections και προστατεύει το backend. ## Οπτική συνέντευξης Ο συνεντευκτής θέλει να σας δει να κατονομάζετε το **race condition** με ακρίβεια: `SELECT stock` και μετά `UPDATE` σε δύο εντολές αφήνει δύο requests να διαβάσουν και τα δύο 1000 και να πουλήσουν και τα δύο — κλασικό oversell. Το "καλό" είναι "χρησιμοποίησε transaction / `SELECT ... FOR UPDATE`"· το "εξαιρετικό" είναι να αναγνωρίζετε ότι τα row locks σειριοποιούν 1 εκατομμύριο requests πάνω σε μία hot row και καταρρέουν το throughput, οπότε μετακινείτε την contention σε ένα single-threaded atomic op στο Redis και κάνετε persist μόνο τους νικητές. Η παγίδα είναι να εμπιστεύεστε ελέγχους σε επίπεδο εφαρμογής (`if (stock > 0)`) χωρίς atomicity. ## Trade-offs και αποτυχία - **Redis vs DB `FOR UPDATE`**: το Redis χειρίζεται 100k+ ops/s σε ένα hot key· ένα Postgres row lock σειριοποιεί και λιώνει κάτω από ένα flash sale. Κρατήστε τη βάση για durable order records. - **Διαθεσιμότητα vs ορθότητα**: αν το Redis αποτύχει στη μέση της πώλησης πρέπει να κάνετε **fail closed** (απόρριψη) — το ξανάνοιγμα των πωλήσεων ρισκάρει oversell. Κάντε persist το πλήθος πωλήσεων ώστε να ανακτάτε το αληθινό υπόλοιπο. - **Consistency**: κάντε reconcile τους νικητές του Redis με τα orders της βάσης μετά την πώληση· ένας νικητής του οποίου το DB write απέτυχε πρέπει να πάρει refund μια θέση ή να ξανα-εκχωρηθεί. Προσθέστε rate limits ανά χρήστη και bot detection αλλιώς scripts αδειάζουν το stock σε milliseconds.

Αρχιτεκτονική

Στοιχεία και ροή

Οπτική συνέντευξης

Trade-offs και αποτυχία

Σχετικές ερωτήσεις