Microservices API design. Maintain stateful context

Question

Imagine password recovery process, which consist of three steps:

1. Send SMS. User enters the phone. Send sms with confirmation code. We must limit how many times in a period of time user can make this request.
2. Enter SMS code. User enters confirmation code. We must limit the number of attempts.
3. Set a new password.

Also we must ensure correct order of this steps. Meaning user can not jump straight to step 3 without succeeding in first two steps.

---

Suppose we have simple architecture:
Gateway and Login service which implements three API methods each of which corresponds to each password recovery step process.

The question is: Which service must implement this kind of stateful restrictions ? Gateway or Login service ?

Should It be Gateway that will keep track number of failed attempts and other context. Which leaves Login service stateless.
Or maybe Login service, so if architecture evolves and there will be another Gateway, there is no need to duplicate same code in another gateway.

Answer 1

From my point of view, state shouldn't be stored neither in login nor gateway, both services must be stateless so they can be scaled out. This information must be in a datastore that has to be queried by the login service. Because this is a login process the responsible for all operations related to login must be the login service and it needs to keep track of where in the whole login process each user is by storing, for example, a login_status variable. This way you can know if a specific user is waiting to receive SMS, or to enter the code into the system or the number of attempts this user has made.

The gateway instead must be completely ignorant of the business logic of the services behind it. Its responsibility is just to be a unique point of access