7 ms·

Data consistency is overrated

90 points by bo0tzz 4y ago

dgb23 4y ago
I needed to read this, but I'm not sure what to make of it yet. The reason is I've been struggling with the idea that (bi-) temporal, consistent data is great, as it provides a ton of leverage both for users and for auditing and debugging. For some problems it's the cleanest, general solution. What irks me that the code that validates, consumes, transforms and displays the data lives in its own time model (git). Philosophically you're not really looking into the past. You're looking at an echo of the past that's displayed in a current form. And more practically it's simply tough to draw the line between assuring that historical data is still handled and rendered correctly and getting rid of overhead and complexity of a growing and evolving application. The article talks about eventual consistency, but I really don't have these kinds of problems and when I do, I fully agree with the author as long as it's very clear to the user whether something is consistent and when it will be.
- refset 4y ago
  > practically it's simply tough to draw the line between assuring that historical data is still handled and rendered correctly and getting rid of overhead and complexity of a growing and evolving application Agreed, the issue of maintaining accurate data (bitemporal or otherwise) in the context of evolving schema and code feels like a real puzzle to solve with commonplace tools like git and SQL.
legulere 4y ago
Data consistency comes at a cost, but eschewing it does as well. Most of the time the performance impact of data consistency does not matter, potentially introducing heisenbugs in your system can come at a huge cost though.
- layer8 4y ago
  And also, eventual consistency means that you need to make sure that data eventually does become consistent, and not just give up on consistency.
  - kqr 4y ago
    How do you make sure of that? With atomic consistency guarantees you can "just" roll back the transaction -- nobody else would have seen any values contained in it. In an eventually consistent system some parts will have started building on the new values so you can't roll them back. You have to give up on consistency and achieve it only in a "best effort" sense.
bjornsing 4y ago
Durability is also overrated. Jokes aside, I’ve been responsible for a system that processed ~1 billion monetary transactions per day. Even with a fanatical focus on consistency and correctness it was still always off. With the philosophy promoted on the OP the chaos would have been complete… is my gut feeling at least.
- mousetree 4y ago
  Out of interest, what system processed 1 billion monetary transactions a day?
  - bjornsing 4y ago
    Bookkeeping / billing / analytics system for a high volume online API.
  - playingalong 4y ago
    High-frequency something would be my guess;)
- vidarh 4y ago
  Durability often is overrated. E.g. lets say your system is storing billing records for an API. Customers won't complain about being under-charged, so a loss of data for a system like that is fine as long as reducing the durability saves more money than it costs in losts ability to charge your customers. E.g. if rolling up and syncing summaries to disk every 10 seconds were to on average lose you 0.1% of records but cut your server cost for that system by 80%, it's a simple question of whether those server costs are higher or lower than .1% of your revenue (all numbers taken out of thin air). We make sacrifices in terms of both consistency and durability and all kinds of things all the time. The problem is that we often don't take the time to analyse what kind of inconsistency and loss is acceptable from a business point of view before designing a solution that often tries to aim for a level of consistency or durability that may not be needed. You can afford to sacrifice all kinds of guarantees as long as you have reliable models for how sacrificing them impacts you and your customers so that you know the sacrifices represent acceptable tradeoffs. The risk you're taking is that you're sacrificing safety margins, and so it's something you should only do if you understand both the domain and your systems failure modes very well.
gorbachev 4y ago
I once worked on a platform producing analytics using data that, at its source, was manually typed in by people. My product managers would insist we do distinct counts on the aggregates instead of using probabilistic algorithms, because we "needed" the absolute 100% accurate output. No matter how many times I would explain the data was never 100% accurate to begin with and that the error rate using HyperLogLog wouldn't make an ounce of difference, we never were allowed to do that. As a consequence the performance of the system when doing distinct counts on interactive queries was about 100x worse. This didn't seem to bother anyone. I never understood why.
- crazygringo 4y ago
  100x is not that big of a difference, and I've been burned by "clever" algorithms before because they weren't coded exactly right. Because if they drift into a broken state, nobody can tell. While a simple sum is unlikely to fail in subtle ways. There are benefits to simplicity. If there isn't a reason to need 100x faster performance, then why complicate things? That would be my why.
  - dgb23 4y ago
    That's a great point. But I want to add that anecdotally users do care about performance and they will often thank you for anything that is noticeable. Sometimes just because it feels nice, but it can also enable a fast feedback loop, which increases immersion and productivity. In a broader sense, we use computers not only because they can perform work autonomously but also because they are fast, correct and remember details almost perfectly.
