Tecnologia e Infraestrutura → Kesh Níveis e armazenamento de dados

Níveis de kesh e armazenamento de dados

1) Por que precisa de um kesh de camadas múltiplas

Kesh é um atalho para responder sem ir para os subsistemas «caros» (BB, API externa, redes). A multiplicidade de camadas distribui a carga: navegador CDN/edge camada de aplicação distribuída banco de dados/armazenamento. Os objetivos são reduzir o P95/P99, descarregar o origin, aguentar os picos e custar o byte.

2) Mapa dos níveis de cajá

1. Браузер: `Cache-Control`, `ETag`, `Last-Modified`, `stale-while-revalidate`.
2. CDN/Edge: TTL/ключ, Vary, Signed URLs, image-resize; tiered/shield.
3. API Gateway/Service Mesh: curta resposta por GET seguro.
4. Aplicativo (in-processo): LRU/LFU, near-cachê para chaves «quentes», milissegundos.
5. Kesh distribuído (Redis/Memcached): camada principal para dinâmica.
6. Cachês BD: tampões Pg/Inodb, PgBouncer multiplexing, materializações views.
7. Ecrãs de disco/objeto: precomputed snapshots, blob-kesh (por exemplo, S3 + CDN).

Princípio: "Quanto mais perto do usuário, mais curto é o TTL e menos personalização; quanto mais perto dos dados, mais rico será a política de consistência".

3) Pattern de cajado

Cachê-Aside (Lazy): Lendo → quando MISS carregamos de uma fonte → colocamos em um caju. Simples, dá controle TTL.
Read-Through: O aplicativo é lido através de kesh que é puxado da fonte. É conveniente centralizar a política.
Write-Through: A gravação vai para e para a origem imediatamente. Mais consistente, mas mais caro por gravação.
Write-Back (Write-Behind): escrevendo em kesh, a origem é atualizada asinhronalmente (fila). Alta velocidade, são necessárias garantias de entrega e idempotidade.
Refresh-Ahead: As chaves de ponta atualizam o valor até TTL expirar.

Onde: cartões de jogo/catálogo - cachê-aside/read-through; contadores/liderbords - write-back + CRDT/agregações; guias de moedas/limites - read-through com TTL controlado.

4) Chaves, segmentação e naiming

Шаблон: `domain:entity:{id}:v{schema}|region={R}|currency={C}|lang={L}`.
Incluir na chave apenas o que realmente muda a resposta (região, moeda, língua, versão do esquema).
Versionização de diagramas: Em caso de alterações incompatíveis, aumente 'vN' na chave, evitando purge em massa.
Namespacing para produtos/tenantes: 'tenant: Se você não quiser, é crítico para o multi-tenant.
O filtro bloom para «existência de chave» pode reduzir as idas para a origem.

5) TTL, frescor e deficiência

• estática (arquivos hasteados): 30-365 dias + 'imutable';
• diretórios/banners: 5-60 minutos + 'stale-while-revalidate';
• liderbords/cotação: 2-15 segundos;
• guias (moedas/limites): 1 a 10 minutos.
• Deficiência de eventos: Publicando 'produt'. updated '→ deficiência de chave de ponto/prefixo.
• Tag-based purge: limpeza em grupo por marcas de formatação (lançamento promocional/catálogo).
• Soft-Expiry: Após o TTL, damos o «stale» obsoleto e atualizamos (SWR/SIE).
• Versioned Keys> purge em massa: mais barato e seguro.

6) Estampede, chaves «quentes» e concorrência

• Single-flight (request coalescing): um líder atualiza a chave, os outros aguardam.
• TTL Jitter: Desfalque a caducidade, evitando o colapso de uma pessoa.
• SWR local: Damos o valor vencido ao usuário e atualizamos.

• replicação da chave «quente» em várias slots «key # 1.. N» distribuída pela leitura;
• near-cachê na memória do processo;
• prewarm/refresh-ahead antes dos picos (torneios/jogos).
• Limites para as atualizações de concarrance para as chaves pesadas.

7) Consistência e camadas cruzadas

Write-invalidate: ao gravar na origem - inválida sincronicamente as chaves correspondentes (pub/sub).
Read-repair: Atualize o kesh com um valor correto.
Eventual vs Strong: transações em dinheiro críticas lendo diretamente/com TTL curto; Vitrines UI e estatísticas - eventual.
CRDT/agregadores: para contadores/classificações distribuídos - estrutura «merge-safe» (G-Counter, Top-K em streaming).
Deficiência em cascata: Atualizar «jogo» inválida cartão + lista + caixa de recomendação personalizada.

8) Serialização, compressão e formato

Formatos: Protobuf/ Pack mais rápido que o JSON; para CDN/navegador - JSON com Brotli.
Compressão Redis: É benéfico para objetos> 1-2 KB, mas siga o CPU.
Partial responses/campos sob demanda: menos bytes → menos TTFB e RAM.

