NoSQL Zone is brought to you in partnership with:

Alec is a Content Curator at DZone and lives in Raleigh, North Carolina. He is interested in Java and Android programming, and databases of all types. When he's not writing for the NoSQL and IoT Zones, you might find him playing bass guitar, writing short stories where nothing happens, or making stuff in Java. Alec is a DZone Zone Leader and has posted 579 posts at DZone. You can read more from them at their website. View Full User Profile

MongoDB & Bitcoin: How NoSQL Design Flaws Brought Down Two Exchanges

  • submit to reddit

On March 3rd, the Bitcoin exchange Flexcoin shut down after being hacked and catastrophically robbed. The hack was made possible, according to Emin Gün Sirer in this recent post on the topic, by a concurrency problem brought on by the use of NoSQL databases. To illustrate the problem, Sirer offers an analogy based on ATM withdrawals:

Now, consider what would happen if I duplicated my debit card, gave it to my best friend, synchronized our watches, and performed withdrawals at two different ATMs at the same time.

What's that I hear you say? Absolutely nothing bizarre would happen. My account would be deducted the right amount. That's because banks employ systems that guard against this kind of elementary error. They are based on transactions with ACID guarantees.

But if our bank was implemented using a first-generation NoSQL datastore, say MongoDB, we'd see something very different.

Hacked websites and flawed code are not necessarily notable events, but this one stands out, not only because of the quantity of the loss (896 BTC, according to Sirer), but because of the simplicity of the problem: These kinds of concurrency issues are well-known and there are numerous ways to get around them. From Sirer's point of view, the big problem is not this individual failure, but that these issues are built into NoSQL solutions:

Yes, yes, the broken-by-design apologists will trot out the usual refrain that goes "there is nothing wrong with MongoDB as long as you always deploy it knowing that it can give you back bogus answers." Yeah well, there is nothing wrong with flammable mattresses either, just make sure there is no source of ignition nearby. It just turns out that we then get charred family tragedies, because people are fallible.

And as it turns out, it wasn't just a fluke issue with Flexcoin. Sirer points to another Bitcoin exchange, Poloniex, which suffered from the same design flaw, and he even points to a possible third example as well. The scary part, Sirer suggests, is the built-in nature of the problem. This wasn't a burglars-picking-your-lock situation, after all; it's more like the door was left open. 

Check out Sirer's full post for more details on the collapse of Flexcoin and Poloniex, and for thoughts on how one might avoid such catastrophes even when using NoSQL databases.


Thomas Whitmore replied on Thu, 2014/05/01 - 5:16pm

Basic transactional processing, present in every SQL database & well support since the 1970s. But they chose to use a "trendy" alternative to solve a non-existent load problem.


Alex Popescu replied on Sat, 2014/05/03 - 3:15pm

Emin Gün Sirer’s post is great, but unfortunately he jumps to generalizations too fast. For both these cases it is not the database lack of ACID guarantees that led to the problems. It’s rather the… developers behind those apps.

Luca Cavagnoli replied on Thu, 2014/06/05 - 5:35am

No relational database with ACID properties would have same them from that flawed business process.

Comment viewing options

Select your preferred way to display the comments and click "Save settings" to activate your changes.