Escolher entre uma arquitetura Stateful ou Stateless é uma das decisões mais fundamentais que tomamos ao desenhar o backend de uma aplicação. Essa escolha impacta diretamente como seu sistema escala e como ele lida com a autenticação.
Neste artigo, vamos desmistificar esses conceitos com analogias simples e exemplos práticos.
1. O que é Stateful? (O estado mantido)
Vamos entender o que é o Stateful com uma analogia simples e didática. Imagine que você frequenta a mesma cafeteria todos os dias. Ao chegar lá, o atendente já sorri e diz:
"Bom dia, Otávio! Vai querer o mesmo de sempre?"
O atendente lembra de você. Ele guardou na memória dele o seu nome e que o seu pedido favorito é um café expresso duplo. Se você disser apenas "quero mais um", ele saberá exatamente o que preparar, porque existe um contexto anterior (o estado) guardado na mente dele.
- Conceito: O servidor mantém uma "conversa" ativa com o usuário. Ele armazena informações sobre o cliente (a sessão) na sua própria memória (RAM) ou em um banco de dados temporário.
- Exemplo Prático: Sessões clássicas em PHP, Java (HttpSession) ou ASP.NET, onde o servidor guarda os dados do usuário no lado do servidor enquanto ele estiver logado.
- Prós e Contras: É intuitivo e fácil de gerenciar em aplicações pequenas (monolitos), mas é difícil de escalar horizontalmente. Se você precisar de 5 servidores rodando a mesma app, precisará de estratégias complexas (como Sticky Sessions ou Redis) para que todos "conheçam" a sessão do usuário.
-
Exemplo de código (.NET): No ASP.NET, usamos o objeto
Sessionpara que o servidor memorize o usuário.
// O servidor guarda o nome na Sessão (Estado mantido na RAM do servidor)
HttpContext.Session.SetString("UsuarioNome", "Otávio");
// Para recuperar, o servidor busca na própria memória:
var nome = HttpContext.Session.GetString("UsuarioNome");
2. O que é Stateless? (O estado enviado)
Agora imagine que você entra em uma cafeteria de autoatendimento. Você chega no balcão e diz: "Meu nome é Otávio e quero um café expresso". O atendente te entrega o café e esquece quem você é no segundo seguinte.
Se você quiser outro café, terá que dizer tudo de novo: "Meu nome é Otávio e quero outro café expresso". Cada interação é completa por si só. O atendente não precisa lembrar de nada; você traz toda a informação necessária em cada pedido.
Na prática (Backend):
- Conceito: O servidor não guarda nada sobre o cliente entre as requisições. Toda a informação necessária para processar a tarefa deve vir na própria requisição (geralmente no Header).
- Exemplo Prático: APIs REST modernas e autenticação via JWT (JSON Web Token).
- Prós e Contras: Altamente escalável e ideal para microserviços, mas as requisições podem ficar levemente mais "pesadas", já que carregam os dados de autenticação (o token) em cada chamada.
// O servidor não busca na memória interna "quem é este usuário".
// Ele extrai a informação direto do Token que o cliente enviou no Header.
@GetMapping("/perfil")
public ResponseEntity<String> getPerfil(@RequestHeader("Authorization") String token) {
// O servidor é "frio": ele não tem uma lista de usuários logados na RAM.
// Ele apenas decodifica o JWT que o cliente enviou para saber quem é o usuário.
if (token != null && token.startsWith("Bearer ")) {
String jwt = token.substring(7);
String username = jwtService.extractUsername(jwt); // Extrai o "sub" do payload do JWT
return ResponseEntity.ok("Usuário identificado via Token: " + username);
}
return ResponseEntity.status(HttpStatus.UNAUTHORIZED).build();
}
3. Comparativo: Stateful vs Stateless
| Característica | Stateful | Stateless |
|---|---|---|
| Armazenamento | Servidor (Memória/RAM) | Cliente (Token/Cookie) |
| Escalabilidade | Difícil (Requer Sticky Sessions) | Fácil (Foco em Cloud e Microserviços) |
| Exemplo Real | Sessões PHP, Carrinhos antigos | APIs REST, JWT, OAuth2 |
| Conexão | Mantém um histórico da conversa | Cada requisição é uma nova conversa |
Conclusão: Qual escolher?
A regra de ouro hoje em dia para o desenvolvimento web moderno é: Dê preferência ao Stateless. Se você pretende rodar sua aplicação na nuvem (AWS, Azure, Google Cloud) ou usar Docker/Kubernetes, o modelo Stateless permite que você suba 10 ou 100 instâncias do seu serviço sem se preocupar se o usuário vai "cair" em um servidor que não conhece a sessão dele.
O Stateful ainda tem seu espaço em sistemas legados ou aplicações monolíticas muito específicas, mas o futuro (e o presente) é Stateless.
Espero que essa explicação tenha ajudado a clarear esses conceitos! Se tiver alguma dúvida ou quiser compartilhar como você utiliza isso nos seus projetos em Node.js, Java ou .NET, deixa um comentário abaixo! 🚀
Top comments (0)