9) Políticas de exclusão e tamanho

LRU (padrão) - seguro; LFU - melhor para conteúdo «popular».
Tamanho das chaves/valores: mantenha controle (métricas 'avg value size', 'max').
Quotas de namespace/tenant para que um produto não «devore» todo o kesh.

10) Segurança e PII/PCI

Dados pessoais/financeiros - Não é baseado em CDN/edge e em camadas comuns; use tokens/projeções.
Criptografia de valores sensíveis no Redis através do cliente-side crypto (com cuidado para perdas de controle TTL).
LCA rigoroso e isolamento de redes; NAT/IP fixo para egress para provedores.

11) Observabilidade e SLO kesha

• Hit Ratio (camadas e prefixos), Origin Offload.
• TTFB/P95/P99 antes/depois do caju, Latency Redis.
• Evictions, OOM, keyspace hits/misses.
• Estampede rate (proporção de atualizações paralelas), refresh time.
• Stale served % и Freshness lag.

• Catálogo de jogos: Hit Ratio ≥ 85%, TTFB P95 ≤ 150 ms (edge).
• Guias API Revalidação-hit ≥ 60%, P95 ≤ 200 ms.
• Redis: P99 operação ≤ 5 ms, evictions no máximo 1% por hora.

12) FinOps: custo do cajá

$/mês GB RAM vs $/RPS origin: conte o ponto de retorno.
Offload e egress: CDN + Redis reduzem o tráfego de saída da região-origin.
Image/WebP/AVIF e denormização oferecem a maior economia de bytes.
Limite «Caros MISS», analista de bytes x Miss x Região.

13) Exemplos (fatias)

13. 1 Cachê-Aside com single-flight (pseudocode)

python def get(key, ttl, loader):
val = redis. get(key)
if val: return val with single_flight (key): # only one updates val = redis. get (key) # double check if val: return val data = loader () # request to source redis. setex(key, ttl_with_jitter(ttl), serialize(data))
return data

13. 2 Publicar deficiência por evento

json
{
"event": "game. updated",
"game_id": "g123",
"affected": ["catalog:list:region=TR", "game:card:g123:"]
}

O Consumer está inscrito no canal e faz de «DEL »/« PUBLISH» as chaves/marcas correspondentes.

13. 3 Chave com versão de circuito e local

game:card:v2:id=g123    region=BR    currency=BRL    lang=pt-BR

14) Folha de cheque de implementação

1. Mapa dos níveis de cajá e da matriz TTL (estático/semistático/API).
2. Nayming chaves, domínio, versão do circuito, local/região/moeda, tênant.
3. Escolha um pattern per-endpoint (aside/read-through/write-through/back).
4. SWR/SIE, single-flight e TTL-jitter contra estampede.
5. Deficiência de eventos (pub/sub), tag-purge para grupos.
6. Near-cachê para chaves «quentes» e prewarm antes dos picos.
7. Formatos e compressão (protobuf/MsgPack Brotli), controle de tamanho.
8. Políticas LRU/LFU, quotas de namespace/tenant.
9. SLO/метрики: hit ratio, latency, evictions, stale %, freshness lag.
10. Segurança: no-store para pessoal, tocenização, rede/LCA.

15) Anti-pattern

'no-cachê' «por precaução» e desistências da TTL - zero offload.
A chave inclui todos os query/títulos → explosão de radicalidade.
Purge «todo CDN/Redis» em massa a cada lançamento.
Falta de proteção contra estampede e «top chaves» de uma só vez.
Redis comum sem quotas/isolamento; tenant «quente» come todo o caroço.
Cajulação de respostas pessoais para edge/CDN.
Não há telemetria freshness/evictions → controle cego.

16) Contexto iGaming/fintech: notas práticas

Liderbords/classificações: TTL 2-10 s, agregate-fluxo + CRDT, SWR em casos de falhas.
Catálogo de jogos/banners: CDN + Redis; chave: região/moeda/língua; deficiência com marcas de formatação «promo: update».
Estatais de pagamento: sem dinheiro no caminho de gravação; leitura - TTL curto (≤3 -5 c) ou consulta direta.
KYC/AML respostas: Cajue derivativos não-PII (estatais), não guarde imagens/documentos no Redis.
Caminho VIP: nomeado namespace/pool Redis, serviço prioritário.

Resultado

Uma forte estratégia de kesh é a arquitetura de níveis, pattern de atualização corretos, TTL/deficiência elaborada, resistência a estampede, chaves e versões cuidadosas e observabilidade e FinOps. Seguindo estes princípios, você estabiliza as caudas P95/P99, reduz a pressão sobre as fontes e obtém um custo previsível de milissegundos - exatamente onde isso é mais importante para o produto e para o negócio.