Fundamentos•6–10 horas

Cliente resiliente para API de IA

Construye un cliente de API LLM listo para producción con salida estructurada, validación, reintentos, timeouts, idempotencia, trazas y pruebas.

tipado en Pythonasync IOPydanticreintentosobservabilidadtesting

Escenario

Tarea

Un servicio interno debe llamar a un LLM para clasificar solicitudes de soporte. Las respuestas deben ser estructuradas, las solicitudes repetidas deben ser seguras y los fallos deben poder medirse y reproducirse.

Ejecución paso a paso

1. Define el contrato

Resultado: Requests y responses tienen una forma tipada estable.

Tareas

→Define el modelo de entrada
→Crea el esquema de salida
→Define los errores de validación
→Añade un correlation ID

Comprobaciones

✓Las respuestas inválidas nunca pasan en silencio
✓El esquema tiene pruebas unitarias

2. Implementa la capa de transporte

Resultado: El cliente controla explícitamente el comportamiento de red.

Tareas

→Añade requests asíncronos
→Configura timeouts de conexión y lectura
→Gestiona respuestas 429 y 5xx
→Añade backoff exponencial con jitter

Comprobaciones

✓Los reintentos tienen un límite
✓La política no repite errores no reintentables

3. Añade observabilidad

Resultado: Cada llamada puede explicarse después de ejecutarse.

Tareas

→Registra el request ID
→Mide la latencia
→Registra uso de tokens y número de reintentos
→No registres secretos ni PII

Comprobaciones

✓Un request puede trazarse de extremo a extremo
✓Los datos sensibles no llegan a los logs

4. Crea pruebas y simulación de fallos

Resultado: Los modos de fallo conocidos se reproducen localmente.

Tareas

→Simula un timeout
→Simula un 429
→Devuelve JSON malformado
→Prueba un request duplicado

Comprobaciones

✓Todas las rutas de fallo tienen assertions
✓Un request idempotente repetido no crea duplicados

Criterios de aceptación

Los tipos pasan la validación
Todas las pruebas están en verde
Los reintentos están limitados
Una salida estructurada inválida devuelve un error explícito
Existe un informe de latencia/reintentos/coste

Rúbrica de evaluación

Cómo se evalúa el resultado

Puntuación mínima: 70/100 · Distinción: 90/100

Contratos y validación

Requests, responses y errores tienen una forma tipada explícita.

25 puntos

Insuficiente

El esquema está incompleto o los errores se silencian.

Competente

Los contratos principales están tipados y probados.

Sólido

Los contratos están versionados y los modos de fallo tienen tipos y pruebas específicos.

Evidencia requerida

✓ Enlace al código o artefacto
✓ README breve con las decisiones
✓ Salida de pruebas o evidencia de runtime
✓ Ejemplos de respuestas válidas e inválidas

Fiabilidad de la capa de transporte

Timeouts, retries, backoff, rate limits e idempotencia están implementados con límites seguros.

30 puntos

Insuficiente

Los reintentos son ilimitados o se mezclan errores reintentables y no reintentables.

Competente

Las políticas de retry y timeout tienen límites y pruebas.

Sólido

Se demuestra jitter, circuit breaker o fallback entre modelos con evidencias.

Evidencia requerida

✓ Enlace al código o artefacto
✓ README breve con las decisiones
✓ Salida de pruebas o evidencia de runtime
✓ Simulación de fallos para timeout, 429 y 5xx

Observabilidad

Cada llamada se explica mediante request ID, latencia, retries, uso y logs seguros.

20 puntos

Insuficiente

No existe correlación de extremo a extremo o los logs contienen datos sensibles.

Competente

Se implementan request ID, latencia, uso y redacción.

Sólido

Se implementan trazas distribuidas, dashboards o umbrales de alerta.

Evidencia requerida

✓ Enlace al código o artefacto
✓ README breve con las decisiones
✓ Salida de pruebas o evidencia de runtime
✓ Ejemplo de trace o log estructurado

Pruebas y reproducibilidad

Los caminos de éxito y fallo se reproducen automáticamente.

25 puntos

Insuficiente

Solo se prueba el happy path.

Competente

Hay pruebas unitarias y de integración para los principales modos de fallo.

Sólido

Incluye pruebas de concurrencia/carga y fixtures de regresión estables.

Evidencia requerida

✓ Enlace al código o artefacto
✓ README breve con las decisiones
✓ Salida de pruebas o evidencia de runtime
✓ Matriz de pruebas para escenarios clave