Resiliência antes dos microsserviços: fronteiras, limites e idempotência

Em entrevista acompanhada de síntese no The Pragmatic Engineer, Sam Newman descreve microsserviços como arquitetura de último recurso e destaca o valor da implantação independente.[15] Sua definição objetiva é um serviço que pode ser implantado sem obrigar a implantação de outros.[15] Minha leitura é que a discussão deveria começar pela autonomia necessária, não pela quantidade de serviços desenhados.

O que muda para quem desenvolve

Newman resume problemas recorrentes dos sistemas distribuídos em três pontos: informação leva tempo para viajar, dependências podem ficar indisponíveis e recursos são finitos.[15] Ele também defende que a decisão de continuar ou bloquear uma operação quando uma checagem falha depende do contexto de negócio.[15]

A aplicação prática dessa visão é explicitar as consequências antes de escolher um mecanismo. Uma consulta informativa e uma autorização financeira não deveriam herdar o mesmo comportamento de falha apenas porque ambas chamam uma API. Proponho definir prazo, limite de recursos e resultado aceitável por operação.

A conversa também destaca idempotência: uma chave fornecida pelo cliente permite reconhecer novas tentativas da mesma operação e evitar duplicação.[15] Uma impressão digital calculada no servidor pode ser mais fácil de introduzir em sistemas antigos, mas pode confundir pedidos legítimos semelhantes ou deixar duplicações passarem.[15] É um compromisso de contrato, não apenas uma escolha de biblioteca.

Como aplicar

Antes de extrair um serviço, desenhe o módulo dentro da aplicação atual. Identifique dados próprios, operações, dependências e equipe responsável. Só proponha distribuição quando conseguir explicar qual autonomia de implantação compensa o custo operacional adicional.

Para uma operação com efeito externo, como registrar uma cobrança, defina uma chave de idempotência e documente seu escopo. Proponho especificar também o que acontece se a mesma chave chegar com conteúdo diferente e como a resposta anterior será recuperada. Não use semelhança de valor e horário como substituta silenciosa da identidade da operação.

Em ambiente de teste, simule o caso em que o servidor conclui a operação, mas a resposta não chega ao cliente. Repita a requisição com a mesma chave e confirme que não aparece um segundo efeito. Teste ainda solicitações legítimas parecidas com chaves distintas. O experimento deve demonstrar ausência de duplicação sem bloquear operações diferentes.

Para integração de IA, Newman recomenda interfaces modulares que permitam trocar fornecedor ou substituir uma etapa de LLM por código determinístico.[15] Proponho aplicar isso inicialmente a uma capacidade pequena, com entradas, saídas e falhas explícitas, em vez de construir uma abstração universal antes de conhecer a necessidade.

Cuidados e limites

O texto distingue robustez, recuperação, resposta a surpresas e adaptação, e observa que mecanismos automáticos podem acrescentar novos modos de falha.[15] Reiniciar um componente não demonstra que o sistema aprendeu a evitar o próximo incidente.

Esta análise se apoia na síntese escrita, não numa avaliação própria do episódio completo. As posições de Newman sobre IA e causalidade são opiniões da entrevista, não resultados experimentais apresentados ali.[15] O critério continua operacional: fronteiras claras, falhas testadas e evidência de que o desenho resolve uma necessidade real.

Fonte

[15] Fonte: The Pragmatic Engineer