先日のビットコイン取引所で発生した盗難事件を受けて，結果整合性(eventually consistent)データベースは果たして銀行業務に有用なのか，という議論が巻き起こっている。
2014年3月2日，プログラムコードの問題が原因で，Flexcoinは所有していたビットコインをすべて紛失した。攻撃者は，自分の口座のひとつから別の口座への送金要求を，同時に数千回発行した。さらに別の口座に対しても同じ操作を，すべてのビットコインが引き出されるまで繰り返したのだ。このような攻撃が可能だったのは，コードが複数の同時要求を処理するように書かれていなかったためだ。すべての送金処理は，残高が変更される前に実施された。残高がリアルタイムに更新されなければ，口座の残高が本当は０であったとしても。新たな要求を送信することが可能になる。その結果Flexcoinは，約50万ドルに相当する896BTCを失って業務を停止することになった。
同じことがその2日後，Poloniexでも起きたが，失ったビットコインが12.3パーセントに過ぎなかったため，同社は損失をカバーして何とか倒産を免れることができた。
コーネル大学准教授のEmin Gün Sirer氏は，ビットコイン損失の原因を結果整合性データストアに求めた，批判的なブログ記事を書いた。氏はNoSQLソリューションの中でもMongoDBやCassandra, Riakなどの名前を挙げた上で，次のような理由から銀行業務には脆弱に過ぎると指摘する。
この問題は，MongoDBの提供しているインターフェースやセマンティクスの設計が根本的に悪い(broken-by-design)ことに起因しています。CassandraやRiakを使ったとしても，状況に対した違いはありません。…
ビットコインは，分散システムの特異な暗黒時代と時を同じくして登場しました。CAP定理の誤った解釈によって理論武装した人々が，データベースの一貫性はもはや不可能だと考えていた頃です ...
ただしその頃のFlexcoinやPoloniexで，MongoDBが実際に使用されていたがどうかは分からない。さらにはSirer氏が，HyperDexの開発に関与していることも注意しておくべきだろう。HyperDexは，ACIDトランザクションをサポートするキーバリュー型データストアとして，前出のものとは競合関係にあるのだ。また，氏がMongoDBの設計を批判するのは今回が初めてではなく， １年程前にもMongoDBのフォールトトレランスの不完全さを主張したことがある。
議論はさておき，結果整合性データストアが銀行業務に適しているかどうかには熟考の価値がありそうだ。予想に違わず，Sirer氏の記事には数多くのコメントが付いた。特に重要と思われるものをいくつか紹介しよう。
jrp氏は，MongoDBの更新処理がデータベースレベルでアトミックに実行されていることを指摘する一方で，"その他のACIDの特性が意識されていない"点には同意している。
jakcharlton氏は，このケースでは結果整合性に問題はあるものの，"ACIDシステムがこの問題を解決するのではなく，単にアプリケーション側に押し付けるだけです。そちら側でまた，同じ問題が発生することになります。銀行業務は例題として使用するには不適切な分野であって，データベースにACIDが備わっていれば同時実行性に関する問題は解決する，という開発者の考え方が問題なのです。"
Alex氏はMongoDBを"トランザクションが必要な部分を除くすべての場所で使用しています。その他の部分には，仕事に対して適切な(MongoDB以外の)ツールを選んでいます。" 氏は，MongoDBを使うべきでない処理に使用したことが間違っている，という考えだ。
HyperDexの開発者であるRobert Escriva氏は，原因はプログラマにあるのではなく，結果整合性システムが銀行業務に使用できるという，一般的な認識に問題があると考えている。
問題はプログラマの理解にあるのではありません。結果整合性システムの使用を推奨しようという，間違った動きが人々に広がっています。そういった人たちは，"銀行で十分に使えるのなら，あなたにも十分なものです"という言い方で，それを正当化するつもりなのでしょう。これは危険な考え方です。
一日の業務が終わったアプリケーションは，不変量の集まりです。もしシステムで使用しているデータストアが信用に値しない機能のものであったら -- あるいはもっと酷く，大規模な修正が必要で，信頼性を得るために10万ドルのサポート契約が必要なものだったら -- こんなアプリケーションでは役に立たない，と開発業者を非難することになるでしょう。データベースベンダ(特にVCから数百万ドルのキャッシュ提供を受けているような)に対しては，もっと高いレベルを要求するのが当然です。
CAP定理を著したEric Brewer氏はかつて，銀行がATM運用に一貫性を任せているのは，分断状態における可用性の提供が目的だ，ということを書いている。ただしそれは，一度に引き出し可能な金額が極めて低く制限されているなど，十分な予防策が取られた上でのことだ。Webおよびモバイルの支払システムであるStripeについても述べておく必要があるだろう。開発者によるブログ記事のひとつによると，同システムはMongoDBを使用しているということなのだ。
結果整合性データストアは一般的な銀行業務に適切なものなのだろうか，あるいは，開発者がその限界を認識して，他の選択肢を探すべきなのだろうか？