Резервируйте слот атомарно в общей БД, а не локальной блокировкой одного backend-процесса. Победителя определяет условное обновление или уникальное ограничение.
Как на сервере обработать параллельные запросы на резервирование одного слота скидки при масштабировании до 300 касс?
Резервируйте слот атомарно в общей БД, а не локальной блокировкой одного backend-процесса. Победителя определяет условное обновление или уникальное ограничение.
Короткий ответ
Что ответить на собеседовании
Подробный разбор
Ответ с пояснениями
Резервируйте слот атомарно в общей БД, а не локальной блокировкой одного backend-процесса. Победителя определяет условное обновление или уникальное ограничение.
Например, UPDATE discount_slots SET reserved_by = :request_id WHERE id = :slot_id AND reserved_by IS NULL RETURNING id выдаёт слот только одному запросу. Пустой результат означает, что слот уже занят.
Для повторов кассы используйте idempotency key и возвращайте прежний результат. При временной резервации храните срок и проверяйте владельца/версию при подтверждении и освобождении. Не держите транзакцию во время долгой оплаты. Для 300 касс важны индексы, таймауты и понятный ответ при конкуренции, а не число потоков на сервере.