a. Visão geral

Quando o gateway escala horizontalmente, cada instância da JVM tem seu próprio cache local. Uma requisição roteada para a réplica 1 coloca uma conta em cache; a mesma conta buscada pela réplica 2 dispara outra consulta ao banco. Um cache externo compartilhado (Redis) resolve isso: todas as réplicas leem e escrevem no mesmo armazenamento.

Bancos de dados em memória

Um banco de dados em memória (IMDB, in-memory database) mantém seu conjunto de dados de trabalho principal na RAM, e não em disco. Como a latência de acesso à RAM é medida em nanossegundos, enquanto a de acesso ao disco é medida em milissegundos, os IMDBs são ordens de grandeza mais rápidos para workloads com muitas leituras.

O padrão típico em produção é o cache-aside: a aplicação consulta primeiro o armazenamento em memória; somente em um cache miss ela consulta o banco de dados e então preenche o cache com o resultado.

flowchart LR
    app[Serviço] -->|"1. GET account:42"| redis[(Redis)]
    redis -->|"2a. cache hit → retorna"| app
    redis -->|"2b. cache miss (nil)"| app
    app -->|"3. SELECT * FROM accounts\nWHERE id = 42"| db[(PostgreSQL)]
    db -->|"4. retorna a linha"| app
    app -->|"5. SET account:42 ...EX 300"| redis

Redis

O Redis (Remote Dictionary Server) é o armazenamento de estruturas de dados em memória mais utilizado. Ele é usado ao mesmo tempo como cache, armazenamento de sessões, message broker e motor de estruturas de dados em tempo real — e é o padrão de fato para cache distribuído em arquiteturas de microsserviços.

Estruturas de dados

Diferentemente do Memcached (apenas strings), o Redis oferece estruturas de dados nativas, cada uma com operações O(1) ou O(log n):

Opções de persistência

O Redis não é puramente volátil. Dois mecanismos de persistência permitem uma durabilidade controlada:

Neste hands-on, habilitamos o AOF (--appendonly yes), o que garante durabilidade sem sacrificar o desempenho de escrita.

Arquitetura

Adicionar o Redis à plataforma introduz uma camada de cache compartilhada entre todas as réplicas dos microsserviços e o banco de dados:

flowchart LR
    subgraph lb [Balanceador de Carga]
        nginx["Nginx\n:80"]
    end
    subgraph api [Camada Confiável]
        nginx e1@==> gw1["gateway\n(réplica 1)"]
        nginx e2@==> gw2["gateway\n(réplica 2)"]
        nginx e3@==> gw3["gateway\n(réplica 3)"]
        gw1 & gw2 & gw3 --> auth
        gw1 & gw2 & gw3 --> account
        auth & account e4@-->|"leitura/escrita no cache"| redis["Redis\n:6379"]:::highlighted
        redis -->|"apenas em cache miss"| db@{ shape: cyl, label: "PostgreSQL" }
    end
    internet e0@==>|":80"| nginx
    e0@{ animate: true }
    e1@{ animate: true }
    e2@{ animate: true }
    e3@{ animate: true }
    e4@{ animate: true }
    classDef highlighted fill:#fcc

As três réplicas do gateway compartilham a mesma instância do Redis. Uma entrada de cache gravada pela réplica 1 pode ser lida imediatamente pelas réplicas 2 e 3, eliminando consultas redundantes ao banco, independentemente de qual instância atenda a próxima requisição.