При работе на экстремальных нагрузках у вас богатого выбора нет. Это почти всегда - асинхрон, а потом ещё и пакетная обработка.

Но 100 одновременных юзеров - это как бы очень скромно. Десятки тысяч, вот тут уже стоит думать.

Можно из одной таблицы сделать сотню, использовать партиционирование. И разным запросам выдавать разные таблицы для блокировки.

Хм. Ок. Спасибо.

Нужно уходить от модели request-response. Принимаете запрос, ставите его в обработку (конвейер/поток), возращаете результат (пуш)

Не знаю как будет на практике, но мне нравится идея с буфером)

Двумерная коллекция, где элемент коллекции:
Тип товара -> 100 свободных айдишников.

При пустом буфере первый пользователь подождёт заполнение буфера, последующие 99 будут быстро получать незанятый айдишник для данного товара, 101-ый пользователь ждёт сброс буфера в базу и заполнение нового буфера.

Допустим 10000 типов товаров, по 100 айдишников на каждый - 8 мегабайт памяти)
upd: Если uid используется для айдишников, то 16 МБ*

Окей, рассмотрю этот вариант, спасибо.

Хм.. а вот этих выигрышных билетов разве их не штук 10 всего?
Почему бы их просто не держать в памяти веб-сервера в статике?
Или это был гипотетический пример?

Сервис не различает выигрышные и не выигрышные билеты.

Это вот такой вариант: сделать чтобы различал. Какой смысл хранить невыигрышные билеты?

Отдать их пользователю.

Зачем их хранить в БД, чтобы отдавать? Можно хэш сделать и так проверять законность билета.

Законность?

Сервис не знает про то, выигрышные билеты или нет.

Ему надо просто отдать.

Законность: это к тому, чтобы проверить что билет настоящий.

Т.е. все билеты в оперативке держать?

Только выигрышные.

Нет информации о том, выигрышные билеты или нет.

не внимательно читал переписку, но имхо - фильтр блума вам поможет