MongoDB & Bitcoin: How NoSQL Design Flaws Brought Down Two Exchanges
MongoDB & Bitcoin: How NoSQL Design Flaws Brought Down Two Exchanges
Join the DZone community and get the full member experience.
Join For FreeDownload Microservices for Java Developers: A hands-on introduction to frameworks and containers. Brought to you in partnership with Red Hat.
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.
Download Building Reactive Microservices in Java: Asynchronous and Event-Based Application Design. Brought to you in partnership with Red Hat.
Like This Article? Read More From DZone
Opinions expressed by DZone contributors are their own.
{{ parent.title || parent.header.title}}
{{ parent.tldr }}
{{ parent.linkDescription }}
{{ parent.urlSource.name }}