Software · Arquitetura de Software
Stateful vs Stateless: Sessões, Escala Horizontal e Onde Guardar o Estado
A transição indispensável para arquiteturas elásticas: por que serviços de aplicação devem ser estritamente stateless, como gerenciar afinidade de sessão e onde persistir o estado distribuído.
Neste artigo
A regra de ouro da computação em nuvem é simples: aplicações que escalam horizontalmente com facilidade tratam suas instâncias de computação como recursos descartáveis (cattle, not pets). Essa premissa exige que a camada de servidores seja Stateless (sem estado retido em memória local), permitindo que qualquer requisição seja atendida por qualquer nó da frota.
flowchart TD
subgraph ArquiteturaStateful["Abordagem Antiga: Servidor Stateful com Sessão em Memória"]
LB1["Load Balancer com Sticky Session (Afinidade)"]
Srv1["Servidor 1 (Sessão do Usuário A na RAM)"]
Srv2["Servidor 2 (Sessão do Usuário B na RAM)"]
LB1 -- "Se Servidor 1 cair, Usuário A é deslogado!" --> Srv1
LB1 --> Srv2
end
subgraph ArquiteturaStateless["Abordagem Moderna: Servidores Stateless + Cache Central"]
LB2["Load Balancer Round-Robin / Sem Afinidade"]
NodeA["Instância Pod A (Stateless)"]
NodeB["Instância Pod B (Stateless)"]
NodeC["Instância Pod C (Stateless)"]
RedisStore[("Cluster Redis / Azure Cache<br/>Sessões Centralizadas")]
LB2 --> NodeA
LB2 --> NodeB
LB2 --> NodeC
NodeA <--> RedisStore
NodeB <--> RedisStore
NodeC <--> RedisStore
end
As Dores do Modelo Stateful
No paradigma antigo, aplicações web armazenavam o carrinho de compras ou dados de autenticação diretamente na memória do processo (HttpSession no Java ou In-Proc Session no ASP.NET). Esse modelo traz três gargalos graves:
- Obrigatoriedade de Sticky Sessions: O balanceador de carga precisa inspecionar cookies e amarrar cada usuário ao mesmo servidor físico.
- Distribuição Desbalanceada: Se um usuário realiza operações pesadas em um nó, aquele servidor sofre saturação de CPU enquanto os demais ficam ociosos.
- Impossibilidade de Autoscale Elástico: Se a frota precisa encolher durante a noite, desligar uma máquina encerra abruptamente as sessões ativas de quem estava conectado nela.
Externalização de Estado em Camadas Dedicadas
Em uma arquitetura moderna sem estado local, o estado é segregado conforme sua volatilidade:
| Tipo de Estado | Onde Persistir | Características de Latência |
|---|---|---|
| Credenciais de Identidade | Tokens JWT assinados criptograficamente | Validação local na CPU sem I/O de rede |
| Sessão Transitória e Carrinhos | Cache Distribuído em Memória (Redis / Valkey) | Latência sub-milissegundo (< 2ms) |
| Arquivos e Uploads de Usuários | Armazenamento de Objetos (S3 / Azure Blob) | Persistência elástica durável via streaming direto |
| Transações e Registros Definitivos | Banco Relacional / NoSQL (PostgreSQL, Cosmos) | Transacionalidade ACID e índices relacionais |
Com essa separação rigorosa, subir dez novas réplicas de um container no Kubernetes durante um pico de tráfego leva poucos segundos e não afeta nenhuma sessão de usuário em andamento.
