En elogio de memcached

Artículo original ↗ Discusión en Hacker News ↗

El diseño minimalista de clave–valor en memoria de memcached se contrasta con el conjunto de funciones más rico de Redis/Valkey, que mezcla caché con estructuras de datos persistentes, clustering y tipos de datos avanzados. Los comentaristas argumentan que la flexibilidad de Redis a menudo lleva a los equipos a usarlo mal como base de datos principal o a construir sistemas frágiles que asumen persistencia y disponibilidad perfecta, mientras que la ephemeridad estricta de memcached puede imponer patrones más seguros de “solo caché”, aunque con sus propias peculiaridades operativas. Muchos concluyen que la elección correcta depende del contexto: los sistemas pequeños o simples a menudo pueden apoyarse en la base de datos principal o en una caché básica, mientras que las arquitecturas más grandes deben sopesar rendimiento, complejidad, coste de la RAM y el riesgo de sobrediseñar su capa de caché.

Acusaciones escritas por IA y metadiscusión

  • Varios comentaristas objetan la afirmación refleja de “esto está escrito por IA”, calificándola de poco valor y ahora común en HN.
  • Otros creen que el artículo “se lee como IA” o que al menos fue pulido por un LLM, pero no hay consenso ni pruebas, y algunos señalan formulaciones informales concretas como improbables en un LLM.

Redis vs Memcached como tecnologías de caché

  • Muchos coinciden en que Redis funciona bien como caché, pero necesita una configuración cuidadosa: imponer expiraciones, desactivar o separar la persistencia, establecer maxmemory y la política de expulsión, y evitar estructuras complejas para objetos en caché.
  • Un tema importante: Redis intenta ser a la vez un almacén persistente y una caché volátil; esa dualidad facilita el mal uso (por ejemplo, tratarlo como una base de datos duradera, olvidar la expulsión).
  • Memcached es elogiado por ser “aburrido”, simple, puramente efímero y más difícil de mal usar como almacenamiento. Su falta de clustering y de funciones se ve como una virtud por algunos y una limitación por otros.

Problemas operativos y modos de fallo

  • Incidentes reportados de Redis/Valkey: sin expulsión, lo que lleva a OOM; fallos de escritura de AOF por disco lleno; aplicaciones que asumen que Redis siempre está disponible y poblado, sin plan alternativo.
  • A algunos les gusta el modelo de memcached de “fail open” (null ante un fallo → recomputar), otros creen que el fallo silencioso es peligroso y prefieren errores explícitos.
  • La asignación de slabs de memcached puede causar “slab starvation” y requiere ajustes; esto se cita como una complejidad oculta.

Rendimiento, complejidad y alternativas

  • Se afirma que memcached es significativamente más rápido para KV simples; las contraafirmaciones dicen que en el mundo real las diferencias pueden ser pequeñas y que la latencia de red domina.
  • Algunos sostienen que un SGBDR (p. ej., Postgres/MariaDB) con su propia caché es suficiente para la mayoría de las cargas; otros señalan que Redis es más simple que una base de datos completa y sobresale cuando está en la misma máquina.
  • Se debate entre Redis de un solo hilo y memcached multihilo; Redis puede detenerse ante operaciones complejas, mientras que memcached apunta a operaciones O(1) por diseño.

Casos de uso más amplios y deriva del ecosistema

  • Redis se usa más allá de la caché: limitación de tasa, flags de funcionalidad, pub/sub, backplanes de WebSocket, colas de trabajos, coordinación para tareas distribuidas.
  • Algunos prefieren separar responsabilidades: memcached (o BD+filesystem) para caché, y Redis con persistencia para funciones intensivas en estructuras de datos.
  • Hay críticas al crecimiento de funciones de Redis y a su marketing (incluida la posición sobre IA), y mención de Valkey y otros sistemas, pero sin consenso claro de que una herramienta “gane” en general.