- dgb23 4y ago
  I can imagine some reasons: - They don't care about performance and think their users don't care about performance. - They have sold something that doesn't make sense but sounds good. - They are afraid of their users. - Their users don't understand the problem you're describing or simply don't believe it. - The business domain of their users actually knows the about the issue, but they still want or need the exact counts.
- 4y ago
StreamBright 4y ago
Data consistency is overrated if your business is ok with that. Many businessed are not ok with that. Example: airline, booking process.
- fbdab103 4y ago
  Airlines are notorious for over-booking available seats and dealing with the fallout.
  - StreamBright 4y ago
    Which is done purposefully and not by data in-consistency at all.
    - macintux 4y ago
      I would wager, in complete ignorance of the real implementation, that the knowledge that they can overbook means that they can relax some of their requirements. If two servers can’t talk to each other to coordinate for a while, they could still each sell tickets.
    - esailija 4y ago
      No, it's because of CAP forces to make a compromise. If there was a way to be available and consistent there would not be overbooking. But they chose availability because losing sales is worse than dealing with overbooking. Exactly same with Amazon, they will not bother checking that the product is actually available because then you will miss the sale when the warehouse service is down or slow, which it would be all the time because it has to be a single place of failure. Its better to refund orders for non existent items than to miss sales. Consistency requires single source of truth which implies single place of failure. There is tremendous cost to it, it's not done for no reason like you say.
      - StreamBright 4y ago
        > there would not be overbooking. This is not the case at all. Airlines operate on the principle that a certain percentage of customers are no show. They would like to fly the planes fully booked so they allow some overbooking and they are controlling how much it gets overbooked. If it was up to CAP there would be 200% overbooking for certain flights and the airline would go bust within a year.
ddulaney 4y ago
I think there are two different kinds of consistency, and it's important to not conflate them. There's consistency that's internal to a system. Do all of the foreign keys line up correctly? Have I lost any data that was provided to me? Here, we can aspire to be 100% correct. I don't think the examples in this article conflict with that. Then there's consistency that's external to a system. This can be between this system and other systems, or between this system and reality. Did the operator enter the correct data for this item? Did the external system change and fail to tell me? Here there is no way to be 100% correct using only the tools that are inside the system. You need external audits, reality checks, periodic reconciliation. Critically, all of the author's examples are about external consistency (accounting matching reality; inter-system communication), but their conclusion seems to be that because external consistency can't be fully achieved, we should be OK to abandon internal consistency within single systems. I think that's too strong a conclusion.
- taeric 4y ago
  I think I agree with you. That said, internal and external are a touch inadequate. Specifically, for a large enough system, internal consistency will look more like external from a smaller system's perspective. To that end, it is all about costs. If the cost of keeping consistent is not above the budget, do so.
  - gfody 4y ago
    including unknowable cost/opportunity risk
- GauntletWizard 4y ago
  There's a ton of places where foreign keys are used wrong - deletion is acceptable, and good error handling for that case is the right thing to build anyway. That's one of the key arguments that nonconsistency advocates are arguing for. If you build a music playlist, the behavior of the program if the mp3 files referenced within should be to skip that track, not to crash. I've heard too many people arguing that they should be allowed to emit nasal demons if there's a data error, and they're wrong even in many well structured and tightly integrated datasets, but especially wrong in "web-scale" datasets
readthenotes1 4y ago
Wouldn't it be funny if the post changed every few hours?
- LAC-Tech 4y ago
  Does the post need multiple redundant copies with high write availability? Because a lot of data does.
