News for hackers. Stuff that matters.
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.

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?