ALL COVERED TOPICS

NoSQL Benchmarks NoSQL use cases NoSQL Videos NoSQL Hybrid Solutions NoSQL Presentations Big Data Hadoop MapReduce Pig Hive Flume Oozie Sqoop HDFS ZooKeeper Cascading Cascalog BigTable Cassandra HBase Hypertable Couchbase CouchDB MongoDB OrientDB RavenDB Jackrabbit Terrastore Amazon DynamoDB Redis Riak Project Voldemort Tokyo Cabinet Kyoto Cabinet memcached Amazon SimpleDB Datomic MemcacheDB M/DB GT.M Amazon Dynamo Dynomite Mnesia Yahoo! PNUTS/Sherpa Neo4j InfoGrid Sones GraphDB InfiniteGraph AllegroGraph MarkLogic Clustrix CouchDB Case Studies MongoDB Case Studies NoSQL at Adobe NoSQL at Facebook NoSQL at Twitter

NAVIGATE MAIN CATEGORIES

Close

Card Payment Sytems and the CAP Theorem

On the surface it would appear that building such a system would be easy since the card vault can be implemented in a data store (either RDBMS or noSQL store) and the data stores schema could be simple, containing just the PAN, token and perhaps some timestamp information. There are plenty of companies that have attempted to build their own card vaults and many vendors offering commercial products. However we shall see later in this article that designing a card vault it requires a distributed data store and a decision is needed on which compromises of the CAP Theorem your system is willing to accept.

Firstly a small correction to the original post: instead of “partition tolerance is not an option”, read “partition tolerance is not optional”.

One of the most frequently asked question about NoSQL databases is “how do they handle transactions. Like in a banking system”. I’ve never developed a banking system, so I don’t know how those work. But I’d bet most of those asking haven’t worked on one either. So why not asking about the solution a NoSQL database would require for the system you are actually working on.

Original title and link: Card Payment Sytems and the CAP Theorem (NoSQL database©myNoSQL)

via: http://superconductor.voltage.com/2011/12/tokenization-of-credit-card-numbers-and-the-cap-theorem.html