> To that end, it is nice not having to effectively do a "loopUntilChangeReflected" after every write and checking to see if it is safe to do the next thing. Which you have to do in an eventually consistent world.

If you have to do this, you probably shouldn't be using an eventually consistent system. Eventually consistent systems should only be deployed when a stale read is harmless. For example, it probably isn't a big deal if something reads "5 upvotes" instead of "7 upvotes" before a change fully propagates out.

Wrapping every write in a "block to ensure consistency" loop is just a lossy, slow, terrible and dangerous way to recapture a tiny amount of the consistency available to those who use a system that suits their needs.

I know that in the real world, we don't often get to make these decisions, or there may be one-off edge cases (though really just put these on a system that's safe for them). But I just want to point out to other readers that if you catch yourself doing this, you just need to use a datastore that fits your application's use case.

Yes, even if you just read an article in TechCrunch about the Hippest Coolest Hottest Big-Dataiest 2.0 3.0 4.0 5.0 Data Storage Project That Makes Google and Facebooks' Mouths Water Hadoop-Daboop Machine, That Only Cool People Use, and No Uncool People Or Trump Supporters Of Any Kind Allowed.

Read that article, and then go use Postgres.

Fair. I was overly silly in my example there.

I'd still argue that even reasoning about all writes in an, "eventually this is true for everyone else," fashion is less than straight forward.

To that end, components should all be able to assume what they do is strongly consistent. If possible, assume everyone else is behind?

Not that I necessarily agree, but what GP is saying is that say you have a distributed DB backing your auth system, and there is a partition. The user tries to log in and you can’t be sure that their account is still valid because of the partition, but because all they are trying to do is watch a movie, just let them in based on the data that the partition you do have access to.

This is in contrast to a bank which should always operate only when there is no partition.

That makes sense, but how do you encode it? The auth system now does not return authorized or not authorized, but authorized or maybe authorized? Seems much easier to just rely on auth being a yes or no. Possibly with an expiration for how long a yes can be trusted.

That is, how is it simpler to assume that the data you get back could be wrong? Now, anyone involved with the system seems to have to know how everyone involved in the system interprets results.

> Now, anyone involved with the system seems to have to know how everyone involved in the system interprets results.

This meshes with the articles assertion: strong consistency leads to fewer bugs because fewer possible states exist at application level.

It allows the person writing the business software layer to make a decision that fits that business use case independent of how others interpret it. But no one else needs to know how it works.

If the "play movie" service calls the auth service and says "should I let this play", the auth service returns "authorized" or didn't give a response or said "maybe authorized" or whatever. The "play movie" service makes the business decision that makes sense for playing a movie, in this case, "go ahead".

But the billing service maybe says "I'm only gonna let you in with a confirmed yes". So it's possible the billing service will give you an error in the same conditions that the movie service does not, but those are business decisions instead of technical ones, which is good.

This doesn't sound like a consistency debate, though. Distributed system, yes. Weak consistency, though?

I'd want strong semantics on, "what is allowed with an authenticated connection with an authentication that is X old?". Preferably, I'd want a somewhat knowable centralized list of the answers. These are not software concerns, but business ones. Right?

> Is anyone actually "failing open" for user authentication?

Netflix did for a while at least, may still do it. Worst case is that someone didn't pay for the month. The partitions happen rarely enough that it is better to give the user a good experience then not let a legit user in because of a network partition.

But the nice part is that this was a business decision, not a database decision.

Billing is not authentication, it's a facet of authorization. In any event, it would be pretty lousy if Netflix exposed account details, viewing history, etc., to loosely-authenticated accounts.

It was only for playing a movie. But that right there is a perfect example of why the logic should be at the business level and not the database level.

Allow them to watch a movie, but don't show billing details.

This is still worded poorly. You aren't skipping authentication for these people. You just aren't doing it again.

In theater parlance, people in the theater are assumed authorized to be there by virtue of the entrance requiring authorization.

Right?

Similarly, this had little to do with consistency. Any client that makes a logout should assume the connections it has are no longer valid. To assume otherwise seems odd. Worse, to encourage relying on it.

This sounds suspicious. They had other mechanics to guard against abuse than auth?

Worst case would be a renegade client that constantly used the open door, no?

I think this is a backend thing, so renegade client isn't an issue. The choice is: if the auth system was down, should the video system prevent everyone from seeing video, or let everyone in. If auth is down, some people will be able to watch when the shouldn't be able to, but only for the period of time while the auth system is down.

Wouldn't this only allow recently authenticated people in? That is, connections at this point can check if there is an "authenticated" flag set. Assuming any basic expiration, the only people getting through this are those that have recently lost authorization. They were still authenticated. Right?

If auth is up, everything works as normal. If it's down let everyone in.

I'm envisioning something on the backend equivalent to:

OnGetVideoChunkRequest: if Authorized(User) or IsDown(AuthSystem) then SendVideoChunk

Makes sense. Still surprises me that it wouldn't be a check more like "if not expiredOrAbsentAuthentication..."

I think you're overly focusing on details. Authorized(User) might check expiration or other things, but that isn't really relevant to the fail open vs fail close idea being discussed.

I'm focused on connections. All systems should not have to connect back to the auth system to do their job. To that end, determining that a connection is trusted is not a weak versus strong consistency issue.

Now, checking a password in the system should be strongly consistent. In that I should be able to update my password and immediately use the updated password. Any other behavior will surprise me.

I wouldn't take my example too literally. The example was just to illustrate the basic logic for fail open and intentionally wasn't complete or detailed.

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".

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.

It would only fail open if the connection from the auth service to the database was down. It's all server side.

See my sibling response. This doesn't sounds like a consistency debate as much as a trusted connections debate.