QR должен ссылаться на серверный счёт с непрогнозируемым токеном, а не задавать сумму оплаты. Заказ закрывают по проверенному подтверждению платёжного провайдера, не по возврату браузера.
Спроектируйте высоконагруженную систему QR Pay для ресторана: касса печатает QR-код со счётом, пользователь открывает страницу, видит итоговую сумму и переходит на платёжный шлюз; после успешной оплаты заказ должен закрыться. Ожидается около миллиона запросов в час. Опишите сервисы, последовательность вызовов, технологии, безопасность и масштабирование.
QR должен ссылаться на серверный счёт с непрогнозируемым токеном, а не задавать сумму оплаты. Заказ закрывают по проверенному подтверждению платёжного провайдера, не по возврату браузера.
Короткий ответ
Что ответить на собеседовании
Подробный разбор
Ответ с пояснениями
QR должен ссылаться на серверный счёт с непрогнозируемым токеном, а не задавать сумму оплаты. Заказ закрывают по проверенному подтверждению платёжного провайдера, не по возврату браузера.
Касса создаёт invoice с неизменяемой суммой, валютой и сроком; web/API показывает его и создаёт идемпотентную попытку платежа. Webhook сверяют с провайдером и атомарно фиксируют paid; outbox доставляет событие кассе с повторами и дедупликацией. Нужны reconciliation и обработка поздних платежей. Миллион запросов в час — около 278/с в среднем: отдельно оценивают пики. Stateless API масштабируют горизонтально, БД индексируют по invoice/payment ID, публичные страницы защищают от перебора и утечек.