Aislamiento de la IA en una plataforma .NET: un servicio Python caído devolvió HTTP 503, no el fallo de toda la API

Un experimento sencillo muestra bien cómo debe comportarse una plataforma con un componente de IA. El autor de un análisis en Habr detuvo el servicio Python con un modelo de machine learning y la API .NET siguió operativa: la solicitud a la función de IA recibió HTTP 503. Tras restablecer Python, la misma solicitud volvió a terminar con código 200. Nadie reinició la aplicación principal.

Para los equipos que integran modelos en sistemas corporativos existentes, esta es la cuestión práctica clave. Un modelo falla con más frecuencia y de forma más impredecible que el resto del backend. El objetivo es que su fallo no se convierta en la caída de toda la plataforma.

Por qué separar .NET y Python

La mayor parte del ecosistema de ML vive en Python: PyTorch, bibliotecas de inferencia, wrappers listos para modelos. La lógica de negocio, la autorización, las transacciones y las integraciones del mundo corporativo suelen estar escritas en .NET. La tentación de unirlos en un solo proceso es comprensible: menos infraestructura y ninguna llamada de red.

El precio de esa decisión es un destino compartido. Una fuga de memoria en una biblioteca nativa, un bloqueo por el GIL o una caída al cargar pesos pesados afectan a todo el proceso. Un servicio Python independiente fija un límite de fallo: puede caerse, reiniciarse y actualizarse según su propio calendario, mientras el resto de la API sigue atendiendo a los clientes.

El título del original promete una solución «sin microservicios innecesarios». Se trata de un único servicio dedicado al modelo, sin fragmentar todo el sistema en decenas de nodos.

Qué hay que prever en la frontera entre ambos

La frontera de red por sí sola no garantiza nada. Si .NET espera indefinidamente la respuesta de un Python inaccesible, el fallo simplemente se traslada al pool de hilos. Para un aislamiento real, en el lado de .NET suelen hacer falta varios mecanismos:

• timeouts estrictos en cada llamada al modelo;
• comprobaciones de estado del servicio (health checks) para detectar rápidamente que no está disponible;
• circuit breaker: tras una serie de errores, las llamadas se interrumpen temporalmente y las solicitudes reciben un rechazo inmediato;
• reintentos con espera exponencial y jitter, pero solo para operaciones idempotentes;
• límite de accesos simultáneos al modelo (bulkhead), para que una inferencia lenta no consuma todos los recursos de la API.

La semántica de la respuesta también importa. El código 503 indica al cliente que el servicio no está disponible temporalmente, y eso es más honesto que un error genérico 500. El frontend y los sistemas que llaman a la API pueden distinguir el fallo de la función de IA de una avería de la plataforma. Según la descripción del experimento, la API se comportó exactamente así: 503 mientras duró la caída y 200 justo después de que Python volviera.

Resultado del experimento

Según la descripción publicada, el panorama es el siguiente:

• Servicio Python detenido: la API .NET sigue funcionando.
• Solicitud a la función de IA durante ese tiempo: HTTP 503.
• Servicio Python restablecido: la misma solicitud termina con HTTP 200.
• Reinicio de la aplicación principal: no fue necesario.

El autor no aporta aquí cifras de latencia ni de carga, así que es una demostración de un principio, no un benchmark. Los detalles de la implementación están en el artículo original.

Qué llevarse a la práctica

Para un equipo que va a añadir un modelo a un sistema en producción, de esto se derivan varios pasos. Primero, determine qué funciones dependen realmente de la IA y decida qué verá el usuario cuando no estén disponibles: un mensaje de error, una respuesta de la caché o una lógica simplificada sin modelo. Después, fije timeouts estrictamente más cortos que los de los clientes de nivel superior. Por último, incluya el fallo del servicio de IA en sus simulacros periódicos: deténgalo en un entorno de pruebas y compruebe que el resto de la API responde con normalidad, como hizo el autor.

Si al detener Python empiezan a caer endpoints no relacionados, el límite de fallo está mal trazado y el problema no es el modelo.