aljungberg 4y ago
Within a closed system, consistency (and verifying it) is a fail fast mechanism. For example, it’s better to crash on a constraint failure when attaching a doodad to a non-existent user account than to figure out where all these orphan doodads came from next year.
LAC-Tech 4y ago
Wisdom from 40 years ago: Network partitioning can completely destroy mutual consistency in the worst case, and this fact has led to a certain amount of restrictiveness, vagueness, and even nervousness in past discussions, of how it may be handled. In some environments it is desirable or necessary to permit users to continue modifying resources such as files when the network is partitioned. A network operating system would be a good example. In such environments mutual inconsistency becomes a fact of life which must be dealt with. [0] TL;DR - you either store your data in one place, or you store it in multiple places but disallow writes when there's a network split and wait for consensus on all nodes... or you have inconsistency and you have to deal with it. [0] Detection of Mutual Inconsistency in Distributed Systems, 1983. Great paper, fairly readable, and still relevant. https://pages.cs.wisc.edu/~remzi/Classes/739/Fall2018/Papers/parker83detection.pdf https://pages.cs.wisc.edu/~remzi/Classes/739/Fall2018/Papers...
- deathanatos 4y ago
  > wait for consensus on all nodes... You can (e.g., using something like Raft) permit writes on the side of the netsplit that can establish quorum (if it exists), which is much less than all nodes.
  - LAC-Tech 4y ago
    Good point.
jeffwilcox 4y ago
FTX's Excel spreadsheet has entered the chat.
tiagobertolo 4y ago
Sounds like an excuse.
foota 4y ago
The problem with no consistency isn't the impact to users, but developers. If things can be inconsistent you need to worry about a whole new class of failure cases where data is inconsistent, and handle them correctly. Part of this is guarantees about correctness. Is there a bug that manifests even without inconsistency, or was there just some weird inconsistent state that caused an issue? If you don't have consistency you have to ask this about every single bug, making debugging problems much harder.
- cerved 4y ago
  One hundred percent agree
vvipgupta 4y ago
The same is true for data (aka gradients) consistency while training large ML models. Asynchronous SGD is as good (and maybe even faster) than synchronous SGD: https://papers.nips.cc/paper/2011/file/218a0aefd1d1a4be65601cc6ddc1520e-Paper.pdf https://papers.nips.cc/paper/2011/file/218a0aefd1d1a4be65601...
pyrale 4y ago
I'm a bit puzzled by the article. First off, I'm not sure whether they consider that eventual consistency is not consistency. Secondly, they quote a long example where business behaviour inherently results in inconsistent data. There is a significant difference between your system being robust enough to let inconsistent data exist, and to give the tools for business users to reconcile it, and a system that is not consistent iself, and lets the users deal with it. An illustration of this is text editing. If you simply share a text file with multiple people and let everyone edit, it'll be hard to avoid people overriding each other in a chaotic and destructive way. But if you use e.g. CRDTs, you give people the ability to each follow their train of thoughts, and to reconcile their versions later on. That example tends to show how valuable consistency is, and how important it is to build a system that lets users reconcile data if the business logic is not always consistent.
jongjong 4y ago
I find the example given by the author about financial inconsistency to be alarming. When you consider the fact that the monetary system is made up of large numbers of participants and all of them are constantly making small mistakes... Surely it can accumulate into significant discrepancies over time. Imagine that you create a multiplayer MMORPG video game with a 'limited' number of virtual gold coins and you set the supply at 1 billion gold coins and you decide to track account balances using 1000 different systems managed by different companies (which constantly credit and debit each other using different mechanisms) instead of just 1 system managed by 1 company... What are the odds that you will still have only 1 billion gold coins in circulation in one year's time? Surely at least 1 of the 1000 systems will go rogue and start inflating the currency supply; it may start sending fake coins to other systems and the other systems won't be able to know that they are fake since they all operate on mutual trust instead of cryptographic proofs, they will unwittingly propagate records of those fake coins to other systems as if they were real. This is essentially how the fiat monetary system works. The power of money creation is not supposed to be in the hands of private institutions, yet because currency is tracked across so many different systems and there is no universal consistency between them, money creation seems to be essentially guaranteed to occur; especially when you consider that the incentive is to turn a blind eye to errors which benefit large institutions.
- kqr 4y ago
  The power of money creation is in the hands of private institutions more explicitly than that. When a bank lends you money, they are just incrementing the money counter in your bank account. They cannot print bills, but they do for all practical intents create money. https://www.bankofengland.co.uk/explainers/how-is-money-created https://www.bankofengland.co.uk/explainers/how-is-money-crea...
