Comparativo geral entre todas as soluções

Objetivos

Nesta aula você vai:

• Consolidar o panorama completo das soluções de cache e banco em memória
• Aplicar o teorema CAP como lente analítica
• Usar uma matriz de decisão para escolher a ferramenta certa em cada cenário

Conteúdo

O epílogo do módulo comparativo

Depois de examinar cada personagem individualmente — Redis, Valkey, Memcached, DragonflyDB, KeyDB e Aerospike — chegamos ao capítulo final em que todos ocupam o mesmo palco. Como em um romance de ficção científica, cada tecnologia representa uma resposta diferente à pergunta fundamental: o que você sacrifica quando exige velocidade?

Panorama das soluções

O teorema CAP aplicado

O teorema CAP (Brewer) afirma que um sistema distribuído só pode garantir simultaneamente duas de três propriedades:

• Consistency (Consistência) — todos os nós veem os mesmos dados ao mesmo tempo
• Availability (Disponibilidade) — toda requisição recebe resposta (não erro)
• Partition tolerance (Tolerância a partição) — sistema funciona mesmo com falha de rede entre nós

Em sistemas distribuídos reais (com partição de rede inevitável), a escolha é entre CP e AP:

                    Consistência (C)
                         ▲
                         │
              Aerospike  │  Redis/Valkey
              (sync rep) │  (sync rep)
                         │
    Partition ───────────┼─────────── Disponibilidade (A)
    Tolerance (P)        │
                         │
              AP systems │  Memcached
              (eventual) │  (sem replicação nativa)
                         │
                         ▼

Nota pedagógica: CAP é modelo de pensamento, não receita de bololo. Na prática, sistemas modernos oferecem níveis configuráveis de consistência (ex.: Redis WAIT, Aerospike strong vs eventual).

Matriz de decisão por caso de uso

Comparativo de performance (referência)

Valores ilustrativos em servidor 16 cores, 64 GB RAM, valores de 256 bytes:

Aerospike inclui persistência SSD. Redis com AOF everysec. Sempre benchmark no seu ambiente.

# Script de benchmark comparativo (executar contra cada instância)
for host in redis valkey keydb dragonfly memcached; do
  echo "=== $host ==="
  redis-benchmark -h $host -p 6379 -t get,set -n 100000 -q
  redis-cli -h $host --latency-history -i 1 | head -5
done

Comparativo de latência por percentil

Entender percentis é essencial para SLAs de produção:

Distribuição de latência (ilustrativa):

Frequência
    ▲
    │  ████
    │  ████████
    │  ████████████
    │  ████████████████▓▓▓▓░░  ← cauda longa (P99+)
    └──────────────────────────► Latência
         P50  P95  P99  P99.9

Regra de ouro: otimize para P99, não para média. Um P50 de 0,2 ms com P99 de 50 ms indica problema (GC, persistência, rede) — não excelência.

Comparativo de custo operacional

Árvore de decisão

Precisa de cache?
├── Sim → Dados cabem em RAM?
│   ├── Sim → Precisa de estruturas ricas (hash, sorted set)?
│   │   ├── Sim → Precisa multi-thread?
│   │   │   ├── Sim → DragonflyDB ou KeyDB
│   │   │   └── Não → Redis ou Valkey
│   │   └── Não → Memcached
│   └── Não → Aerospike
└── Não → Considere PostgreSQL, Kafka, etc.

Coexistência: arquitetura políglota de dados

Sistemas maduros raramente escolhem uma única solução:

┌─────────────────────────────────────────────────────────┐
│                    Camada de Aplicação                   │
├──────────┬──────────┬──────────┬──────────┬─────────────┤
│Memcached │  Redis   │ KeyDB/   │Aerospike │ PostgreSQL  │
│ Cache    │ Sessão + │Dragonfly │ Perfis + │ Pedidos +   │
│ de página│ Rate Lim │(through) │ Inventár.│ Relatórios  │
└──────────┴──────────┴──────────┴──────────┴─────────────┘

Cada ferramenta resolve um capítulo do enredo — não tente escrever o livro inteiro com um único personagem.

Checklist de seleção

Antes de decidir, responda:

1. Volume de dados — cabe em RAM? (< 100 GB → Redis; > 500 GB → Aerospike)
2. Padrão de acesso — chave-valor simples ou estruturas ricas?
3. Durabilidade — perda de dados é aceitável? (sim → Memcached; não → Redis/Aerospike)
4. Throughput — quantas ops/s? (> 500k em 1 nó → DragonflyDB/KeyDB)
5. Consistência — CP ou AP? (financeiro → CP; cache → AP)
6. Licença — BSD obrigatório? (Valkey, KeyDB, Memcached)
7. Equipe — experiência existente com qual ferramenta?
8. SLA de latência — qual P99 é aceitável?

Resumo

• Não existe "melhor" solução universal — existe a melhor para cada contexto
• CAP ajuda a posicionar trade-offs: CP (Redis, Aerospike) vs AP (Memcached, KeyDB active)
• Otimize decisões por P99, não por ops/s de marketing
• Arquiteturas maduras combinam múltiplas ferramentas — poliglotismo é força, não fraqueza

Para refletir

"O arquiteto não escolhe a ferramenta mais rápida — escolhe a que o time opera bem, o negócio tolera e o orçamento sustenta."

Desenhe a arquitetura de cache de um SaaS com 10.000 clientes, 50 GB de sessões e 200 GB de perfis: quais soluções você combinaria?