Procesamiento batch: costo, ventana de 24 horas, custom ID y cálculo del SLA

Bienvenidos y bienvenidas a la cápsula siete del Módulo uno. Hoy vemos el task statement cuatro punto cinco: el procesamiento por lotes con la Message Batches API.

La Message Batches API procesa muchas peticiones de forma asíncrona. Según la guía oficial, ahorra un cincuenta por ciento del costo, procesa en una ventana de hasta veinticuatro horas y no garantiza latencia. Cada petición lleva un identificador, el custom ID, que sirve para emparejar cada resultado con su petición, porque los resultados pueden volver en cualquier orden.

La regla de decisión se lee con conectores. Si la carga no bloquea a nadie y tolera la espera, como los reportes nocturnos, las auditorías semanales o la generación nocturna de pruebas, entonces conviene batch. Por su parte, si un desarrollador o un cliente espera el resultado, como en un chequeo previo al merge, entonces corresponde la API síncrona. Además, si necesitas ejecutar una herramienta tuya a mitad de la petición y devolverle el resultado al modelo, entonces batch no sirve, porque no admite llamadas a herramientas en varios turnos dentro de una misma petición.

El cálculo del SLA aparece en el examen. Con envíos cada cuatro horas y hasta veinticuatro horas de procesamiento, puedes garantizar un SLA de treinta horas. Un documento que llega justo después de un envío espera hasta cuatro horas al siguiente lote, y luego el lote tarda hasta veinticuatro. Son veintiocho horas en el peor caso, y quedan dos de margen. Con un SLA de veintiséis horas, esas ventanas ya no alcanzarían.

Si algo falla, entonces reenvías solo lo que falló, identificado por su custom ID y con los cambios necesarios, por ejemplo dividir en partes los documentos que excedieron el límite de contexto. Reenviar el lote completo duplica el costo y no arregla nada. Y antes de procesar un volumen grande, afinas el prompt con una muestra pequeña.

Una pregunta. ¿Qué trabajos puedes mandar a batch sin que nadie lo note?

Los que nadie espera: reportes nocturnos, auditorías y miles de documentos sin urgencia.

Pregunta uno. Una panadería industrial tiene dos flujos. Uno es un chequeo en tiempo real de etiquetas antes de despachar los camiones, que bloquea la salida. El otro es un reporte de inventario que se genera de noche. Se propone pasar ambos a la Message Batches API por el ahorro del cincuenta por ciento. ¿Qué conviene? Opción A: usar batch solo para el reporte nocturno y mantener tiempo real para el chequeo previo al despacho. Opción B: pasar ambos a batch y consultar el estado con polling. Opción C: pasar ambos a batch, con un respaldo en tiempo real si el lote demora. Opción D: mantener ambos en tiempo real por miedo a la latencia.

La correcta es A. Batch puede tardar hasta veinticuatro horas sin garantía de latencia, así que sirve para el reporte nocturno y no donde alguien espera. La B confía en que suele ser rápido, algo inaceptable en un flujo que bloquea. La C agrega complejidad que se evita asignando cada API a su uso. La D renuncia al ahorro justo donde nadie espera.

Pregunta dos, de respuesta múltiple. Elige dos. Una empresa de drones agrícolas debe procesar cuarenta mil informes de vuelo acumulados, sin urgencia. Algunas peticiones del lote fallan. ¿Qué dos medidas corresponden? Opción A: usar la Message Batches API con un custom ID en cada petición. Opción B: procesar los informes uno a uno en tiempo real. Opción C: reenviar el lote completo cuando algo falla. Opción D: asumir que los resultados vuelven en el mismo orden en que se enviaron. Opción E: reenviar solo las peticiones fallidas, identificadas por su custom ID. ¿Cuáles dos?

Las correctas son A y E. La A da el ahorro que se busca cuando no hay urgencia, y el custom ID empareja cada resultado con su petición. La E repara solo lo que falló. La B paga más de lo necesario. La C duplica el costo. La D falla porque los resultados pueden volver en cualquier orden.

Resumen: batch para lo que nadie espera, síncrono para lo que bloquea a alguien. El custom ID empareja resultados, y se reenvía solo lo fallido. Si te sirvió, sigue el podcast, dale cinco estrellas y activa las notificaciones. En la próxima cápsula vemos la revisión con varias instancias y varias pasadas. Nos escuchamos en la próxima cápsula de EvoAcademy.