[aphyr]

All those should be possible; you just might not observe the state of the counter as it was a few milliseconds(?) ago, rather than what it might be right now. If you're dealing with extremely frequent updates where the chances of observing that sort of anomaly are more common, chances are the precise value of the counter doesn't matter so much, and an occasional off-by-one or off-by-two isn't the end of the world. YMMV, of course. :)

[pdeva1]

>you just might not observe the state of the counter as it was a few milliseconds

did you mean 'might observe' instead of 'might not'? stale read would result in the older value being read.

i believe the anomaly would then occur depending on how close the 2 events are in time, regardless of frequency.

in that case, precise counts can be needed even with low frequency. say you are a restaurant with 1 burger left. 2 folks order the same time, but you decrement the count by 1 only.

also anything involving monetary values, you definitely don't want to read stale values ever.

[grogers]

If you earmarked the last burger to multiple people, it would violate serializability, not linearizability. So you should be good on that. Violating linearizability would look like this: with no burgers left, the kitchen cooks a burger, marks it as available in the DB and then shouts that it's ready. A customer hears them shout and immediately tries to order it, but fails because the customer's transaction happened at an earlier logical time than the kitchen's. Kyle is saying there are still relatively small time bounds on such violations (usually?) so it's probably not the biggest problem your restaurant has to worry about (just apologize and have the customer try again).

Dealing with money is similarly not a problem. ACH takes much longer to clear than the uncertainty window of linearizability violations. The client probably won't be able to tell the difference.

[manigandham]

For banking systems in reality, monetary values in databases are immutable and only ever appended to. Banking is often used as a reason for strong consistency but it actually is almost always eventually consistent.

[aphyr]

Yes, thank you. I was rushing to get out the door and edited the sentence carelessly! You'll likely see a current value most of the time, even under high contention, but might occasionally see a slightly stale one.

As grogers notes, a stale read is a different phenomenon than the burger problem you describe, which is also called "lost update". We didn't observe any cases of lost updates in YugaByte DB.

As for monetary values, you might find it interesting to ask someone who works in banking or fintech about recency properties of their data systems. Latencies on the order of multiple days are surprisingly common.

[pdeva1]

correct me if i am wrong here:

1. burger case, i do: count = count-1 if both txs see count=1, we get count=0 at the end.

2. i didnt say banking per se. can involve a simple billing system of a startup. or any critical data where you need to ensure you are reading accurate, uptodate values. maybe a leaderboard.

>You'll likely see a current value most of the time

'most' is not a guarantee :) either the system is designed with seeing uptodate values or not. and if 'some' of the time the value is stale, you have to program with low consistency in mind.

the marketing on yugabyte's page makes it seems it can replace db's like cassandra and give you a consistent view of your data. but if one is seeing stale values, you are back to coding like data is non-consistent

[manigandham]

Cassandra is designed for eventual consistency across multiple independent regions.

[aphyr]

correct me if i am wrong here... i do: count = count-1 if both txs see count=1, we get count=0 at the end.

I, er, don't mean to be rude, but... both grogers and I have already explained that this idea is somewhat less than correct. The anomaly you're describing is called lost update, and is explicitly prohibited by both snapshot isolation and serializable isolation, the two isolation levels supported by YugaByte DB. Linearizability is not necessary to prevent lost updates. This is not only a theoretical fact, but supported by experimental evidence: we have extensively tested YugaByte DB for lost updates, and have not (yet) observed any.

i didnt say banking per se. can involve a simple billing system of a startup. or any critical data where you need to ensure you are reading accurate, uptodate values. maybe a leaderboard.

While linearizability may be a nice property for these systems to have, it is rarely necessary. Billing systems and leaderboards, like bank ledgers and shopping carts, are often designed as append-only ledgers with eventual consistency, employing sealing windows, compensating transactions, and time-shifting to handle late discovery of events. Others are designed as as reports periodically derived from some underlying datastore via, say, an ETL process; data may be not only milliseconds, but even days or weeks out of date. That's not to say this is a universal pattern, but I can think of a few dozen systems off the top of my head.

I know this because I've worked on several systems like this, including in fintech, and consulted for companies and government organizations building others. I can also offer some anecdotal experience here. For example, I have no fewer than three emails in my inbox from AWS's billing system informing me of missing data or other mistakes in the previous month's bill, accompanied by updated reports providing newer data. Last summer, my bank deferred visibility of some transaction data for over six weeks.

This might feel counter-intuitive, but since money is fungible and addition is commutative, it's one of the easiest things to work with in a stale or even eventually-consistent manner. Where you really want linearizability (or at least sequential consistency) is in domains where operations don't commute. Linearizability is particularly important where those non-commutative operations involve side-channels, but that's a longer discussion for another time.

'most' is not a guarantee

This is true, but there is a qualitative difference between a system which exhibits, say, a 5ms stale read once per thousand transactions during clock skew, and a 10-day stale read one in every two transactions all the time. I mention these numbers to provide a rough characterization of anomaly frequency and severity.

the marketing on yugabyte's page makes it seems it can replace db's like cassandra and give you a consistent view of your data. but if one is seeing stale values, you are back to coding like data is non-consistent

Linearizability is not the only form of consistency model, and many models have no realtime properties whatsoever. You might find https://jepsen.io/consistency informative.

[pdeva1]

thanks for clarifying. appreciate the detailed answer.