Planteamiento y alcance
La carga de un video pasa a través de una CDN, un API gateway, un servicio de aplicación y un almacenamiento de objetos, cada uno con un tamaño aceptado diferente. Diseña la respuesta 413 Content Too Large, el descubrimiento de límites, la carga reanudable, Retry-After, el cuerpo del error y el monitoreo.
Esta es una pregunta de confiabilidad de API en el backend. La cantidad de capas y el tamaño del video son suposiciones, no afirmaciones de frecuencia.
Qué está evaluando el entrevistador
- Si separas los límites permanentes, la capacidad temporal y los fallos de validación del cuerpo.
- Si explicas con precisión la relación entre 413 y Retry-After.
- Si diseñas reanudabilidad en lugar de reintentar el cuerpo completo.
- Si manejas los límites de proxies, la idempotencia y la fuga de información.
Preguntas de clarificación para hacer
- ¿Qué capa emitió el 413 y se conservan su alcance y request ID?
- ¿El límite es por solicitud, inquilino (tenant), objeto, ventana de tiempo o cuota restante?
- ¿Puede el cliente usar fragmentos (chunks), reanudar y consultar una sesión de carga?
- ¿El límite es una configuración fija o una capacidad o cuota temporal?
- ¿Los bytes recibidos pueden generar efectos secundarios de facturación, bloqueos o metadatos de objetos?
Una respuesta de 30 segundos
“413 significa que el servidor se rehúsa a procesar contenido que es demasiado grande. Un límite fijo no debería hacer esperar al cliente; una condición temporal puede incluir Retry-After. El edge debe rechazar de forma temprana con un código estable, request ID y una restricción pública, mientras que la aplicación sigue validando los bytes reales. Los archivos grandes utilizan una sesión de carga, fragmentos y una finalización idempotente. Tras una desconexión, se consulta el estado antes de reenviar; nunca se reenvían fragmentos confirmados. Mido el 413 por capa, inquilino y tamaño”.
Diseño paso a paso
1. Definir límites por capas
Los máximos fijos, las cuotas por inquilino, las políticas de objetos y la capacidad en tiempo de ejecución necesitan responsables claros. Un edge puede rechazar a partir de Content-Length, pero la aplicación también debe verificar los bytes recibidos, el tamaño descomprimido y la política de contenido. Incluye un request ID en el error; no reveles nodos internos, capacidad de disco o datos de otro inquilino.
2. Usar Retry-After correctamente
El RFC 9110 permite que un servidor genere Retry-After cuando la condición 413 es temporal. El valor puede ser una fecha HTTP o segundos de retraso. Un máximo fijo necesita una solicitud modificada o fragmentos, no esperar. Usa el encabezado para una cuota conocida o una ventana de recuperación por mantenimiento, y haz que los clientes limiten (cap) y validen el retraso.
HTTP/1.1 413 Content Too Large
Retry-After: 120
Content-Type: application/problem+json
X-Request-Id: req-81a3. Hacer que el error sea procesable (actionable)
Devuelve un código estable, el alcance, el modo de carga permitido, el tamaño máximo de fragmento y un punto de entrada para la sesión de carga. Nunca expongas nombres de implementación del gateway, stack traces o errores de base de datos. El cliente puede comprimir, redimensionar, fragmentar o solicitar cuota basándose en el código en lugar de reintentar el mismo cuerpo indefinidamente.
4. Proveer carga reanudable
Crea primero una sesión de carga y devuelve su ID, expiración, rango de tamaño de fragmento y una consulta para fragmentos completados. Cada fragmento lleva un digest y una clave de idempotencia; la finalización solo hace referencia a fragmentos verificados. Ante un 413, el cliente puede reducir un nuevo fragmento o crear una nueva sesión sin retransmitir datos confirmados.
5. Manejar capas inconsistentes
El gateway puede devolver 413 antes que la aplicación, mientras que la aplicación puede rechazar después de verificaciones de descompresión, cuota o políticas. Un modelo de error compartido no puede asumir que cada capa conoce el límite final. Devuelve las restricciones actuales en la creación de la sesión, monitorea los orígenes de 413 y no almacenes en caché el valor temporal de una capa como un límite global permanente.
6. Vincular reintentos, facturación y métricas
Clasifica el 413 en el cliente: modifica la solicitud para un límite fijo, sigue Retry-After para un límite temporal y consulta el estado de la sesión tras un fallo en la sesión. Usa idempotencia para la finalización de modo que la facturación no se duplique, y haz expirar las sesiones abandonadas. Rastrea la capa de origen, el inquilino, el tamaño de solicitud, los bytes cargados, el cumplimiento de Retry-After, la retransmisión de fragmentos y la recuperación final para detectar desviaciones en los límites.
Respuesta modelo de alta calidad
“Primero identifico la capa emisora y el tipo de límite. Un máximo fijo devuelve 413 con una restricción pública o un punto de entrada para fragmentos; solo una cuota o capacidad temporal devuelve Retry-After. Los archivos grandes utilizan sesiones y fragmentos con digests e idempotencia, y un cliente desconectado consulta los fragmentos confirmados. El edge rechaza de forma temprana, mientras que la aplicación verifica los bytes reales y descomprimidos. El cuerpo del error expone solo un código estable, request ID y el siguiente paso. Mido el origen, la distribución de tamaños, el cumplimiento de espera, las finalizaciones duplicadas y la tasa de recuperación”.
Errores comunes
- Agregar Retry-After a cada 413 → los límites fijos provocan esperas inútiles → usa tiempo solo para condiciones temporales.
- Codificar de forma fija (hard-code) un límite en el cliente → las capas divergen → devuelve las restricciones de sesión y monitorea el origen.
- Reenviar el cuerpo completo → el ancho de banda y los efectos secundarios se multiplican → usa fragmentos, consultas y finalización idempotente.
- Verificar únicamente Content-Length → los bytes reales o descomprimidos pueden exceder los límites → valida durante y después de la ingesta.
- Exponer límites internos → se filtran la topología y la capacidad → devuelve un código estable y un request ID.
Preguntas de seguimiento y respuestas
¿Qué debería hacer un cliente cuando 413 no tiene Retry-After?
No adivines un retraso. Trátalo como un límite fijo o desconocido, usa el código de error y el estado de la sesión, y cambia a una solicitud más pequeña, fragmentos o un flujo explícito de solicitud de cuota. Automatiza la espera únicamente cuando el servidor proporcione un tiempo de recuperación.
¿Qué sucede si un fragmento también excede el límite de una capa?
Devuelve el rango permitido actualmente al crear la sesión y elige un fragmento que no sea mayor que el límite efectivo más pequeño. Si la política cambia, conserva los fragmentos confirmados y continúa con nuevos parámetros de sesión en lugar de reenviar los fragmentos antiguos.
El gateway devolvió 413 pero la aplicación no tiene registro. ¿Cómo lo depuras?
Compara los request IDs, los bytes recibidos y el origen de la respuesta a través del edge, el gateway y la aplicación. Si la aplicación no tiene registro, inspecciona primero los límites del gateway, el enrutamiento y el reenvío del cuerpo; la ausencia de logs en la aplicación no demuestra un rechazo por parte de esta.