While, as far as I can tell, chapter 7 avoids having hard server failures, AFAICT it doesn't avoid potential breakdowns of all services, at least as observable to the end user.
Concretely with the Rolling Update Deployment Strategy, and the deployment of email confirmation as an unit. If there currently a rolling update going on, then one might end up signing up in the backend with email confirmation while signing up, but then, when confirming his request, end up at a backend without the email confirmation. In that case he would get an error and would not be able to finish his signup.
This relies on a replication of more than 1, and on the update taking longer than the user getting the mail and trying to confirm it. Depending on the SLA it might not even count. Still, I thought I might highlight this, as with some weird setups it isn't impossible, and with eg. canary deployment it would be much more likely.
One would be able to avoid this by first deploying only the confirmation logic without using it (so immediately confirming the user, as one state of the backend already does, but having the confirmation endpoint present), waiting until it propagated through all backends, and only then the logic requiring email confirmation.
While, as far as I can tell, chapter 7 avoids having hard server failures, AFAICT it doesn't avoid potential breakdowns of all services, at least as observable to the end user.
Concretely with the Rolling Update Deployment Strategy, and the deployment of email confirmation as an unit. If there currently a rolling update going on, then one might end up signing up in the backend with email confirmation while signing up, but then, when confirming his request, end up at a backend without the email confirmation. In that case he would get an error and would not be able to finish his signup.
This relies on a replication of more than 1, and on the update taking longer than the user getting the mail and trying to confirm it. Depending on the SLA it might not even count. Still, I thought I might highlight this, as with some weird setups it isn't impossible, and with eg. canary deployment it would be much more likely.
One would be able to avoid this by first deploying only the confirmation logic without using it (so immediately confirming the user, as one state of the backend already does, but having the confirmation endpoint present), waiting until it propagated through all backends, and only then the logic requiring email confirmation.