banco-de-dados
Redis
Redis em entrevista testa uso além de 'cache de chave-valor': as estruturas (hash, sorted set para ranking e rate limiting, listas para fila), estratégias de cache (cache-aside, write-through) e a parte difícil — invalidação, thundering herd, e o que acontece quando a memória enche (políticas de eviction). Persistência RDB x AOF e o trade-off de durabilidade.
Tópicos por senioridade
Desafios práticos
Cenários reais pra resolver em voz alta, como numa entrevista de verdade — não é múltipla escolha.
- Cache-aside, TTL e o thundering herd
Descreva o padrão cache-aside com Redis e o problema do 'thundering herd' quando uma chave popular expira.
Perguntas mais cobradas
ver todas →- Médio
Redis não é só chave-valor: as estruturas
String (cache, INCR), Hash (objeto por campos), List (fila), Set (dedupe/conjuntos), Sorted Set (ranking, rate limit por janela), Streams (log com consumer groups), HLL (contagem aproximada).
- Difícil
Cache-aside, TTL e o thundering herd
Cache-aside: app lê o cache, no miss busca no banco e grava com TTL; escrita invalida. Thundering herd: chave quente expira → todos dão miss juntos → pico no banco. Mitigue com lock, jitter no TTL, ou stale-while-revalidate.
- Médio
RDB x AOF: durabilidade no Redis
RDB: snapshot periódico, compacto e rápido de restaurar, mas perde as escritas desde o último. AOF: log de comandos, bem mais durável (~1s com fsync everysec), arquivo cresce e restart mais lento. Prod costuma usar os dois.
- Médio
Redis é single-thread — por que isso é uma vantagem (e o cuidado)
Um comando por vez → cada comando é atômico, sem lock. Rápido porque é RAM + O(1). Mas um O(N) grande (`KEYS *`, `SMEMBERS` de set gigante, Lua pesado) trava a thread e todos esperam — use `SCAN`.
- Difícil
`MULTI/EXEC` x script Lua pra atomicidade
`MULTI/EXEC`: enfileira comandos fixos (sem usar resultado de um no próximo); read-modify-write precisa de `WATCH` + retry. Lua (`EVAL`): roda atômico no servidor COM lógica (if, usa resultados) — idiomático pra rate limit e locks.
- Médio
Quando a memória enche: políticas de eviction
Ao bater maxmemory: `noeviction` faz writes falharem; `allkeys-lru`/`lfu` removem as menos usadas (escolha pra cache); `volatile-*` só mexem em chaves com TTL. Monitore `evicted_keys` — alto = instância pequena.