We use analytics cookies.We use cookies to analyze site traffic and improve your experience.
Loading...
System Design and AI Engineering, by Roni Das. 984 interactive lessons.
Start LearningIntermediate · Database Types & Storage
A simple, high-performance distributed memory caching system. Stores key-value pairs in RAM. Simpler than Redis but less feature-rich.
In short
Memcached is an open-source, in-memory key-value store that caches small chunks of data (strings or objects) in RAM so applications can read them in microseconds instead of querying a slower database. It is distributed across many servers, intentionally simple, and is most often used to cache database query results, rendered page fragments, and session data.
In short
Memcached is an open-source, in-memory key-value store that caches small chunks of data (strings or objects) in RAM so applications can read them in microseconds instead of querying a slower database. It is distributed across many servers, intentionally simple, and is most often used to cache database query results, rendered page fragments, and session data.
Learn it in the course
This page is the free part.
₹1,111 in India$25 everywhere elseonce, for the whole course
The System Design course covers Memcached across a run of lessons, not one page. These 3 alone are about 64 minutes of step-by-step reading, every one with a quiz.
The same big read multiplied a small GET by 1.3 on memcached and by 32 on Redis, from an identical 0.021 ms idle. Ten of sixteen pages stayed with a slab class nobody was using.
A shared cache is a network service, so how you call it matters far more than which product you picked.
Databases that live entirely in RAM, trading durability for speed measured in microseconds.
all part of
System Design Masterclass
770 lessons · about 287 hours · 18 free to read
₹1,111in India, by UPI
$25everywhere else, by PayPal
It is really nice and good Please join the course
You own this course
Continue with Memcachedpay once,
yours for life
Memcached is a cache that lives entirely in RAM. You give it a key and a value, it holds that value in memory, and the next time you ask for the same key it hands the value back without touching disk or a database. A read from Memcached typically takes well under a millisecond, while the same MySQL or PostgreSQL query it replaces might take 10 to 100 milliseconds.
It was created by Brad Fitzpatrick in 2003 to take load off the database behind LiveJournal. The design goal was deliberate simplicity: store opaque bytes under a string key, with an optional expiration time, and nothing else. There are no data types beyond raw blobs, no persistence to disk, no replication, and no querying. The core commands are set, get, delete, increment, and decrement.
Values are capped at 1 MB by default and keys at 250 bytes. If a value would be larger than 1 MB you are expected to split it or not cache it. This constraint keeps the memory allocator predictable and the whole system fast.
Each Memcached server holds an independent hash table in memory. The cluster is shared-nothing: servers do not talk to each other and do not know other servers exist. All of the intelligence about which server owns which key lives in the client library, not in the servers.
The client takes the key, hashes it, and uses that hash to pick one server out of the list it was configured with. Most modern clients use consistent hashing so that adding or removing one server only remaps a fraction of the keys instead of shuffling everything. This is why you scale Memcached by simply adding more boxes and more total RAM.
Inside one server, memory is managed with a slab allocator. Memcached carves RAM into pages, splits each page into fixed-size chunks (for example 96 bytes, 120 bytes, 152 bytes), groups pages with the same chunk size into a slab class, and stores each item in the smallest slab class that fits. When the cache is full it evicts items using an LRU policy, throwing out whatever was least recently used. Expired and evicted items are simply gone; there is no second tier and no recovery.
Memcached is also heavily multithreaded, so a single instance with many cores can serve hundreds of thousands of requests per second over its simple text or binary protocol on TCP or UDP.
Reach for Memcached when you have a read-heavy workload and a clear set of values that are expensive to compute but cheap to store as flat blobs: database query results, fully rendered HTML fragments, API responses, or login session objects. The classic pattern is cache-aside, where the app checks Memcached first, and on a miss reads the database, then writes the result back into the cache with a short expiry.
Its strength is also its limitation. Because it is just a flat key-value store, there are no lists, sets, sorted sets, counters with atomic guarantees beyond increment, pub/sub, or persistence. If your data vanishes when a node restarts, that has to be fine, because everything is volatile. Memcached is purely a cache, never a source of truth.
The honest comparison is with Redis. Redis has richer data structures, optional persistence, replication, and clustering built in, which is why many new projects start there. Memcached still wins in narrow cases: it is genuinely multithreaded so one large instance uses many cores well, its slab allocator can have lower memory overhead for large numbers of small uniform values, and its smaller feature surface means fewer ways to misuse it. Pick Memcached when you want a dumb, fast, horizontally scalable blob cache and nothing more.
Picture a product page that runs a join across orders and inventory to compute how many units are left. That query takes 40 milliseconds and runs on every page view. Under traffic of 5,000 views per second the database is doing 5,000 of those joins every second and falls over.
With Memcached in front, the app computes the result once, stores it under a key like inventory:product:12345 with a 30 second expiry, and serves the next 150,000 requests from RAM in under a millisecond each. The database now runs that join roughly once every 30 seconds per product instead of thousands of times per second.
The cost you accept is staleness: for up to 30 seconds the displayed count can be wrong. For a stock counter that is usually acceptable, and you can shorten the expiry or delete the key on writes to tighten it. That trade between freshness and load is the core decision in every cache, and Memcached makes it about as simple as it gets.
Ran one of the largest Memcached deployments ever, with thousands of servers holding terabytes of cached data; engineers published the McSqueal and mcrouter work to scale it.
Wikipedia
Uses Memcached to cache parsed article fragments and database query results so pages serve fast under heavy read traffic.
Amazon ElastiCache
Offers Memcached as a managed engine alongside Redis, so AWS users can spin up multithreaded cache clusters without running the servers themselves.
YouTube
Used Memcached early on to cache video metadata and reduce repeated reads against its MySQL backend.
Both are in-memory key-value caches, but Redis supports rich data types (lists, sets, sorted sets, hashes), optional disk persistence, replication, and pub/sub, while Memcached stores only flat string or blob values with no persistence. Memcached is multithreaded so one big instance uses many CPU cores, whereas core Redis is largely single-threaded. Choose Memcached for a simple high-throughput blob cache and Redis when you need data structures or durability.
No. Everything lives in RAM and is lost if the server restarts or crashes. Memcached is a pure cache, not a database, so you must always be able to rebuild any cached value from the underlying source of truth.
By default a single value can be at most 1 MB and a key at most 250 bytes. The 1 MB limit comes from the slab allocator design; you can raise it with the -I startup flag, but storing large objects in Memcached is discouraged and usually a sign you should cache something smaller.
The servers do not coordinate at all. The client library hashes the key and maps it to one server, typically using consistent hashing so that adding or removing a node only remaps a small share of keys. All cluster awareness lives in the client, not the servers.
It evicts existing items using a least-recently-used policy within each slab class to make room for new ones. Evicted and expired items are simply discarded with no warning, so a cache miss after eviction just sends the request back to the database.
Redis
An in-memory data store used as a cache, message broker, and database. Blazing fast because everything lives in RAM.
Caching
Storing frequently accessed data in a faster storage layer so you don't have to fetch it from the original (slower) source every time.
Document Database
A NoSQL database that stores data as flexible JSON-like documents. MongoDB and CouchDB let each document have a different structure.
Key-Value Store
The simplest NoSQL model: store data as key-value pairs. Blazing fast lookups by key. Redis, DynamoDB, and etcd are key-value stores.
Column-Family Store
A NoSQL database that groups columns into families, optimized for reading and writing large amounts of data across many machines. Cassandra and HBase use this model.
Graph Database
A database built for storing and querying relationships between entities. Nodes are entities, edges are relationships. Neo4j is the most popular.
This page explains the idea. The "Memcached" lesson builds it up step by step, with diagrams. It is part of the System Design Masterclass course, which has 770 lessons. 18 of them are free to read. You pay once and keep it for life, with no subscription.
Open the Memcached lessoncourse 1
From absolute beginner to principal engineer, drawn step by step.
Asked about Memcached in an interview?
Each question has why it is asked, a full answer, what the interviewer listens for, the follow-ups, the common mistakes and a diagram (268 diagrams in all). A PDF you keep, junior to staff level.
India: UPI, cards or netbanking through Razorpay. Elsewhere: card or PayPal. Download at once from My packs.