- yxhuvud 4y ago
  A mmorpg would have user churn though, so even if it aquired more users to offset that the end result would be less coins in circulation. In other words: The system is already broken by design. Using a single consistent server would not change that. I also wonder why you think money creation isn't supposed to be in private hands. It needs to be regulated with enforcement, but at the end of the day it is the only reasonably efficient way to couple the productive ability of society with its consumption. The world revolves around promises. Not all will be kept, but the system as a whole is built to handle that and eventually resolve inconsistencies. That is also why autocratic and corrupt systems are so bad, they put the self correcting parts out of order.
BulgarianIdiot 4y ago
Data consistency is an aspiration which we achieve by many means, including pragmatic tolerance for inconsistency, when consistency is not possible and alternate mechanisms for handling it. Those mechanisms are almost always less efficient than consistency. So to say consistency is "overrated" is nonsense. It's not always 100% applicable, but this comes at a cost.
riknos314 4y ago
The important thing to consider is: What tradeoffs are required to achieve consistency for your use case? Delivering consistency in either the CAP or ACID sense requires some amount of constraints on other aspects of the system. Sometimes making this tradeoff it worth it, sometimes it isn't. The key is to make the value analysis for each problem you face so you can determine the best overall solution to the problem at hand.
ps1983 4y ago
Oh yes, because who needs consistency in their data anyway? Why bother making sure that the information we're basing our decisions on is accurate and reliable? Let's just mix up some numbers and hope for the best. I mean, what's the worst that could happen? It's not like incorrect data could lead to costly mistakes or missed opportunities. Let's just throw caution to the wind and see where inconsistency takes us. Who needs consistency when you can have chaos, right?

90 points by bo0tzz 4y ago

I needed to read this, but I'm not sure what to make of it yet. The reason is I've been struggling with the idea that (bi-) temporal, consistent data is great, as it provides a ton of leverage both for users and for auditing and debugging. For some problems it's the cleanest, general solution. What irks me that the code that validates, consumes, transforms and displays the data lives in its own time model (git). Philosophically you're not really looking into the past. You're looking at an echo of the past that's displayed in a current form. And more practically it's simply tough to draw the line between assuring that historical data is still handled and rendered correctly and getting rid of overhead and complexity of a growing and evolving application. The article talks about eventual consistency, but I really don't have these kinds of problems and when I do, I fully agree with the author as long as it's very clear to the user whether something is consistent and when it will be.

refset 4y ago
> practically it's simply tough to draw the line between assuring that historical data is still handled and rendered correctly and getting rid of overhead and complexity of a growing and evolving application Agreed, the issue of maintaining accurate data (bitemporal or otherwise) in the context of evolving schema and code feels like a real puzzle to solve with commonplace tools like git and SQL.

legulere 4y ago

Data consistency comes at a cost, but eschewing it does as well. Most of the time the performance impact of data consistency does not matter, potentially introducing heisenbugs in your system can come at a huge cost though.

layer8 4y ago
And also, eventual consistency means that you need to make sure that data eventually does become consistent, and not just give up on consistency.
- kqr 4y ago
  How do you make sure of that? With atomic consistency guarantees you can "just" roll back the transaction -- nobody else would have seen any values contained in it. In an eventually consistent system some parts will have started building on the new values so you can't roll them back. You have to give up on consistency and achieve it only in a "best effort" sense.

bjornsing 4y ago

Durability is also overrated. Jokes aside, I’ve been responsible for a system that processed ~1 billion monetary transactions per day. Even with a fanatical focus on consistency and correctness it was still always off. With the philosophy promoted on the OP the chaos would have been complete… is my gut feeling at least.

