Держите счётчик остатка в одном атомарном месте и уменьшайте его атомарно — через Redis DECR (или Lua-скрипт), возвращающий оставшееся значение. Если результат < 0, этот запрос проиграл; база данных никогда не является точкой контроля конкурентности. Всё остальное — про то, как дёшево отсечь остальные 999 000 запросов.
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"
DECR stock:sale123 атомарен — два запроса не могут одновременно прочитать «остался 1». Lua-скрипт делает это за один round trip: проверяет остаток, уменьшает и записывает SADD winners:{sale} {user}, чтобы один пользователь не выиграл дважды. Lua выполняется в Redis однопоточно, поэтому весь check-and-set — один атомарный шаг.>= 0) кладутся в очередь; воркер асинхронно пишет заказ в Postgres. БД никогда не видит 1 млн конкурентных записей — только ~1000 записей победителей.Интервьюер хочет, чтобы вы точно назвали race condition: SELECT stock, затем UPDATE двумя операторами позволяют двум запросам оба прочитать 1000 и оба продать — классический oversell. «Хорошо» — «использовать транзакцию / SELECT ... FOR UPDATE»; «отлично» — осознавать, что блокировки строк сериализуют 1 млн запросов на одну горячую строку и обрушивают throughput, поэтому вы переносите конкуренцию на однопоточную атомарную операцию в Redis и сохраняете только победителей. Ловушка — доверять проверкам на уровне приложения (if (stock > 0)) без атомарности.
FOR UPDATE в БД: Redis держит 100k+ операций/с на одном горячем ключе; блокировка строки в Postgres сериализуется и плавится под flash sale. Оставьте БД для durable-записей заказов.Библиотека вопросов для IT-собеседований с подробными ответами — от Junior до Senior.
Поддержать