HN Debrief

In praise of memcached

  • Infrastructure
  • Databases
  • Open Source
  • Performance

The post makes a simple case for memcached over Redis or Valkey when the job is just caching expensive reads. The author’s point is not that Redis is bad. It is that Redis tries to be both a durable data store and a cache, and that mix invites teams to treat a cache like infrastructure they cannot lose. Memcached’s narrower design pushes you toward the healthier pattern. A miss is normal, fallback logic is mandatory, and the cache can disappear without taking the app down.

If you only need a disposable shared cache, treat that as a separate infrastructure choice and make it impossible for teams to smuggle durable state into it. If you already rely on Redis features like queues, rate limiting, or sorted sets, assume you are running a second data system and give it the same design and ops discipline as a database.

Discussion mood

Mostly supportive of the post’s core claim that memcached is a safer default for pure caching because its constraints reduce misuse. The main caveat was that Redis is not the root cause of bad architecture, and memcached can trigger the same distributed systems failures if teams depend on it too much or ignore its quirks.

Key insights

  1. 01

    Cache outages come from dependency mistakes

    The old memcached failure stories match the Redis ones almost exactly. Fleets got sized assuming the cache was always up, hot keys overloaded single nodes, and key invalidation triggered backend stampedes. That sharpens the post’s thesis. The win is not memcached itself. The win is designing the app so cache loss degrades gracefully instead of becoming a production incident.

    Test cold-cache and no-cache paths as first-class scenarios. Capacity-plan the backing store so a cache outage becomes slower service, not a cascading failure.

      Attribution:
    • shermantanktop #1
  2. 02

    Memcached constrains latency by design

    Keeping every operation O(1) is not just an implementation detail. It removes a whole class of surprise pauses that come from Redis supporting richer commands with variable cost on a single-threaded core. For simple cache traffic, that predictability can matter more than feature depth.

    If your cache tier sits on a latency-critical path, prefer primitives with fixed-cost operations. Push anything involving scans, ranges, or heavier data structures out of that tier.

      Attribution:
    • nasretdinov #1
  3. 03

    Memcached has its own operational traps

    Its simplicity ends at the API boundary. Underneath, slab allocation and item size classes can create starvation and uneven eviction that operators eventually have to understand. Redis often feels simpler in practice because it hides that memory-management model, even if it is more featureful overall.

    Do not choose memcached assuming zero tuning forever. If your value sizes vary a lot, benchmark real workloads and learn how slab behavior affects hit rates and memory waste.

      Attribution:
    • dvt #1
    • foobarian #1 #2
    • gnz11 #1
    • functional_dev #1
  4. 04

    Safe Redis caching requires guardrails

    Redis can work well as a cache, but only if you actively force cache semantics onto it. Commenters called out mandatory expirations, maxmemory, an eviction policy like allkeys-lru, and avoiding partial updates to complex structures that can be evicted underneath you. Without those guardrails, teams drift into treating it as durable application state.

    If you keep Redis for caching, wrap the client and config so unsafe patterns are impossible by default. Review every nontrivial Redis data structure as if it were schema design, not just convenience code.

      Attribution:
    • kijin #1 #2
    • dvt #1
    • FridgeSeal #1
  5. 05

    You often do not need a network cache yet

    Several comments grounded the decision in scale and architecture, not fashion. A hot user lookup or shared session token can justify caching early, but many apps under moderate load do fine with Postgres tables, local caches, or sticky sessions. The pressure point is shared state and repeated expensive reads, not an arbitrary requests-per-second threshold.

    Add a shared cache only after identifying a specific hot path that it will relieve. Before that, exhaust simpler options that keep failure modes and operations inside systems you already run.

      Attribution:
    • calpaterson #1
    • hylaride #1
    • psadri #1
  6. 06

    Redis earns its keep outside caching

    The strongest case for Redis was not 'better cache' but 'useful coordination layer'. Atomic counters, distributed rate limiting, pub-sub, job queues, and small shared state across app servers are all natural fits. That makes the technology sticky, but it also means you should stop pretending it is just a cache when you rely on those features.

    Inventory every Redis use by role. Split pure cache workloads from coordination or durable-ish workloads so each can have the right config, failure expectations, and ownership.

      Attribution:
    • WJW #1
    • AussieWog93 #1
    • boesboes #1

Against the grain

  1. 01

    Redis is rock solid when used narrowly

    A few people rejected the framing that Redis itself is the problem. Used as a straightforward key-value store with sensible boundaries, it has been boring and reliable for years. The rough edges they had hit were in adjacent tools like Celery, not Redis, and the richer Redis feature set was still useful for counters and lightweight shared state.

    If your team already knows Redis and uses only a small subset well, switching to memcached may buy little. The bigger win may be cutting optional framework complexity around it.

      Attribution:
    • AussieWog93 #1 #2
    • msandford #1
  2. 02

    Two cache technologies can be worse

    One practical objection was simple tool sprawl. Even if memcached is cleaner for pure caching, many larger teams eventually need Redis features somewhere, and then you are operating both stacks. Some argued that once that happens, standardizing on Redis can be the lower-friction choice, especially since a cache-only Redis instance still needs different settings from a persistence-oriented one.

    Count operational overhead, not just technical purity. If Redis is already a core dependency, a second dedicated Redis deployment may be cheaper than introducing memcached as another platform surface.

      Attribution:
    • kylewpppd #1
    • calpaterson #1
    • teacpde #1
  3. 03

    RAM-only caching is getting expensive

    A cost-focused pushback was that pure in-memory caches are harder to justify as memory prices bite, especially in cloud environments and at large cache sizes. That weakens the nostalgic case for memcached as the obvious default, although one commenter noted memcached now has flash storage support too.

    Benchmark with infrastructure cost in mind, not just latency. For large caches, compare RAM-only designs against disk-backed or hybrid approaches before locking in architecture.

      Attribution:
    • freediddy #1
    • oftenwrong #1

In plain english

allkeys-lru ↩
A Redis eviction policy that can remove any key when memory is full, choosing the least recently used items first.
Celery ↩
A Python task queue system used for background jobs and distributed work execution.
key-value store ↩
A storage system that saves data as a lookup key paired with a value, like a dictionary or map.
memcached ↩
A simple distributed in-memory key-value cache designed for fast temporary storage without built-in persistence.
O(1) ↩
Constant-time complexity, meaning an operation takes about the same amount of time regardless of input size.
pub-sub ↩
Publish-subscribe messaging, where one component broadcasts messages and multiple subscribers receive them.
Redis ↩
An in-memory data store commonly used for caching, queues, counters, and other shared application state, with optional persistence to disk.
single-threaded core ↩
A system design where one main execution thread handles most command processing, so long operations can block others.
slab allocation ↩
A memory management approach used by memcached that groups items into fixed-size classes, which can improve speed but waste or strand memory when item sizes vary.
Valkey ↩
An open source fork of Redis that keeps the same basic model and command style.

Reference links

Caching internals and storage

Performance and architecture references