mousetree 4y ago
Out of interest, what system processed 1 billion monetary transactions a day?
- bjornsing 4y ago
  Bookkeeping / billing / analytics system for a high volume online API.
- playingalong 4y ago
  High-frequency something would be my guess;)
vidarh 4y ago
Durability often is overrated. E.g. lets say your system is storing billing records for an API. Customers won't complain about being under-charged, so a loss of data for a system like that is fine as long as reducing the durability saves more money than it costs in losts ability to charge your customers. E.g. if rolling up and syncing summaries to disk every 10 seconds were to on average lose you 0.1% of records but cut your server cost for that system by 80%, it's a simple question of whether those server costs are higher or lower than .1% of your revenue (all numbers taken out of thin air). We make sacrifices in terms of both consistency and durability and all kinds of things all the time. The problem is that we often don't take the time to analyse what kind of inconsistency and loss is acceptable from a business point of view before designing a solution that often tries to aim for a level of consistency or durability that may not be needed. You can afford to sacrifice all kinds of guarantees as long as you have reliable models for how sacrificing them impacts you and your customers so that you know the sacrifices represent acceptable tradeoffs. The risk you're taking is that you're sacrificing safety margins, and so it's something you should only do if you understand both the domain and your systems failure modes very well.

gorbachev 4y ago

I once worked on a platform producing analytics using data that, at its source, was manually typed in by people. My product managers would insist we do distinct counts on the aggregates instead of using probabilistic algorithms, because we "needed" the absolute 100% accurate output. No matter how many times I would explain the data was never 100% accurate to begin with and that the error rate using HyperLogLog wouldn't make an ounce of difference, we never were allowed to do that. As a consequence the performance of the system when doing distinct counts on interactive queries was about 100x worse. This didn't seem to bother anyone. I never understood why.

crazygringo 4y ago
100x is not that big of a difference, and I've been burned by "clever" algorithms before because they weren't coded exactly right. Because if they drift into a broken state, nobody can tell. While a simple sum is unlikely to fail in subtle ways. There are benefits to simplicity. If there isn't a reason to need 100x faster performance, then why complicate things? That would be my why.
- dgb23 4y ago
  That's a great point. But I want to add that anecdotally users do care about performance and they will often thank you for anything that is noticeable. Sometimes just because it feels nice, but it can also enable a fast feedback loop, which increases immersion and productivity. In a broader sense, we use computers not only because they can perform work autonomously but also because they are fast, correct and remember details almost perfectly.
dgb23 4y ago
I can imagine some reasons: - They don't care about performance and think their users don't care about performance. - They have sold something that doesn't make sense but sounds good. - They are afraid of their users. - Their users don't understand the problem you're describing or simply don't believe it. - The business domain of their users actually knows the about the issue, but they still want or need the exact counts.
4y ago

StreamBright 4y ago

Data consistency is overrated if your business is ok with that. Many businessed are not ok with that. Example: airline, booking process.

fbdab103 4y ago
Airlines are notorious for over-booking available seats and dealing with the fallout.
- StreamBright 4y ago
  Which is done purposefully and not by data in-consistency at all.
  - macintux 4y ago
    I would wager, in complete ignorance of the real implementation, that the knowledge that they can overbook means that they can relax some of their requirements. If two servers can’t talk to each other to coordinate for a while, they could still each sell tickets.
  - esailija 4y ago
    No, it's because of CAP forces to make a compromise. If there was a way to be available and consistent there would not be overbooking. But they chose availability because losing sales is worse than dealing with overbooking. Exactly same with Amazon, they will not bother checking that the product is actually available because then you will miss the sale when the warehouse service is down or slow, which it would be all the time because it has to be a single place of failure. Its better to refund orders for non existent items than to miss sales. Consistency requires single source of truth which implies single place of failure. There is tremendous cost to it, it's not done for no reason like you say.
    - StreamBright 4y ago
      > there would not be overbooking. This is not the case at all. Airlines operate on the principle that a certain percentage of customers are no show. They would like to fly the planes fully booked so they allow some overbooking and they are controlling how much it gets overbooked. If it was up to CAP there would be 200% overbooking for certain flights and the airline would go bust within a year.

