Re:Pick strong consistency whenever possible
by taeric on Tuesday January 16, 2018 @12:48AM
(#16156115)
I suspect it is just focusing on an example. So, to that, apologies if I am over diluting the conversation. Rereading my first post, I should have been clearer that I can agree with the point. Just don't know if auth is the domain I would pick, since it isn't a persisted thing, but a vouched one.
Similarly, anywhere you are doing idempotent guarantees, strong consistency is vital. Same for customer interaction. Reads following writes that a user made should almost certainly strive for strong consistency. If only to avoid confused customers.
Writes the system makes, though? Expect those to just fail in ways that will leave things inconsistent and constantly check for them.
For purposes of discussing fail open, how that logic gets translated during implementation doesn't matter. Authorized(User) might be expiring tokens passed in via cookie. IsDown(AuthSystem) could just check some global flag that gets set by some watchdog service on a AuthSystem heartbeat. It could be something else. It doesn't matter because it's not relevant.
Having a direct connection to the AuthSystem or not is an implementation detail, not something that changes the idea "Netflix should fail open".