📚 Pré-requisitos Teóricos: este projeto aplica conceitos ensinados em Módulo 08: Bancos de Dados SQL e NoSQL. Recomendado revisar antes de começar.

⚡ Arquitetura de Cache Distribuído com Redis & Invalidação Inteligente

v3.0 — Padrão Cache-Aside, Write-Through, Invalidação e Rate Limiting

Trilha de Engenharia de Dados & Bancos de Dados — Projeto 3 de 4

• v1: Modelagem Relacional 3FN · Constraints · Triggers · PostgreSQL 16
• v2: Modelagem NoSQL · Aggregation Pipelines · MongoDB 7.0
• ➡️ v3 (este): Estratégias de Cache · Cache-Aside · Invalidação · Redis 7.2
• v4: DBA Enterprise · EXPLAIN ANALYZE · Particionamento · PgBouncer · RLS

🎓 Nível Profissional Simulado: Engenheiro de Backend Sênior / Systems Architect. Na computação, existem apenas duas coisas difíceis: invalidação de cache e escolha de nomes. Aqui você aprende como arquitetar um cache resiliente que evita Cache Stampede, Cache Avalanche e Stale Data.

🎯 Objetivo

Implementar uma camada de aceleração em memória com Redis 7.2 aplicando os padrões Cache-Aside (Lazy Loading) e Invalidação Atômica, garantindo latência sub-milissegundo de resposta e protegendo o banco relacional contra picos de tráfego.

🏗️ Diagrama de Sequência — Padrão Cache-Aside & Invalidação

sequenceDiagram
    autonumber
    actor Cliente
    participant App as Backend API
    participant Cache as Redis (In-Memory)
    participant DB as PostgreSQL (Disk)

    Note over Cliente,DB: Cenário 1: Leitura Inicial (Cache MISS)
    Cliente->>App: GET /produtos/101
    App->>Cache: GET produto:101
    Cache-->>App: (nil / Cache MISS)
    App->>DB: SELECT * FROM produtos WHERE id = 101
    DB-->>App: { id: 101, nome: "MacBook", preco: 14999 }
    App->>Cache: SETEX produto:101 60s {json}
    App-->>Cliente: 200 OK (50ms - Disco)

    Note over Cliente,DB: Cenário 2: Leituras Subsequentes (Cache HIT)
    Cliente->>App: GET /produtos/101
    App->>Cache: GET produto:101
    Cache-->>App: { id: 101, nome: "MacBook", preco: 14999 } (Cache HIT)
    App-->>Cliente: 200 OK (< 2ms - RAM)

    Note over Cliente,DB: Cenário 3: Atualização com Invalidação (Evita Stale Data)
    Cliente->>App: PUT /produtos/101 { preco: 13999 }
    App->>DB: UPDATE produtos SET preco = 13999 WHERE id = 101
    App->>Cache: DEL produto:101 (Invalidação Atômica)
    App-->>Cliente: 200 OK (Preço Atualizado)

🧑‍💼 Fase 1 — Levantamento de Requisitos

O Briefing do Cliente (Equipe de Infraestrutura & SRE)

“Nas promoções relâmpago, o mesmo produto recebe 50.000 requisições por segundo. O banco de dados relacional trava porque atinge 100% de CPU rodando o mesmo SELECT repetidamente. Precisamos de uma camada intermediária em memória ultra-rápida que responda instantaneamente e saiba quando atualizar os dados se o preço mudar.”

Requisitos Funcionais (RF) e Não-Funcionais (RNF)

📋 Fase 2 — Backlog & User Stories

🌿 Fase 3 — Engenharia em Equipe (Git Flow & Setup)

# Branch da funcionalidade
git checkout -b feature/US01-cache-aside-redis

# Subir o Redis isolado
docker-compose up -d

# Monitorar os comandos em tempo real
docker exec -it db_cache_redis redis-cli -a redissecret MONITOR

🛠️ Fase 4 — Implementação Passo a Passo (app/cache_manager.py)

def buscar_produto_com_cache_aside(redis_client, produto_id, ttl=60):
    cache_key = f"produto:{produto_id}"
    dados = redis_client.get(cache_key)
    
    # 1. Cache HIT
    if dados:
        return json.loads(dados)

    # 2. Cache MISS: Busca no banco relacional
    produto_db = buscar_no_postgresql(produto_id)

    # 3. Salva no Redis com TTL configurável
    if produto_db:
        redis_client.setex(cache_key, ttl, json.dumps(produto_db))
    return produto_db

🧭 Decisões Técnicas (ADRs)

• ADR 001: Adoção do padrão Cache-Aside com TTL curto para balancear consistência eventual com velocidade extrema.

🚀 Como Executar no Laboratório

1. Abra o terminal na pasta deste projeto

No seu editor/IDE, abra a pasta deste projeto (File > Open Folder) ou navegue via terminal:

cd db_cache_03_redis_sharding_tuning

2. Execute a aplicação ou testes

docker-compose up -d
# Executar a suíte de testes automatizados com asserções de HIT/MISS/TTL:
python -m unittest tests/test_cache_manager.py

[!TIP] Dica para execução a partir da raiz do repositório: Se você abriu o repositório completo no VS Code, basta navegar até a pasta antes de executar: cd catalogo_projetos/db_cache_03_redis_sharding_tuning

🧪 Testes de Validação & Asserções

# Executar a demonstração guiada de Cache Hit, Miss e Invalidação:
python app/cache_manager.py

🏛️ Arquitetura Visual & Engenharia de Dados

A arquitetura abaixo demonstra o fluxo de persistência, otimização e isolamento dos componentes na subpasta app/:

flowchart TD
    subgraph DDL["Modelagem & Schema (DDL)"]
        S1["Tabelas / Coleções"] --> S2["Constraints & Índices"]
    end
    subgraph DML["Regras & Automação (DML / PL)"]
        R1["Triggers / Aggregations"] --> R2["Procedimentos Transacionais"]
    end
    subgraph Perf["Otimização & Armazenamento"]
        P1["Planos EXPLAIN / Partições"] --> P2["Garantia de ACID / TTL"]
    end
    subgraph Homolog["Homologação & Qualidade"]
        Q1["Docker Compose & Scripts"] --> Q2["Checkpoints CP-01..05 PASS"]
    end

    DDL --> DML
    DML --> Perf
    Perf --> Homolog

    style DDL fill:#e3f2fd,stroke:#1976d2,stroke-width:1.5px
    style DML fill:#fffde7,stroke:#fbc02d,stroke-width:1.5px
    style Perf fill:#e8f5e9,stroke:#388e3c,stroke-width:1.5px
    style Homolog fill:#f3e5f5,stroke:#7b1fa2,stroke-width:1.5px

🎯 Engenharia de Requisitos & Modelagem Formal

👤 User Stories (Histórias de Usuário)

⚙️ Requisitos Funcionais (RF)

🛡️ Requisitos Não-Funcionais (RNF)

🔗 Matriz de Rastreabilidade (RTM)

🏁 Checkpoints de Qualidade & Homologação