ddulaney 4y ago

I think there are two different kinds of consistency, and it's important to not conflate them. There's consistency that's internal to a system. Do all of the foreign keys line up correctly? Have I lost any data that was provided to me? Here, we can aspire to be 100% correct. I don't think the examples in this article conflict with that. Then there's consistency that's external to a system. This can be between this system and other systems, or between this system and reality. Did the operator enter the correct data for this item? Did the external system change and fail to tell me? Here there is no way to be 100% correct using only the tools that are inside the system. You need external audits, reality checks, periodic reconciliation. Critically, all of the author's examples are about external consistency (accounting matching reality; inter-system communication), but their conclusion seems to be that because external consistency can't be fully achieved, we should be OK to abandon internal consistency within single systems. I think that's too strong a conclusion.

taeric 4y ago
I think I agree with you. That said, internal and external are a touch inadequate. Specifically, for a large enough system, internal consistency will look more like external from a smaller system's perspective. To that end, it is all about costs. If the cost of keeping consistent is not above the budget, do so.
- gfody 4y ago
  including unknowable cost/opportunity risk
GauntletWizard 4y ago
There's a ton of places where foreign keys are used wrong - deletion is acceptable, and good error handling for that case is the right thing to build anyway. That's one of the key arguments that nonconsistency advocates are arguing for. If you build a music playlist, the behavior of the program if the mp3 files referenced within should be to skip that track, not to crash. I've heard too many people arguing that they should be allowed to emit nasal demons if there's a data error, and they're wrong even in many well structured and tightly integrated datasets, but especially wrong in "web-scale" datasets

readthenotes1 4y ago

Wouldn't it be funny if the post changed every few hours?

LAC-Tech 4y ago
Does the post need multiple redundant copies with high write availability? Because a lot of data does.

aljungberg 4y ago

Within a closed system, consistency (and verifying it) is a fail fast mechanism. For example, it’s better to crash on a constraint failure when attaching a doodad to a non-existent user account than to figure out where all these orphan doodads came from next year.

LAC-Tech 4y ago

Wisdom from 40 years ago: Network partitioning can completely destroy mutual consistency in the worst case, and this fact has led to a certain amount of restrictiveness, vagueness, and even nervousness in past discussions, of how it may be handled. In some environments it is desirable or necessary to permit users to continue modifying resources such as files when the network is partitioned. A network operating system would be a good example. In such environments mutual inconsistency becomes a fact of life which must be dealt with. [0] TL;DR - you either store your data in one place, or you store it in multiple places but disallow writes when there's a network split and wait for consensus on all nodes... or you have inconsistency and you have to deal with it. [0] Detection of Mutual Inconsistency in Distributed Systems, 1983. Great paper, fairly readable, and still relevant. https://pages.cs.wisc.edu/~remzi/Classes/739/Fall2018/Papers/parker83detection.pdf https://pages.cs.wisc.edu/~remzi/Classes/739/Fall2018/Papers...

deathanatos 4y ago
> wait for consensus on all nodes... You can (e.g., using something like Raft) permit writes on the side of the netsplit that can establish quorum (if it exists), which is much less than all nodes.
- LAC-Tech 4y ago
  Good point.

jeffwilcox 4y ago

FTX's Excel spreadsheet has entered the chat.

tiagobertolo 4y ago

Sounds like an excuse.

foota 4y ago

The problem with no consistency isn't the impact to users, but developers. If things can be inconsistent you need to worry about a whole new class of failure cases where data is inconsistent, and handle them correctly. Part of this is guarantees about correctness. Is there a bug that manifests even without inconsistency, or was there just some weird inconsistent state that caused an issue? If you don't have consistency you have to ask this about every single bug, making debugging problems much harder.

cerved 4y ago
One hundred percent agree

vvipgupta 4y ago

