Un trabajo de 0.34 segundos esperaba detrás de tareas AI lentas. Separar carriles ayudó; también hacían falta respuestas duraderas, reintentos acotados y recuperación.
Autor
Anichur Rahaman
El estudiante termina el examen y espera su ficha de mérito. Recalcularla tarda unos 0.34 segundos. El registro del 6 de octubre recoge retrasos de 10–115 minutos: el trabajo corto esperaba detrás de unas 2,000 tareas AI de aproximadamente diez segundos, con dos trabajadores compartiendo cola.
NovaCommerce es una plataforma anonimizada de cursos y exámenes. La parte 4 conserva observaciones de septiembre–octubre de 2026 y distingue cambios implementados de salvaguardas recomendadas. No es una auditoría nueva ni un benchmark de StoreConsole.
Valkey gestionado guardaba sesiones, caché y colas para facilitar la sustitución de nodos web. También era una dependencia común: el ensayo del 6 de octubre registró 2,854 timeouts de conexión. El caso describe conexiones TLS nuevas y un aumento de 4 GB a 8 GB por nodo, primario y reserva. La rampa posterior de 25–500 requests/s tuvo cero errores de aplicación, pero 143 errores del balanceador con CPU saturada. Cambió el fallo de conexión; el recorrido completo seguía rechazando trabajo.
Un timeout no demuestra falta de memoria ni un coste CPU preciso del handshake. Investiga rotación de conexiones, límites, red y métricas. El 12.5% de memoria durante un examen es una observación. noeviction evita expulsar claves por presión de memoria, pero puede rechazar escrituras nuevas; no aporta persistencia de cola, failover sin pérdidas ni aislamiento entre caché, sesiones y trabajos.
El equipo separó narrativas AI de mérito/posición. Según el caso, las fichas pasaron a llegar en aproximadamente un minuto. Nombres de cola separados no bastan: asignación de procesos, conexiones y CPU compartida deben dejar capacidad para lo urgente.
La aritmética anterior explica la espera: 2,000×10=20,000 segundos de trabajo; entre dos trabajadores, unos 10,000 segundos, 166.7 minutos, sin sobrecoste. Ilustra la cola, no predice una terminación exacta. Es independiente del limitador posterior: a ocho llamadas/minuto compartidas, 2,000 tareas de una llamada requieren al menos 250 minutos, 4 horas 10 minutos, sin reintentos ni nuevas llegadas.
| Clase de fallo | Respuesta | Evidencia de finalización |
|---|---|---|
| Límite transitorio | Límite compartido; Retry-After; jitter acotado | Operación original conciliada |
| Crédito/autenticación | Pausar; avisar; corregir | Reanudar con control y plazo válido |
| Resultado externo desconocido | Consultar/conciliar antes de repetir | Sin efecto duplicado |
| Plazo agotado | Conservar fallo/pendiente; revisar | Repetición auditada o estado final |
| Trabajador perdido | Restaurar proceso y conciliar registro | Trabajo aceptado contabilizado |
La cola histórica aplicó ocho llamadas/minuto compartidas, backoff exponencial de 1–15 minutos con jitter, ventana de hasta 12 horas y texto temporal de plantilla. El caso registró unas 3,800 narrativas retrasadas por falta de crédito y reanudación después de recargar. No demuestra que todas terminaran ni que ninguna pudiera caducar.
La tasa era configuración del caso, no un derecho garantizado por el proveedor; también pueden existir límites de tokens y concurrencia. Respeta Retry-After si llega. Reintenta fallos transitorios dentro de una fecha límite absoluta; pausa o detén autenticación permanente, payload inválido y crédito agotado, avisando al responsable. Muestra pendiente/plantilla con claridad. Al vencer, conserva el fallo revisable y una repetición controlada.
Un timeout de red puede ocultar una llamada ya completada. Antes de repetir efectos usa identidad estable, idempotencia admitida o conciliación de estado. Devuelve cuota interna solo ante una reserva confirmada como no consumida; cambiar un contador no devuelve la factura del proveedor. Audita reservas y resultados. Son comprobaciones de diseño, no nuevas capacidades verificadas en aquel sistema.
Un Droplet fijo de 4 vCPU/8 GB ejecutaba colas, programador, WebSockets y SMS, cuyo gateway permitía una IP saliente. Existía snapshot; recuperación con IP reservada, trabajador de reserva y capacidad de examen estaban planificados. Esa dirección debe soportar realmente el egreso requerido y la lista permitida; asignarla no prueba el envío de SMS.
Si cae el trabajador se detiene la finalización en segundo plano. Las respuestas aceptadas necesitan ya un registro duradero autoritativo; no prometas seguridad solo por tener una cola Valkey. Prueba persistencia, conciliación y repetición tras failover. Varios trabajadores son normales con reservas seguras y efectos idempotentes. Un programador o un lock distribuido no garantizan exactamente una vez tras un crash. Mantén el timeout del trabajo por debajo de visibilidad/retry_after cuando corresponda; eso es distinto del backoff.
Dos capas limitaban IP en lugar de estudiante autenticado. El 7 de octubre, alrededor del 74% de las llamadas a un endpoint de panel devolvieron 429; claves por cuenta/ruta resolvieron después ese endpoint. No justifica eliminar protecciones de abuso. Conserva límites de cuenta, invitado/red y proveedor; confía cabeceras solo desde proxies controlados. Una IP firmada tampoco autoriza.
Fluent Bit enviaba logs del backend a OpenSearch. El frontend seguía pendiente, con unos 440 MB/día locales expuestos a borrado del nodo. Hacen falta buffers acotados, vigilancia de entrega, acceso restringido y eliminación de respuestas, tokens y datos privados de los logs. Fuera del nodo no significa entrega instantánea sin pérdidas.
El resumen del examen vigilaba inicios/envíos, requests/5xx por nodo, CPU, colas y fallos. Reducir el mínimo durante el examen causó, según el caso, unas 360 peticiones fallidas en dos minutos. El runbook contra esa reducción era una protección humana, no un bloqueo obligatorio. Observa antigüedad del trabajo y resultados pendientes, no solo CPU o cero fallos registrados. La parte 5 revisa qué demostraron las pruebas.
Revisión: 6 de noviembre de 2026. Anichur Rahaman, fundador de StoreConsole. Observaciones existentes conservadas; fuentes primarias para el comportamiento general, no una nueva verificación del sistema privado.
Sobre el autor
Anichur Rahaman
Seguir Leyendo
