1

I need a way to solve double withdrawal attacks in decentralized databases.

For example, a banking infrastructure has multiple servers with their own databases, the advantage is that it lets citizens have quick withdrawals and low latency, with redundant data.

The disadvantage is that it allows double transaction attacks, meaning a citizen could go to two ATM's and withdraw at the exact same time, before the separate databases have reconciled.

How can this issue be solved and do these solutions have any specific names?

5

That's a scenario where eventual consistency is a totally unsuitable consistency model. You really want an ACID database that guarantees:

  • A transaction either has happened or has not happened.
  • After a transaction has been completed successfully, all reads will see the state after this transaction – the database accesses can be linearized as if there were a clear “before” and “after”, even though reads may happen from multiple DBs.

One way to implement this in a distributed system is that writes must first have completed in all databases before the writing database responds to the client with a success. If the distributed databases receive two transactions that modify the same values, one or both will fail and will be rolled back.

In practice, it is highly inconvenient to use a distributed system where consistency is very important. Instead, a master/backup system is much simpler to build: all write requests go to a single database that mirrors the writes to the other DBs in the cluster. A write is only marked as completed after the write has been synced to all backups. Read requests can be answered from all DBs in the cluster. If the master fails, any of the backup DBs can be promoted to the new master.

  • Thanks, so basically unless the writable distributed databases have a faster and lower latency link, it defeats the purpose of having writable distributed databases. – mateos Mar 4 '18 at 16:10
  • @Albert Distributed systems are always more complicated and usually slower than centralized systems. So you shouldn't use distributed systems without a good reason. The ability to quickly fail over to a new master may be such a reason, or the ability to answer more read requests simultaneously. You can't really have quick writes AND consistent data AND a distributed system at the same time. – amon Mar 4 '18 at 16:14
  • 1
    Not entirely correct - there are many different consistency models in between strict and eventual. Likewise there are different locking models not just master or lock-all, for example you can have majority vote requiring n/2 + 1 of quorum or even less 2sqrt(n) votes for matrix type of quorum, neither needs master shard and either can be strict. However, fully agree that beefy single db is the most convenient solution. – wondra Mar 5 '18 at 6:42

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.