Skip to main content

Sticky Session | Arquitetura

  • Sticky Session | Arquitetura

Definição​

Sticky Session (também chamada de Session Affinity) é uma estratégia de balanceamento de carga onde todas as requisições de um mesmo cliente são direcionadas para o mesmo servidor backend durante o ciclo de vida da sessão.

Em termos práticos:

Cliente → Load Balancer → Servidor A
                         → Servidor B
                         → Servidor C

Com sticky session habilitado:

Cliente X → sempre → Servidor B

Problema que resolve​

Aplicações que armazenam estado em memória local do servidor precisam garantir que requisições subsequentes sejam tratadas pelo mesmo nó.

Exemplo clássico:

  • Usuário realiza login
  • Sessão é armazenada em memória (RAM) do servidor
  • Próxima requisição depende dessa sessão

Sem sticky session:

  • Requisição pode ir para outro servidor
  • Sessão não existe naquele nó
  • Usuário aparenta estar deslogado

Funcionamento Técnico​

O Load Balancer mantém uma associação entre cliente e servidor backend.

Existem duas estratégias principais:

O balanceador injeta um cookie na resposta:

Set-Cookie: SERVERID=app02

Nas próximas requisições:

Cookie: SERVERID=app02

O balanceador lê o cookie e direciona a requisição para o servidor correspondente.

IP Hash​

O roteamento é feito por hash do IP do cliente:

hash(client_ip) % total_servidores

Limitação:

  • Clientes atrás do mesmo NAT podem concentrar carga no mesmo servidor.

Exemplo no Nginx​

Configuração com ip_hash:

http {
    upstream backend {
        ip_hash;
        server app01:8080;
        server app02:8080;
        server app03:8080;
    }

    server {
        location / {
            proxy_pass http://backend;
        }
    }
}

Impacto Arquitetural​

Sticky session implica que a aplicação não é totalmente stateless.

Isso afeta:

  • Escalabilidade horizontal
  • Elasticidade automática
  • Resiliência a falhas
  • Distribuição uniforme de carga

Alternativa Moderna (Stateless)​

Arquiteturas modernas evitam sticky session utilizando armazenamento centralizado:

  • Sessões armazenadas em Redis
  • Banco compartilhado como PostgreSQL
  • Tokens JWT assinados

Exemplo arquitetural:

Cliente → Load Balancer → Servidor A
                         → Servidor B
                         → Servidor C
                               ↓
                            Redis

Nesse modelo:

  • Qualquer servidor pode atender qualquer requisição
  • Não existe dependência de afinidade

Quando Utilizar​

Cenários onde sticky session pode ser aceitável:

  • Sistemas legados
  • Aplicações monolíticas
  • Ambiente controlado com pouca elasticidade
  • Migração gradual para arquitetura stateless

Evitar em:

  • Microsserviços
  • Ambientes Kubernetes
  • Cloud auto-scaling
  • Sistemas de alta disponibilidade crítica