O Que É um Serviço Stateful? Quando a Memória Vive na Instância
Um serviço stateful guarda dados que precisam persistir entre requisições e sobreviver a restarts, então suas instâncias não são livremente intercambiáveis.
Alguns serviços genuinamente precisam lembrar de coisas: bancos de dados, caches, message brokers, qualquer coisa que armazena dados. Esses serviços stateful não podem ser mortos e substituídos casualmente como os stateless, porque os dados que guardam são o ponto. Saber quais partes de um sistema são stateful te diz onde o trabalho cuidadoso de escala e deploy tem que acontecer.
Estado que precisa persistir
Um serviço stateful é dono de dados cuja perda importa: linhas em um banco de dados, mensagens em um broker, entradas em um cache persistente. A identidade de uma instância importa porque ela guarda dados específicos, então você não pode tratar instâncias como anônimas e descartáveis.
Por que é mais difícil
- Escalar requer replicação, sharding ou particionamento.
- Instâncias têm identidade, então não podem ser trocadas livremente.
- O failover precisa preservar ou recuperar os dados.
- Deploys arriscam perda de dados se mal conduzidos.
Concentre o estado
Um design comum mantém a maioria dos serviços stateless e empurra o estado para poucos sistemas stateful bem gerenciados. Assim, os problemas difíceis, backups, replicação, upgrades cuidadosos, vivem em um pequeno número de lugares em vez de espalhados por toda parte.
O desafio de CI/CD
Fazer deploy de um serviço stateful muitas vezes envolve migrações de esquema, compatibilidade de dados e ordenação: a migração precisa funcionar tanto para o código antigo quanto para o novo durante um deploy rolling. Pipelines rodam e verificam migrações com cuidado, porque uma ruim pode corromper dados, não apenas derrubar um processo.
Testando com data stores reais
A lógica stateful é melhor testada contra uma instância real do data store, subida como service container no CI, então populada e derrubada a cada execução. Mocks perdem o comportamento específico de armazenamento que causa bugs em produção.
Subindo data stores no CI
Subir um banco de dados ou broker a cada execução de teste adiciona tempo de inicialização. Runners gerenciados aquecidos (como os que o Latchkey fornece) absorvem esse custo para que os testes de integração stateful permaneçam ágeis.
Principais conclusões
- Um serviço stateful guarda dados que precisam persistir e sobreviver a restarts.
- Suas instâncias têm identidade, então escala e deploys são muito mais delicados.
- Concentrar o estado em poucos sistemas gerenciados mantém os problemas difíceis contidos.