When it comes to caching solutions for distributed systems, Memcached and Redis are two of the most popular open-source options. Both are designed to handle in-memory caching and are performant solutions. However, each has its distinct characteristics, strengths, and use cases. This post will compare Memcached vs Redis in detail to help you decide which is best for your application needs.
Pre-requisites:
To ensure this post is useful for you, it’s expected that you already know about the following:
- What is caching in general,
- What is distributed caching? What is the difference between local and distributed cache?
- You are specifically looking for a distributed caching solution.
With that out of the way, let’s start by looking at each definition.
Memcached:
Memcached is a high-performance, distributed memory object cache for storing small chunks of data(more specifically, 1MB). It is often used to cache frequently accessed data, such as database query results, API responses, and static content. Memcached is very fast and can handle a large number of concurrent requests.
Released: 2003
Primary Use-case: Simple key-value store for caching
Programming Language: C
License: BSD License
Redis:
ReDiS (Remote Dictionary Server) is an open-source, in-memory data structure store that can be used as a database, cache, message broker, and queue. While it is also pretty good at caching, like Memcached, it offers many additional features and capabilities beyond that.
Released: 2009
Primary Use-case: Key-value store with rich data structures and more advanced features(e.g. pub/sub, persistence layer)
Programming Language: C
License: BSD License
Memcached vs Redis:
As we just learned, Redis has several different use cases beyond caching; when comparing Redis to Memcached, we will try to keep the context as much as possible within the caching domain. Here’s AWS compares these two as part of their Elasticache solution:
However, to understand how each of them works as a caching solution under the hood, we should look into a few more characteristics in my opinion. Here are a few I think worth noting:
| Memcached | Redis | |
| Memory Fragmentation | Implementation is optimized for not having fragmentation | It does have memory fragmentation, and a built-in background process helps with de-fragmentation from time to time. |
| Eviction policy | Uses LRU | Redis supports several different policies, including LFU. |
| Persistence | Memcached doesn’t have any persistence capability. All data are gone if the server restarts. | Redis has support for configurable persistence layer |
| Vertical Scalability | It can be scaled vertically utilizing its multi-threaded architecture simply by adding more CPU/Memory to the server instance. | Vertical scaling can be achieved by having multiple instances of ReDiS on the same server (due to its single-threaded architecture). |
| Horizontal Scalability | While providing flexibility and no theoretical limitation, it is entirely up to the user/developer to achieve the desired horizontal scalability with customized client implementation. | Most horizontal scalability aspects are provided by ReDiS, thus providing better support with minimal configurations/developer effort |
| Availability | Without proper replication implemented, Memcached can suffer from availability loss. | With support from ReDis Clustering, high availability can be achieved without much effort. |
This guide aims to be a bit concise and provide you with a concise view of these different characteristics. Here’s another resource link that could help you with a lot more internal details on some of these.
When to use Memcached:
- A simple and high-speed caching solution for small chunks of volatile data with minimal overhead.
- Low-effort vertical scaling suits the required use case (Leveraging multi-threading for CPU/resource optimization).
When to use Redis:
Basically, it is in all use cases other than what was mentioned above for Memcached. But, in general, scenarios like the following would make it a no-compromise hard choice over Memcached:
- More than 1MB of data is needed to be cached.
- Need other complex data structures support.
- Use cases beyond simple caching: persistence, pub/sub, transactions, etc.
So, When should you use which?
The information provided so far should be sufficient to make an informed decision for your use cases. However, a more opinionated TL;DR version:
If you are a beginner and/or starting a new project that requires a general-purpose distributed caching solution, IMHO, it’s probably better to start with a managed ReDiS solution unless you have a specific use case in mind that demands otherwise.
That being said, I would also be curious to hear if you have a different opinion/thoughts, if there are any additional considerations worth mentioning, etc. Please feel free to comment below.
Leave a Reply