Todo mundo conhece Redis como "aquele cache rápido". E tá certo , é absurdamente rápido. Mas usar Redis só pra cache é como comprar uma Ferrari pra ir na padaria.
O básico que ninguém lembra
Redis é single-threaded. "Mas isso não é ruim?" Não. É genial.
Sem locks, sem race conditions, sem aquela dor de cabeça de concorrência. Cada comando é atômico por design. Quando você entende isso, começa a ver possibilidades em todo lugar.
Rate Limiting em 3 linhas
Precisa limitar 100 requests por minuto por usuário?
MULTI INCR rate:user:123 EXPIRE rate:user:123 60 EXEC
Se INCR retornar > 100, bloqueia. É isso. Sem biblioteca, sem banco, sem estado no app.
A sacada é o EXPIRE , a key se auto-destrói. Você não precisa limpar nada. O Redis cuida da sua bagunça.
Filas sem Kafka
"Mas eu preciso de uma fila!" Não, você provavelmente não precisa de Kafka. Você precisa de:
# Producer LPUSH queue:emails "{\"to\":\"x@y.com\",\"subject\":\"oi\"}" # Consumer (bloqueia até ter algo) BRPOP queue:emails 0
BRPOP é blocking pop , o consumer fica esperando até aparecer trabalho. Sem polling, sem CPU desperdiçada, sem Zookeeper.
Para quando isso é suficiente? Quando você não precisa de:
- Replay de mensagens
- Múltiplos consumers no mesmo item
- Persistência de longo prazo
Spoiler: isso cobre 80% dos casos.
Pub/Sub pra pobres (que funciona)
Quer notificar todos os servidores quando um usuário faz logout?
# Quem escuta SUBSCRIBE user:logout # Quem publica PUBLISH user:logout "user:123"
Todas as instâncias conectadas recebem. Não persiste, não garante entrega , mas pra invalidação de cache distribuído é perfeito.
Sorted Sets são magia negra
Ranking de jogadores:
ZADD leaderboard 1500 "player:1" ZADD leaderboard 2300 "player:2" ZADD leaderboard 1800 "player:3" # Top 10 ZREVRANGE leaderboard 0 9 WITHSCORES # Posição do player:1 ZREVRANK leaderboard "player:1"
Complexidade? O(log(N)) pra inserção, O(log(N)+M) pra range. Tenta fazer isso em PostgreSQL com milhões de registros e vem chorar.
O pattern que salvou minha sanity
Distributed locking com SET NX EX:
SET lock:resource:123 "owner:abc" NX EX 30
NX= só seta se não existirEX 30= expira em 30 segundos (deadlock protection)
Retornou OK? Você tem o lock. Retornou nil? Alguém já tem, espera ou desiste.
Quando NÃO usar Redis
- Dados que não cabem em memória (duh)
- Queries complexas com JOINs
- Quando você precisa de ACID de verdade
- Persistência como fonte primária de verdade (pode, mas é arriscado)
TL;DR
Redis não é "só cache". É uma estrutura de dados distribuída, atômica e estupidamente rápida.
Se você tem um problema que envolve contadores, filas, rankings, locks ou estado temporário , Redis provavelmente resolve em uma fração do código que você escreveria com outras ferramentas.
Leia a documentação de comandos. Sério. É uma das melhores docs que existe.