Comparing distributed caching frameworks … Redis, Hazelcast and Memchached!!

“Comparing Redis, Hazelcast and Memchached to build a session caching mechanism for our web application using a cache store” would be more precise here! Before putting Redis for use in our production environment finally, we did take a look at two other caching systems. viz. Hazelcast and Memchached. While keeping our use-case in mind we dug deeper into the implementation using these three caching systems.


Hazelcast is a easy to use cache store. Bundle the necessary jars in your application and its ready for use within minutes; Thus making it to easy to kick off the development process without much effort. Its pretty fast too.
However accessing Hazelcast in client mode from the application turned out to be a bit different than we expected! Hazelcast does need a access to all the custom objects on the Hazelcast server side in order to perform the store/retrieve operations.
In-memory Hazelcast has no issues in this respect. Alternatively the data can be stored as byte array which is kinda extra work! Also it wouldn’t take null objects to be stored (minor of the problems!! and storing nulls is no great idea anyway!!)

The free version of the Hazelcast comes with monitoring support for up to two nodes. For anything more the enterprise edition needs to be purchased.
The monitoring UI (Management Center) in itself a handy tool which is definitely plus. However when it comes to client programs there aren’t many in terms of different flavours/languages. There are Java, Memcached and REST based clients available. Hazelcast cluster provide easy linear scalability by adding new nodes.

Other features include but not limited to, In-Memory Data Grid which adds dynamic scalability to the application, excellent at in-memory KV store and ability to work with Memcached, Hibernate and Spring Cache. Another nice feature to mention is broadcast messaging system provided through Hazelcast topics and Map/Reduce capability. Not to forget the excellent documentation. ( )


Memcached is high performance distributed caching system. It is quite generic in nature and works well with storing strings, objects etc. through key/value store.
It is, by design, a Least Recently Used(LRU) cache with every command order of O(1) complexity, which is great however having a use-case at hand to cache data with some kind of grouping, this doesn’t provide any APIs for grouping contents inside the store and other data structure support like Hazelcast or Redis. This way bulk APIs used for manipulating the cache store entries in a little more tweaking. In order to achieve this we built a custom ‘grouping’ implementation. It works nicely. But it also means few extra lines of code and bit of extra work every time a put or get called!!

There are many flavours Memcached clients written in many mainstream languages. With Memcached the capacity building is done by simply adding more nodes to cluster which intern add more muscle to the virtual pool of memory. ( )


Redis has a lot less of such restrictions. Considering all these various handy features, and when we try to apply in our scenario, we found ourselves leaning more towards Redis. Redis is fast KV cache, which provides Hash Ops provided which work nicely as multi-maps where we need to group our data per session. At the same time does not have any restrictions with respect to server side requirements.

And since being hosted on AWS, the AWS cloudwatch comes handy for monitoring purpose for the Elasticache/Redis! As AWS in use in many other places, going with AWS for Elasticache/Redis is convenient when it comes to operational overhead.

By design Redis is a single threaded server. A Redis cluster can be built having a Redis primary server and few read replicas to provide the backup and fail-over capabilities.

Just like others it has excellent documentation as well. The clients are available in numerous mainstream languages too.
So considering all these factors like – fitting solution for our use-case, ease of development and testing, less cost in terms of using additional AWS resource; it seemed like we have a right tool for our needs.
And also it has been a good learning experience knowing all these systems and putting Redis to use. ( )