Qual é a diferença entre serviços com estado e serviços sem estado?

Question

Accepted Answer

Serviços **sem estado** não armazenam o estado do cliente entre requisições (cada requisição é independente), enquanto serviços **com estado** mantêm o estado. A ausência de estado é importante para escalabilidade — serviços sem estado são muito mais fáceis de escalar horizontalmente.

## Serviços sem estado vs com estado

```text
STATELESS → the service keeps NO client state between requests:
  → each request contains all needed info; any server can handle any request
  → state lives ELSEWHERE (database, cache, client, token) if needed
STATEFUL → the service MAINTAINS state across requests:
  → a specific server holds a client's state (session in memory, etc.)
  → requests must go to the SAME server (or state must be shared/synchronized)
```

## Por que a ausência de estado ajuda na escalabilidade

```text
STATELESS services scale horizontally EASILY:
  → any server handles any request → load balancing is simple (any server works)
  → add/remove servers freely; a failed server doesn't lose state → resilient
  → no sticky sessions or state synchronization needed
STATEFUL services are HARDER to scale:
  → requests tied to specific servers (sticky sessions); a server failure loses its state;
    scaling needs state sharing/replication → complexity
→ PREFER STATELESS services for scalability (a key design principle).
```

## Lidando com estado em designs sem estado

```text
→ Store state EXTERNALLY where servers can share it:
  → SESSION/data in a shared store (Redis, database) → any server reads it
  → state in the CLIENT (e.g. JWT tokens carry auth state)
  → keep services stateless; externalize state → scalable AND maintains needed state
```

## Por que isso importa

Compreender a diferença entre serviços com estado e serviços sem estado é fundamental porque **a ausência de estado é um princípio-chave para construir sistemas escaláveis**, portanto é conhecimento essencial de design de sistemas.

A distinção — serviços **sem estado** que não mantêm estado do cliente entre requisições (cada requisição é independente, qualquer servidor pode lidar com qualquer requisição) versus serviços **com estado** que mantêm estado (vinculados a servidores específicos) — é fundamental para como os serviços escalam.

Compreender **por que a ausência de estado ajuda na escalabilidade** é a percepção crucial: serviços sem estado escalam horizontalmente facilmente porque **qualquer servidor pode lidar com qualquer requisição** (tornando o balanceamento de carga simples, permitindo que servidores sejam livremente adicionados ou removidos, e significando que um servidor que falha não perde estado — resiliente), enquanto serviços com estado são muito mais difíceis de escalar (requisições vinculadas a servidores específicos via sticky sessions, falhas de servidor perdendo estado, escalabilidade exigindo compartilhamento de estado complexo).

Isso torna **preferir serviços sem estado um princípio-chave de design** para escalabilidade — um dos conceitos práticos mais importantes ao projetar sistemas escaláveis.

Compreender como **lidar com estado em designs sem estado** — armazenar estado externamente onde os servidores podem compartilhá-lo (sessões em um armazenamento compartilhado como Redis, ou estado em tokens do lado do cliente como JWTs) para que os serviços permaneçam sem estado enquanto ainda mantêm o estado necessário — é a técnica prática que concilia a ausência de estado com aplicações que precisam de estado.

Isso se conecta a escalabilidade horizontal e balanceamento de carga (que funcionam melhor com serviços sem estado).

Como a ausência de estado é um habilitador-chave da escalabilidade horizontal (a principal abordagem para sistemas em larga escala) e compreender a distinção sem estado/com estado, por que a ausência de estado auxilia o scaling, e como externalizar estado é fundamental para projetar sistemas escaláveis, compreender serviços com estado vs sem estado é conhecimento essencial e fundamental de design de sistemas — um princípio-chave para escalabilidade (ausência de estado habilitando escalabilidade horizontal fácil), conectando-se a balanceamento de carga e escalabilidade horizontal, e central ao projetar sistemas que escalam, um conceito importante subjacente à arquitetura escalável.