_______ __ _______
| | |.---.-..----.| |--..-----..----. | | |.-----..--.--.--..-----.
| || _ || __|| < | -__|| _| | || -__|| | | ||__ --|
|___|___||___._||____||__|__||_____||__| |__|____||_____||________||_____|
on Gopher (inofficial)
URI Visit Hacker News on the Web
COMMENT PAGE FOR:
URI Stonebraker on CAP theorem and Databases (2010)
oooyay wrote 8 hours 24 min ago:
A lot of these kinds of discussions tend to wipe away all the nuance
around why you would or wouldn't care about consistency. Most of the
answer has to do with software architecture and some of it has to do
with use cases.
dfajgljsldkjag wrote 8 hours 32 min ago:
I think we try too hard to solve problems that we do not even have yet.
It is much better to build a simple system that is correct than a messy
one that never stops. I see people writing bad code because they are
afraid of the network breaking. We should just let the database do its
job.
pyrolistical wrote 3 hours 53 min ago:
But consistency is a choice we need to make when deciding how to use
a database.
By letting databases do its job, you let someone else make a trade
off for you
johnmwilkinson wrote 10 hours 21 min ago:
Sort of related?
URI [1]: https://www.usenix.org/system/files/login-logout_1305_mickens....
lencastre wrote 3 hours 49 min ago:
til, thx
belter wrote 10 hours 37 min ago:
The 2010 is really important here. And Stonebraker is thinking about
local databases systems and was a bit upset but the NoSQL movement push
at the time.
And he is making a mistake in claiming the partitions are "exceedingly
rare". Again he is not thinking about a global distributed cloud across
continents.
The real world works with Eventual Consistency. Embrace it, for most
90% of the Business Scenarios its the best option:
URI [1]: https://i.ibb.co/DtxrRH3/eventual-consistency.png
majormajor wrote 7 hours 12 min ago:
> And he is making a mistake in claiming the partitions are
"exceedingly rare". Again he is not thinking about a global
distributed cloud across continents.
Any time an AWS region or AZ goes down we see a lot of popular
services go nearly-completely-down. And it's generally fine.
One thing I appreciate about AWS is that (operating "live" in just a
single AZ or even single region) I've seen far fewer
partition-causing networking hiccups than when my coworkers and I
were responsible for wiring and tuning our own networks for our own
hardware in datacenters.
anonymars wrote 8 hours 53 min ago:
Remember also that "partition" is not "yes or no" but rather a
latency threshold. If the network is connected but a call now takes
30 seconds instead of milliseconds, that is probably a partition
hobs wrote 9 hours 37 min ago:
I would say quite the opposite - most business have little need for
eventual consistency and at a small scale its not even a requirement
for any database you would reasonably used, way more than 90% of
companies don't need eventual consistency.
belter wrote 9 hours 12 min ago:
No. The real world is full of eventual consistency, and we simply
operate around it. :-)
Think about a supermarket: If the store is open 24/7, prices change
constantly, and some items still have the old price tag until
shelves get refreshed. The system converges over time.
Or airlines: They must overbook, because if they wait for perfect
certainty, planes fly half empty. They accept inconsistency and
correct later with compensation.
Even banking works this way. All database books have the usual
âyou canât debit twice, so you need transactionsââ¦bullshit.
But think of a money transfer across banks and possibly across
countries? Not globally atomic...
What if you transfer money to an account that was closed an hour
ago in another system? The transfer doesnât instantly fail
everywhere. Itâs posted as credit/debit, then reconciliation runs
later, and you eventually get a reversal.
Same with stock markets: Trades happen continuously, but final
clearing and settlement occur after the fact.
And technically DNS is eventual consistency by design. You update a
record, but the world sees it gradually as caches expire. Yet the
internet works.
Distributed systems arenât broken when theyâre eventually
consistent. Theyâre mirroring how real systems work: commit
locally, reconcile globally, compensate when needed.
awesome_dude wrote 6 hours 40 min ago:
> Even banking works this way. All database books have the usual
âyou canât debit twice, so you need
transactionsââ¦bullshit. But think of a money transfer across
banks and possibly across countries? Not globally atomic..
Banking is my "go to" anology when it comes to eventual
consistency because 1: We use banking almost universally the same
ways, and 2: we understand fully the eventual consistency
employed (even though we don't think about it)
Allow me to elaborate.
When I was younger we had "cheque books" which meant that I could
write a cheque (or check if you're American) and give it to
someone in lieu of cash, they would take the cheque to the bank,
and, after a period of time their bank would deposit funds into
their account, and my bank would debit funds from mine - that
delay is eventual consistency.
That /style/ of banking might have gone for some people, but the
principle remains the same, this very second my bank account is
showing me two "balances", the "current" balance and the
"available" balance. Those two numbers are not equal, but they
will /eventually/ be consistent.
The reason that they are not consistent is because I have used my
debit card, which is really a credit arrangement that my bank has
negotiated with Visa or Mastercard, etc. Whereby I have paid for
some goods/services with my debit card, Visa has guaranteed the
merchant that they will be paid (with some exceptions) and Visa
have placed a hold on the balance of my account for the amount.
At some point - it might be overnight, it might be in a few days,
there will be a reconciliation where actual money will be paid by
my bank to Visa to settle the account, and Visa will pay the
merchant's bank some money to settle the debt.
Once that reconciliation takes place to everyone's satisfaction,
my account balances will be consistent.
kukkeliskuu wrote 4 hours 46 min ago:
I have been working on payment systems and it seems that in
almost all discussions about transactions, people talk about
toy versions of bank transactions that have very little to do
with what actually happens.
You don't even need to talk about credit cards to have multiple
kinds of accounts (internal bank accounts for payment
settlement etc.), multiple involved systems, batch processes,
reconciliation etc. Having a single atomic database transaction
is not realistic at all.
On the other hand, the toy transaction example might be useful
for people to understand basic concepts of transactions.
arter45 wrote 2 hours 2 min ago:
I don't have a lot of payment experience, but AFAIK actual
payment systems work in an append-only fashion, which makes
concurrency management easier since you're just adding a new
row with (timestamp, from, to, value, currency, status) or
something similar. However, how can you efficiently check for
overdrafts in this model? You'd have to periodically sum up
transactions to find the sender's balance and compare it to a
known threshold.
Is this how things are usually done in your business domain?
mrkeen wrote 3 hours 58 min ago:
And then they take that toy transaction model and think that
they're on ACID when they're not.
Are you stepping out of SQL to write application logic? You
probably broke ACID. Begin a transaction, read a value (n),
do a calculation (n+1), write it back and commit: The DB
cannot see that you did (+1). All it knows is that you're
trying to write a 6. If someone else wrote a 6 or a 7 in the
meantime, then your transaction may have 'meant' (+0) or
(-1).
Same problem when running on reduced isolation level (which
you probably are). If you do two reads in your
'transaction', the first read can be at state 1, and the
second read can be at state 2.
I think more conversations about the single "fully
consistent" db approach should start with it not being
fit-for-purpose - even without considering that it can't
address soft-modification (which you should recognise as a
need immediately whenever someone brings up soft-delete) or
two-generals (i.e. consistency with a partner - you and VISA
don't live in the same MySql instance, do you? Or to put it
in moron words - partitions between your DB and VISA's DB
"don't happen often" (they happen always!))
fishstamp82 wrote 1 hour 19 min ago:
RE: "All it knows is that you're trying to write a 6. If
someone else wrote a 6 or a 7 in the meantime, then your
transaction may have 'meant' (+0) or (-1)."
This is not how it works at all. This is called dirty
writes and is by default prevented by ACID compliant
databases, no matter the isolation level. The second
transaction commit will be rejected by the transaction
manager.
Even if you start a transaction from your application, it
does not change this still.
awesome_dude wrote 4 hours 13 min ago:
The point is to give people who don't realise that they have
been dealing with eventual consistency all along, that it's
right there, in their lives, and they already understand it.
You're right I go into too much detail (maybe I got carried
away with the HN audience :-) and you are right that multiple
accounts is something else that people generally already
understand and demonstrate further eventual consistency
principles.
kukkeliskuu wrote 3 hours 41 min ago:
I wasn't criticizing you, just making the point that when
people talk about toy example bank transactions, they
usually want to just introduce the basic understanding. And
I think it ok, but I would prefer that they would also
mention that REALLY the operations are complex.
I modified my comment above that by multiple types of
accounts I meant that banks have various accounts for
settlements with the other banks etc. even in the common
payment case.
da_chicken wrote 4 hours 57 min ago:
No, this is confusing how the financial institutions operate as
a business with how the data store that backs those
institutions operates as a technology.
You can certainly operate your financial system with a double
entry register and delayed reconciliation due to the use of
credit and the nature of various forms of promissory notes, but
you're going to want the data store behind the scenes to be
fully consistent with recording those transactions regardless
of how long they might take to reconcile. If you don't know
that your register is consistent, what are you even reconciling
against?
What you're arguing is akin to arguing that because computers
store data in volatile RAM and that data will often differ from
what is on disk, that you shouldn't have to worry about file
system consistency or the integrity of private address spaces.
After all, they aren't going to match anyways.
awesome_dude wrote 4 hours 15 min ago:
No.
I clearly state
> analogy (sorry about the initial misspell) when it comes to
eventual consistency because 1: We use banking almost
universally the same ways, and 2: we understand fully the
eventual consistency employed (even though we don't think
about it)
The point is, you understand that your bank account is
eventually consistent, and I have given an explanation of
instances of eventual consistency that you already usually
know and understand.
You make the mistake of thinking about something else (the
back end storage, the double entry bookeeping).
onethumb wrote 10 hours 41 min ago:
Probably needs a (2010) label. Great article, though.
redwood wrote 10 hours 54 min ago:
This is why the winning disturbed systems optimize for CP. It's worth
preserving consistency at the expense of rare availability losses
particularly on cloud infrastructure
pyrolistical wrote 3 hours 49 min ago:
Also, giving up on availability doesnt imply we will be down for a
longtime. Itâs just some requests might get dropped. As long as the
client knows the request was rejected they can try later.
wippler wrote 10 hours 56 min ago:
FYI. This was written in 2010 although it feels relevant even now.
Didn't catch it until the mention of Amazon SimpleDB.
redwood wrote 10 hours 53 min ago:
Indeed I was wondering for a moment if amazon had decided to double
down on it
sethev wrote 10 hours 56 min ago:
Normally, I'm not a fan of putting the date on a post. However, in this
case, the fact that Stonebraker's article was published in 2010 makes
it more impressive given the developments over the last 15 years - in
which we've relearned the value of consistency (and the fact that it
can scale more than people were imagining).
alecco wrote 2 hours 42 min ago:
Papers by Stonebraker on that:
"What goes around comes around" (2005) [1] "What Goes Around Comes
Around... And Around..." (2024) [2] (ft Andy Pavlo)
Or video (2025)
URI [1]: https://web.eecs.umich.edu/~mozafari/fall2015/eecs584/papers...
URI [2]: https://dl.acm.org/doi/pdf/10.1145/3685980.3685984
URI [3]: https://www.youtube.com/watch?v=8Woy5I511L8
nine_k wrote 11 hours 7 min ago:
In short: eventual consistency is insufficient in many real-world error
scenarios which are outside the CAP theorem. Go for full consistency
where possible, which is more practical cases than normally assumed.
candiddevmike wrote 10 hours 10 min ago:
But full consistency isn't web scale! There are a lot of times where
full consistency with some kind of cache in front of it has the same
client quirks as eventually consistency though.
As always, the answer is "it depends".
DeathArrow wrote 4 hours 31 min ago:
>But full consistency isn't web scale!
But /dev/null is!
sgarland wrote 7 hours 14 min ago:
Did you unironically use the term âweb scaleâ in reference to a
database?
DIR <- back to front page