Какая архитектура бекенда для временной информации(капча и пр.)?

Question

[MirKey]

Допустим SPA сервис с авторизацией и прочим. Где хранятся примитивные временные данные например текущая капча и количество введённых попыток или ещё какая-то временная информация?
Насколько целесообразно это хранить в БД на диске или это обычно размещают в памяти/сессиях?

Answer 1

[Василий Банников]

Тут напрашивается Redis.
1. Ничего страшного не произойдёт, если разок при вводе капчи пользователя попросят ввести её ещё раз, если на стороне твоего Бэка что-то потеряется.

2. Если ты создаёшь большой сервис с кучей клиентов, то ты можешь захотеть горизонтально масштабироваться - тогда твой сервис должен быть stateless, а по тому никакого состояния в памяти у отдельного экземпляра быть не должно.

3. Сессия - это по определению состояние, которое привязано к конкретному пользователю, но при этом не говорится, где оно хранится.
В случае сервиса капч сессии неприменимы, тк ты не занимаешься идентификацией пользователей.

Comments

[MirKey]

А как быть с хранением активных соединений websocket?

[Everything_is_bad]

MirKey, никак, все соединения только в памяти работающего сервиса

[Василий Банников]

MirKey, про вебсокеты ничего в вопросе не сказано

[MirKey]

Василий Банников, всё таки не понятно где лучше хранить данные сессии(капча, попытки, ID Юзера и тп.) в памяти(Redis...) или на диске(например в pgsql)

[Василий Банников]

MirKey, А для чего тебе их хранить и как ты к ним будешь обращаться?
Если тебе не нужно их супер долго для архива хранить и при этом ты к ним обращаешься каждый запрос, то логично их хранить в редисе (ну или хотябы кэшировать в редисе)

А id юзера почему является частью сессии, а не частью самого юзера? С чем вообще сопоставляется сессия?