The same is true for data (aka gradients) consistency while training large ML models. Asynchronous SGD is as good (and maybe even faster) than synchronous SGD: https://papers.nips.cc/paper/2011/file/218a0aefd1d1a4be65601cc6ddc1520e-Paper.pdf https://papers.nips.cc/paper/2011/file/218a0aefd1d1a4be65601...

pyrale 4y ago

I'm a bit puzzled by the article. First off, I'm not sure whether they consider that eventual consistency is not consistency. Secondly, they quote a long example where business behaviour inherently results in inconsistent data. There is a significant difference between your system being robust enough to let inconsistent data exist, and to give the tools for business users to reconcile it, and a system that is not consistent iself, and lets the users deal with it. An illustration of this is text editing. If you simply share a text file with multiple people and let everyone edit, it'll be hard to avoid people overriding each other in a chaotic and destructive way. But if you use e.g. CRDTs, you give people the ability to each follow their train of thoughts, and to reconcile their versions later on. That example tends to show how valuable consistency is, and how important it is to build a system that lets users reconcile data if the business logic is not always consistent.

jongjong 4y ago

I find the example given by the author about financial inconsistency to be alarming. When you consider the fact that the monetary system is made up of large numbers of participants and all of them are constantly making small mistakes... Surely it can accumulate into significant discrepancies over time. Imagine that you create a multiplayer MMORPG video game with a 'limited' number of virtual gold coins and you set the supply at 1 billion gold coins and you decide to track account balances using 1000 different systems managed by different companies (which constantly credit and debit each other using different mechanisms) instead of just 1 system managed by 1 company... What are the odds that you will still have only 1 billion gold coins in circulation in one year's time? Surely at least 1 of the 1000 systems will go rogue and start inflating the currency supply; it may start sending fake coins to other systems and the other systems won't be able to know that they are fake since they all operate on mutual trust instead of cryptographic proofs, they will unwittingly propagate records of those fake coins to other systems as if they were real. This is essentially how the fiat monetary system works. The power of money creation is not supposed to be in the hands of private institutions, yet because currency is tracked across so many different systems and there is no universal consistency between them, money creation seems to be essentially guaranteed to occur; especially when you consider that the incentive is to turn a blind eye to errors which benefit large institutions.

kqr 4y ago
The power of money creation is in the hands of private institutions more explicitly than that. When a bank lends you money, they are just incrementing the money counter in your bank account. They cannot print bills, but they do for all practical intents create money. https://www.bankofengland.co.uk/explainers/how-is-money-created https://www.bankofengland.co.uk/explainers/how-is-money-crea...
yxhuvud 4y ago
A mmorpg would have user churn though, so even if it aquired more users to offset that the end result would be less coins in circulation. In other words: The system is already broken by design. Using a single consistent server would not change that. I also wonder why you think money creation isn't supposed to be in private hands. It needs to be regulated with enforcement, but at the end of the day it is the only reasonably efficient way to couple the productive ability of society with its consumption. The world revolves around promises. Not all will be kept, but the system as a whole is built to handle that and eventually resolve inconsistencies. That is also why autocratic and corrupt systems are so bad, they put the self correcting parts out of order.

BulgarianIdiot 4y ago

Data consistency is an aspiration which we achieve by many means, including pragmatic tolerance for inconsistency, when consistency is not possible and alternate mechanisms for handling it. Those mechanisms are almost always less efficient than consistency. So to say consistency is "overrated" is nonsense. It's not always 100% applicable, but this comes at a cost.

riknos314 4y ago

The important thing to consider is: What tradeoffs are required to achieve consistency for your use case? Delivering consistency in either the CAP or ACID sense requires some amount of constraints on other aspects of the system. Sometimes making this tradeoff it worth it, sometimes it isn't. The key is to make the value analysis for each problem you face so you can determine the best overall solution to the problem at hand.

ps1983 4y ago

Oh yes, because who needs consistency in their data anyway? Why bother making sure that the information we're basing our decisions on is accurate and reliable? Let's just mix up some numbers and hope for the best. I mean, what's the worst that could happen? It's not like incorrect data could lead to costly mistakes or missed opportunities. Let's just throw caution to the wind and see where inconsistency takes us. Who needs consistency when you can have chaos, right?