Pick strong consistency whenever possible

Re:Pick strong consistency whenever possible by IgorPartola on Monday January 15, 2018 @07:47PM (#16154903)

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.

[ Parent | on HN ]

Re:Pick strong consistency whenever possible by taeric on Monday January 15, 2018 @08:32PM (#16155092)

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.

[ Parent | on HN ]

Re:Pick strong consistency whenever possible by sangnoir on Tuesday January 16, 2018 @12:32AM (#16156052)

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

[ Parent | on HN ]

Re:Pick strong consistency whenever possible by jedberg on Monday January 15, 2018 @09:20PM (#16155276)

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.

[ Parent | on HN ]

Re:Pick strong consistency whenever possible by taeric on Monday January 15, 2018 @09:30PM (#16155316)

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?

[ Parent | on HN ]