3 ms·
This is where the "or persistence" bit comes in, but the trade-off isn't as you describe. One way to approach it would be for B to set a flag against the user
by regularfry 3y ago
This is where the "or persistence" bit comes in, but the trade-off isn't as you describe. One way to approach it would be for B to set a flag against the user in the database they must already have, because they have users so that A can process password resets on its own schedule. It's add a column versus add a message queue. Databases already come with locking primitives and well understood patterns, no reinvention needed.
- valenterry 3y agoYou are now assuming that they indeed have a database nd store users in there, and not use a 3rd party system that might not even allow to attach meta data (or at least make it difficult).
- regularfry 3y agoIn which case why is the password reset my problem at all? But even if I've handed off identity management entirely, I almost certainly do have some per-user state. Otherwise... what on earth am I doing with users in the first place?
- valenterry 3y agoWell, maybe because the 3rd party service is not reliable or you want to send an additional mail. But okay, fair point - password-reset is maybe not the greatest example. But it doesn't invalidate the general point (I gave a couple of other examples). > Otherwise... what on earth am I doing with users in the first place? Maybe just making sure that the user is known and has paid for plan X (if the 3rd party service offers that).