Isolamento de IA em plataformas .NET: com o serviço Python fora do ar, a API devolveu HTTP 503 em vez de cair por inteiro

Um experimento simples mostra bem como uma plataforma com componente de IA deve se comportar. O autor da análise no Habr parou o serviço Python com o modelo de machine learning, e a API .NET continuou operacional: a requisição à função de IA recebeu HTTP 503. Depois que o Python foi restabelecido, a mesma requisição voltou a terminar com código 200. Ninguém reiniciou o aplicativo principal.

Para equipes que incorporam modelos a sistemas corporativos já existentes, essa é a principal questão prática. O modelo falha com mais frequência e de forma mais imprevisível do que o restante do backend. O objetivo é impedir que a falha dele paralise a plataforma inteira.

Por que separar .NET e Python

A maior parte do ecossistema de ML vive em Python: PyTorch, bibliotecas de inferência, wrappers prontos para modelos. Já a lógica de negócio, a autorização, as transações e as integrações no mundo corporativo costumam ser escritas em .NET. É compreensível a tentação de juntar os dois em um único processo: há menos infraestrutura e nenhuma chamada de rede.

O preço dessa escolha é o destino compartilhado. Um vazamento de memória em uma biblioteca nativa, um travamento causado pelo GIL ou uma queda ao carregar pesos pesados afeta o processo inteiro. Um serviço Python separado define uma fronteira de falha: ele pode cair, reiniciar e ser atualizado no seu próprio ritmo, enquanto o restante da API continua atendendo os clientes.

O título do original promete uma solução "sem microsserviços desnecessários". Trata-se de um único serviço dedicado ao modelo, sem fragmentar o sistema em dezenas de nós.

O que prever na interface entre os dois

Uma fronteira de rede, por si só, não garante nada. Se o .NET ficar esperando indefinidamente a resposta de um Python indisponível, a falha apenas migra para o pool de threads. Para um isolamento de verdade, o lado .NET normalmente precisa de vários mecanismos:

• timeouts rígidos em cada chamada ao modelo;
• verificações de estado do serviço (health checks), para detectar rapidamente que ele está indisponível;
• circuit breaker: após uma série de erros, as chamadas são suspensas por um tempo e as requisições recebem recusa imediata;
• novas tentativas com espera exponencial e jitter, mas somente para operações idempotentes;
• limite de acessos simultâneos ao modelo (bulkhead), para que uma inferência lenta não consuma todos os recursos da API.

A semântica da resposta também importa. O código 503 informa ao cliente que o serviço está temporariamente indisponível, o que é mais honesto do que um erro genérico 500. O frontend e os sistemas chamadores conseguem distinguir a falha da função de IA de um defeito da plataforma. Segundo a descrição do experimento, foi exatamente assim que a API se comportou: 503 durante a indisponibilidade e 200 logo após a volta do Python.

Resultado do experimento

De acordo com a descrição publicada, o quadro é este:

• Serviço Python parado: a API .NET continua funcionando.
• Requisição à função de IA nesse intervalo: HTTP 503.
• Serviço Python restabelecido: a mesma requisição termina com HTTP 200.
• Reinício do aplicativo principal: não foi necessário.

O autor não apresenta números de latência ou de carga, então se trata de uma demonstração de princípio, não de um benchmark. Os detalhes da implementação estão no artigo original.

O que levar para a prática

Para uma equipe que pretende colocar um modelo em um sistema de produção, isso se traduz em alguns passos. Primeiro, defina quais funções realmente dependem de IA e decida o que o usuário verá quando elas estiverem indisponíveis: uma mensagem de erro, uma resposta do cache ou uma lógica simplificada sem o modelo. Depois, configure timeouts estritamente menores do que os dos clientes a montante. Por fim, inclua a falha do serviço de IA nos exercícios regulares: pare-o em um ambiente de teste e confirme que o restante da API responde normalmente, como fez o autor.

Se, após parar o Python, endpoints não relacionados começarem a falhar, a fronteira de falha foi traçada de forma errada, e o problema não está no modelo.