Разработка API микросервисов. Поддерживать контекстный контекст

Question

Представьте себе процесс восстановления пароля, который состоит из трех этапов:

1. Отправка SMS. Пользователь входит в телефон. Отправьте смс с кодом подтверждения. Мы должны ограничить, сколько раз за период времени пользователь может сделать этот запрос.
2. Введите код SMS. Пользователь вводит код подтверждения. Мы должны ограничить количество попыток.
3. Установить новый пароль.

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

---

Предположим, у нас простая архитектура:
Служба шлюза и входа в систему, которая реализует три метода API, каждый из которых соответствует каждому шагу восстановления пароля.

Вопрос: Какая служба должна реализовывать такого рода ограничения состояния? Шлюз или служба входа?

Должен ли это быть шлюз, который будет отслеживать количество неудачных попыток и другой контекст. Это оставляет службу входа без сохранения состояния.
Или, может быть, службу входа в систему, так что если архитектура развивается и будет другой шлюз, нет необходимости дублировать тот же код в другом шлюзе.

Answer 1

С моей точки зрения, состояние не должно храниться ни в логине, ни в шлюзе, обе службы должны быть без состояний, чтобы их можно было масштабировать. Эта информация должна находиться в хранилище данных, к которому должен обращаться сервис входа в систему. Поскольку это процесс входа в систему, ответственным за все операции, связанные с входом в систему, должна быть служба входа в систему, и он должен отслеживать, где во всем процессе входа в систему каждый пользователь хранит, например, переменную login_status. Таким образом, вы можете узнать, ожидает ли конкретный пользователь c получения SMS, или ввести код в систему, или число попыток этого пользователя.

Вместо этого шлюз должен полностью не знать о бизнес логи c услуг, стоящих за ним. Его обязанность - просто быть уникальной точкой доступа