Em elogio ao memcached

Acusações escritas por IA e metadiscussão

• Vários comentaristas se opõem à alegação reflexiva de “isso foi escrito por IA”, chamando-a de pouco valor e agora comum no HN.
• Outros acham que o artigo “soa como IA” ou ao menos foi polido por um LLM, mas não há consenso nem prova, e alguns apontam frases informais específicas como algo improvável vindo de um LLM.

Redis vs Memcached como tecnologias de cache

• Muitos concordam que o Redis funciona bem como cache, mas precisa de configuração cuidadosa: impor expirações, desativar ou separar a persistência, definir maxmemory e a política de eviction, e evitar estruturas complexas para objetos em cache.
• Um tema importante: o Redis tenta ser ao mesmo tempo um armazenamento persistente e um cache volátil; essa dualidade facilita o uso incorreto (por exemplo, tratá-lo como banco durável, esquecer a eviction).
• O memcached é elogiado por ser “sem graça”, simples, puramente efêmero e mais difícil de usar incorretamente como armazenamento. Sua falta de clustering e de recursos é vista por alguns como virtude e por outros como limitação.

Problemas operacionais e modos de falha

• Incidentes relatados com Redis/Valkey: ausência de eviction levando a OOM, falhas de escrita no AOF por falta de espaço em disco, aplicações assumindo que o Redis está sempre disponível e preenchido, sem fallback.
• Alguns gostam do modelo “fail open” do memcached (null em caso de falha → recomputar), enquanto outros acham falha silenciosa perigosa e preferem erros explícitos.
• A alocação de slabs do memcached pode causar “slab starvation” e precisa de ajuste; isso é citado como uma complexidade escondida.

Desempenho, complexidade e alternativas

• Há afirmações de que o memcached é significativamente mais rápido para KV simples; contrapontos dizem que, no mundo real, as diferenças podem ser pequenas e a latência de rede domina.
• Alguns argumentam que um SGBDR (por exemplo, Postgres/MariaDB) com seu próprio cache basta para a maioria das cargas; outros observam que o Redis é mais simples do que um banco completo e se destaca quando está no mesmo host.
• O Redis de thread única versus o memcached multithread é debatido; o Redis pode travar em operações complexas, enquanto o memcached mira operações O(1) por design.

Casos de uso mais amplos e deriva do ecossistema

• O Redis é usado além do cache: rate limiting, feature flags, pub/sub, backplanes de WebSocket, filas de jobs, coordenação de tarefas distribuídas.
• Alguns preferem separar responsabilidades: memcached (ou banco + filesystem) para cache, Redis com persistência para recursos que dependem de estruturas de dados.
• Há críticas ao excesso de recursos e ao marketing do Redis (incluindo o posicionamento em IA) e menção ao Valkey e a outros sistemas, mas não há consenso claro de que uma ferramenta “vence” no geral.