Tu API FastAPI responde en 50ms en desarrollo pero en producción el p99 es 2 segundos. La base de datos responde rápido. El problema está en el application layer. ¿Cómo diagnosticas?
Contexto
Startup de fintech. La API maneja 500 req/s. Hay endpoints que hacen múltiples llamadas a servicios internos. El equipo usa sync requests dentro de endpoints async. Deployado en Kubernetes con 4 pods.
Respuesta modelo
Diagnóstico y solución: 1) El problema clásico: usar requests (sync) dentro de endpoints async bloquea el thread pool de uvicorn. Un call bloqueante de 200ms con 8 threads = máximo 40 req/s antes de saturarse. 2) Reemplazar requests con httpx.AsyncClient o aiohttp para llamadas HTTP no bloqueantes. 3) Agregar tracing distribuido (OpenTelemetry) para ver dónde se gasta el tiempo por request. 4) Verificar que las dependencias de FastAPI (Depends) no hacen I/O síncrono. 5) Si hay endpoints que deben ser sync (librerías legacy), moverlos a def (no async def) para que FastAPI los ejecute en un threadpool separado. 6) Configurar el número de workers de uvicorn basándose en CPU cores disponibles.
Claves
- Mezclar código sync en endpoints async es la causa #1 de latencia en FastAPI.
- httpx.AsyncClient reemplaza a requests para llamadas HTTP no bloqueantes.
- Tracing distribuido es esencial para diagnosticar latencia en microservicios.