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



Redis-Based MOM: Redis for Processing Payments

Santosh Kumar:

As you work more with Redis you soon start finding yourself building out workflows, i.e. small pieces of code that talk to each other via Redis. For someone familiar with a Service Oriented approach to building systems this should feel like deja-vu. Except, instead of using a protocol (HTTP, TCP, UDP, AMQP, ZeroMQ) we are going back to CS101 using a good old queue datastructure.

I think instead of workflows and Service Oriented, the right term is message services or MOM. Indeed, Redis’ blocking queues, the corresponding commands, and PUB/SUB support provides one with the basic building blocks of message services. But these are useful only if you don’t need specialized solutions (RabbitMQ, ActiveMQ, etc.) which will provide solutions for more complicated scenarios.

Later in the post, Kumar mentions implementing transactions for the scenario he picked, payment processing, using Redis’ multi-exec. If things haven’t changed radically lately, I’d underline the fact that Redis MULTI/EXEC/DISCARD is just a batched serialized executor and not ACID transactions.

Original title and link: Redis-Based MOM: Redis for Processing Payments (NoSQL database©myNoSQL)