Stateless vs Stateful: Entenda a diferença de uma vez por todas

Source: Dev.to

Escolher entre uma arquitetura Stateful ou Stateless é uma das decisões mais fundamentais ao desenhar o backend de uma aplicação. Essa escolha impacta diretamente como o sistema escala e como lida com a autenticação.

Stateful

Analogia

Imagine que você frequenta a mesma cafeteria todos os dias. Ao chegar, o atendente já sorri e diz:
“Bom dia, Otávio! Vai querer o mesmo de sempre?”

O atendente lembra de você porque guardou seu nome e seu pedido favorito na memória. Se você disser apenas “quero mais um”, ele saberá exatamente o que preparar, pois há um estado mantido entre as interações.

Conceito

O servidor mantém uma “conversa” ativa com o usuário, armazenando informações sobre 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 enquanto ele está logado.

Prós e contras

• Prós: Intuitivo e fácil de gerenciar em aplicações pequenas (monolitos).
• Contras: Difícil de escalar horizontalmente; requer estratégias como Sticky Sessions ou armazenamento externo (ex.: Redis) para que múltiplas instâncias compartilhem o estado.

Exemplo de código (.NET)

// 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");

Stateless

Analogia

Agora imagine uma cafeteria de autoatendimento. Você chega, informa seu nome e o tipo de café, recebe a bebida e o atendente esquece quem você é imediatamente. Se quiser outro café, deve repetir todas as informações.

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

• Prós: Altamente escalável, ideal para microserviços e ambientes em nuvem.
• Contras: Cada requisição pode ser ligeiramente mais “pesada”, pois carrega os dados de autenticação (token) em cada chamada.

Exemplo de código (Spring Boot)

@GetMapping("/perfil")
public ResponseEntity getPerfil(@RequestHeader("Authorization") String token) {
    // O servidor é "frio": não mantém lista de usuários logados na RAM.
    // Decodifica o JWT enviado pelo cliente para identificar o usuário.

    if (token != null && token.startsWith("Bearer ")) {
        String jwt = token.substring(7);
        String username = jwtService.extractUsername(jwt); // extrai o "sub" do payload

        return ResponseEntity.ok("Usuário identificado via Token: " + username);
    }

    return ResponseEntity.status(HttpStatus.UNAUTHORIZED).build();
}

Comparação

Conclusão

A regra de ouro para o desenvolvimento web moderno é dar preferência ao Stateless. Em ambientes como AWS, Azure, Google Cloud ou ao usar Docker/Kubernetes, o modelo Stateless permite escalar de 10 a 100 instâncias sem se preocupar com perda de sessão.

Stateful ainda tem seu espaço em sistemas legados ou monolitos muito específicos, mas o presente e o futuro da maioria das aplicações são Stateless.