# Memcached for system design interviews > Memcached is an in-memory key-value cache for small, serialized values such as database rows, rendered fragments, and computed results. It reduces repeated work and database reads, but the application must tolerate missing entries, stale values, and cache failures. Source: https://sysround.com/tech/memcached Updated: 2026-11-05 ## How it works A Memcached server maintains a hash table that maps keys to cached items. Applications serialize values before writing them; Memcached treats those values as opaque bytes rather than querying fields or maintaining indexes. Memory is organized into slab classes with different chunk sizes. Items use a class large enough to hold their data and metadata, so allocated memory can exceed payload size. Slab allocation and reassignment affect how efficiently memory serves a changing item-size distribution. Expiration and eviction are separate mechanisms. An expired item is no longer returned, while memory pressure can evict an item before its TTL ends. Modern Memcached uses segmented LRU queues and background maintenance rather than one strict global least-recently-used list. Servers use event-driven networking and multiple worker threads. Commands include get, set, add, delete, increment, decrement, and compare-and-swap. Individual commands operate atomically on an item, but there are no general multi-key transactions. In a typical deployment, a client library selects the server for each key, often through consistent hashing. Memcached servers do not coordinate ownership or replicate entries to one another. Routing can also live in a proxy, but placement and failure behavior must be explicit parts of the design. ## What it gives you in a design - **Simple cache-aside integration.** Read the cache first, fetch from the database on a miss, and populate the cache with a TTL. The database remains authoritative, so losing cache entries should affect performance rather than correctness. - **Multi-key reads.** Multi-get retrieves several keys in one request to a server. A cluster-aware client groups keys by destination, reducing round trips without providing a consistent snapshot across keys. - **Conditional writes.** Add stores an item only if its key is absent, while compare-and-swap updates an item only if its CAS token still matches. These help coordinate cache updates, but do not create transactions with the database. - **Atomic numeric operations.** Increment and decrement update an existing unsigned integer value atomically on one server. They are useful for disposable counters, but eviction or server loss makes them unsuitable as authoritative accounting. - **Per-item expiration.** Entries can have different TTLs, allowing the application to trade freshness against backend load. A TTL is not a retention guarantee because an unexpired item can still be evicted. - **Bounded item storage.** The item-memory budget and eviction policy keep the cache from retaining data indefinitely. Capacity planning must include item metadata, slab waste, connections, and process overhead rather than treating all RAM as usable payload space. ## Scaling, replication and failure Partition keys across independent servers using a stable routing scheme. Consistent hashing reduces how many keys move when membership changes, but moved entries generally become misses rather than being automatically copied. Clients need a consistent view of membership to avoid routing the same key to different servers. Adding servers increases aggregate capacity and distributes work across different keys. It does not divide the load of one hot key: that key still maps to one owner. Local caches, request coalescing, or application-managed copies can reduce hot-key pressure, with additional freshness and invalidation costs. Ordinary Memcached deployments have no built-in replication or durable failover. A failed server causes errors or misses for its keys; removing it from routing can redistribute those keys and increase database traffic. Bound fallback concurrency, use short cache timeouts, and shed load rather than allowing every failed lookup to reach the database. Consistency between the cache and database is an application concern. Database-first writes followed by invalidation are common, but a concurrent reader can still refill an old value after invalidation. TTLs bound how long an entry can remain cached, not every possible source of staleness; stricter requirements may need version checks or bypassing the cache. ## Limits and defaults worth knowing - **Key length:** Keys are limited to 250 bytes. The text protocol also disallows spaces and control characters in keys. - **Maximum item size:** The default maximum item size is 1 MiB, configurable with the -I option. Account for key and item overhead, not just the serialized value. - **Expiration interpretation:** Expiration values up to 30 days are relative seconds. Larger values are interpreted as absolute Unix timestamps. Zero means no time-based expiration, but eviction can still occur. - **Default item-memory budget:** The default -m setting is 64 MiB for item storage and is configurable. Total process memory can exceed this amount. - **Atomicity boundary:** Single-item commands such as add, CAS, and increment are atomic on the owning server. There are no general multi-key transactions or atomic database-and-cache updates. - **Replication and durability:** Standard Memcached does not provide built-in server-to-server replication or durable-write guarantees. Applications must be able to reconstruct cached data. ## Use it when - Repeated reads of small objects or expensive query results are overloading the authoritative database. - The workload needs simple key lookups rather than server-side data structures, range queries, or indexing. - Cached values are reconstructible, and misses or bounded staleness are acceptable. - The design can explicitly handle cache outages, cold starts, and uneven key popularity. ## Avoid it when - The cached state would be the only copy of money balances, inventory reservations, jobs, or other durable business records. - The application needs multi-key transactions, durable coordination, or correctness-critical distributed locks. - The workload depends on rich data structures, server-side scripts, range queries, or secondary indexes. - Most entries are large, rarely reused, or invalidated before reuse, making cache memory and network costs hard to justify. ## What interviewers ask about it ### What happens when a Memcached node fails? Requests for its keys fail or become misses, depending on client behavior, and the server does not automatically promote a replica. Explain how routing changes, how much backend load the misses create, and how timeouts, concurrency limits, and load shedding protect the database. ### How do you prevent a cache stampede? Coalesce concurrent loads for the same key and jitter TTLs so unrelated keys do not expire together. For data that permits it, serve a stale value while one worker refreshes it, and bound refresh concurrency even if coordination fails. ### How do you keep cached values consistent with database writes? A common starting point is to commit the database write and then delete the cache entry. Call out the stale-refill race explicitly; use version-aware handling, a stronger invalidation protocol, or database reads where the required freshness cannot tolerate that race. ### Why use consistent hashing, and what does it not solve? It limits key remapping when servers join or leave compared with taking a hash modulo the server count. It does not replicate data, migrate cached values automatically, or spread a single hot key across servers. ### Can add with a TTL implement a distributed lock? It can provide a best-effort refresh lease, but eviction, expiration, and server failure can allow another worker to acquire the same key while the original worker is still running. Do not use it as the sole protection for correctness-critical operations; use authoritative transactional state or coordination with fencing. ### How would you size and monitor the cache? Estimate the useful working set from item counts, serialized sizes, metadata, and slab overhead, then measure actual memory use and evictions. Track hit rate by workload, backend requests caused by misses, latency, errors, and per-node skew rather than relying on one global hit-rate number. ## Common mistakes - Treating a TTL as a promise that an entry will remain available until it expires. - Assuming Memcached supplies replication, automatic ownership management, or durable storage. - Claiming database-first invalidation completely eliminates stale reads without examining concurrent cache fills. - Planning database capacity only for a warm cache and leaving cold starts or node failures unbounded. ## Alternatives - **Redis:** Choose it when the design needs richer data structures, scripting, or built-in replication and persistence options. Those features still require explicit reasoning about failover, consistency, and durability. - **In-process cache:** Choose it for very hot, small data when avoiding a network lookup matters and per-process duplication is acceptable. Invalidation and consistency across application instances become harder. - **Database-native optimization:** Prefer indexes, query changes, or materialized views when the main problem is inefficient queries or when an external cache would add unacceptable consistency complexity. - **CDN:** Choose it for cacheable HTTP responses and media that should be served near users. Memcached is a backend object cache, not a replacement for edge delivery. ## Interview questions where it comes up - [Design a distributed cache](https://sysround.com/questions/design-distributed-cache): Memcached provides a concrete reference for discussing key placement, bounded memory, eviction, and the consequences of having no built-in replication. - [Design a URL shortener like Bitly](https://sysround.com/questions/design-url-shortener): It can cache short-code mappings on the redirect path while exposing hot-key, invalidation, and database-fallback trade-offs. - [Design a news feed like Facebook](https://sysround.com/questions/design-news-feed): It can cache feed pages or hydrated post objects while durable storage remains responsible for rebuilding missing data. - [Design a weather app](https://sysround.com/questions/design-weather-app): It can cache geographically reusable forecasts with TTLs and refresh coalescing to reduce repeated external API calls. - [Design Wikipedia or Notion](https://sysround.com/questions/design-wikipedia): It can cache rendered pages or version-keyed document content while edits and permission changes require explicit invalidation rules. ## FAQ ### What is Memcached used for? Memcached stores temporary key-value data in memory to avoid repeated database reads or expensive computation. Common uses include cached objects, query results, and rendered page fragments. The application must still work correctly when entries disappear. ### What is the difference between Memcached and Redis? Memcached focuses on simple, disposable key-value caching. Redis offers richer data structures, scripting, and replication and persistence options. Choose based on required behavior and operational trade-offs rather than assuming either is universally faster. ### Is Memcached persistent or replicated? Standard Memcached should be treated as a disposable cache, with no built-in server-to-server replication or durable-write guarantee. Specialized storage and restart features do not make it an authoritative database. Keep the source data elsewhere and plan for cache loss. ## Related concepts - [Caching strategies](https://sysround.com/concepts/caching-strategies) - [Consistent hashing](https://sysround.com/concepts/consistent-hashing) - [Cache invalidation](https://sysround.com/concepts/cache-invalidation) - [Cache stampede and thundering herd](https://sysround.com/concepts/cache-stampede) - [Hot keys and hot partitions](https://sysround.com/concepts/hot-keys) --- SysRound (https://sysround.com) is an AI practice tool for system design interviews: a voice or typed AI interviewer, a shared whiteboard, then feedback on every skill and a model answer. Its feedback is AI-generated and can be wrong.