Entrevista general: ¿Cómo deberías explicar HTTP 507 Insufficient Storage?

Planteamiento y contexto

Este planteamiento sobre fundamentos de HTTP y API encaja en roles de backend, plataforma, SRE e infraestructura. Una solicitud sería válida en principio, pero el servidor no puede almacenar el estado resultante del recurso porque se ha agotado una cuota, el sistema de archivos, el presupuesto de memoria o un límite de la aplicación. Explica cuándo 507 es significativo, cuándo otro estado es más preciso y cómo recuperarse sin duplicar una escritura.

Qué evalúa el entrevistador

• ¿Puedes separar el agotamiento de capacidad en el lado del servidor de una solicitud que intrínsecamente es demasiado grande?
• ¿Sabes que 507 se originó en WebDAV y es una condición temporal del servidor en lugar de un error genérico de validación?
• ¿Puedes definir el reintento, el backoff, la idempotencia y la remediación orientada al usuario sin ocultar la causa?
• ¿Puedes rastrear el límite a través de las capas de aplicación, almacenamiento, cuota, proxy y caché?

Preguntas aclaratorias para hacer

Pregunta qué operación falló, si la representación solicitada es válida, qué límite de recursos se alcanzó, si el límite es específico de un tenant y si la operación ya confirmó un estado parcial. Confirma si el cliente puede reintentar de forma segura y si el servicio expone una señal de cuota o capacidad. Si la carga útil excede una política o límite del analizador independientemente de la capacidad libre, usa 413; si el servicio no está disponible temporalmente por razones de procesamiento más amplias, 503 puede encajar mejor. No elijas 507 solo porque existe una alerta de disco en algún lugar de la flota.

Estructura para una respuesta de 30 segundos

Devolvería 507 cuando la operación solicitada sea por lo demás válida, pero el servidor no pueda registrar el estado resultante del recurso porque el almacenamiento disponible o un límite de servidor aplicable está agotado. Lo distinguiría de 413, que trata sobre una solicitud demasiado grande, y de 503, que representa una indisponibilidad temporal más amplia. La respuesta debe exponer un tipo de error estable y un ID de solicitud sin filtrar rutas internas. El cliente reintenta solo cuando la operación es idempotente o tiene una clave de idempotencia, con un backoff acotado; el operador mide la dimensión exacta agotada, libera o expande la capacidad y verifica una escritura completa antes de declarar la recuperación.

Análisis detallado paso a paso

1. Clasificar el fallo. RFC 4918 define 507 para un método que no puede registrar el estado del recurso después de su ejecución porque el destino carece de espacio suficiente. MDN señala que las implementaciones también lo usan para recursos de servidor o límites de aplicación agotados. La condición clave es una acción válida bloqueada por un límite de capacidad del lado del servidor.
2. Separar los estados vecinos. Devuelve 413 cuando el contenido sea demasiado grande independientemente de la capacidad actual. Devuelve 409 o 412 cuando falle un conflicto de estado o una precondición. Devuelve 503 cuando el servicio no pueda procesar solicitudes en general y pueda proporcionar Retry-After. Una respuesta 507 no debe convertirse en un comodín para todos los fallos de escritura.
3. Hacer que el fallo sea accionable. Utiliza un tipo de problema estable, un título legible por humanos, un ID de solicitud y una sugerencia de reintento solo si se espera que la capacidad se recupere. Las cuotas de tenant pueden incluir un identificador de cuota seguro o un enlace de remediación, mientras que las rutas del sistema de archivos, los nombres de host y los detalles de políticas secretas se mantienen internos.
4. Proteger los reintentos. Una carga que agotó el tiempo de espera puede tener un estado de confirmación desconocido. Exige una clave de idempotencia o un token de carga reanudable, persiste el estado de la operación y haz que el cliente consulte el estado antes de reintentar. Aplica backoff exponencial con un límite de tiempo; los reintentos ilimitados pueden amplificar la sobrecarga de un sistema lleno.
5. Rastrear el límite del recurso. Registra los bytes o inodos libres, la cuota del almacén de objetos, el uso de almacenamiento temporal/de base de datos, el límite de memoria, la asignación del tenant y la capa que emitió 507. Compara los registros de la aplicación con las métricas de almacenamiento y los ID de solicitud para que un error generado por un proxy no se confunda con una decisión del origen.
6. Recuperar y verificar. Drena o rechaza nuevas escrituras si es necesario, expande o reclama capacidad y vuelve a ejecutar una escritura acotada utilizando la clave de idempotencia original. Verifica el checksum del objeto, los metadatos, la visibilidad y la contabilidad de cuotas. Genera alertas ante recurrencias y comprueba que un tenant lleno no pueda consumir la reserva de otro tenant.

Ejemplo de una respuesta sólida

Usaría 507 solo cuando la solicitud sea válida pero el servidor no pueda persistir el estado resultante debido a que se agotó un límite de almacenamiento o de recursos del servidor. Una carga útil que siempre es demasiado grande es 413, y una condición amplia de mantenimiento o sobrecarga puede ser 503. Devolvería un tipo de problema estable y un ID de solicitud, además de una sugerencia de reintento solo cuando la recuperación sea plausible:

HTTP/1.1 507 Insufficient Storage
Content-Type: application/problem+json
Cache-Control: no-store
Retry-After: 120

{
  "type": "https://api.example.com/problems/storage-exhausted",
  "title": "The resource could not be stored",
  "status": 507,
  "detail": "The workspace storage limit prevented this operation.",
  "request_id": "req-7f2"
}

El cliente no debe reenviar a ciegas una carga cuyo estado de confirmación se desconoce. Reintenta con la misma clave de idempotencia o consulta primero el estado de la operación. Los operadores correlacionan la solicitud con las métricas de cuota, staging, almacén de objetos, base de datos e inodos, y luego verifican el checksum, la visibilidad y la contabilidad una vez restaurada la capacidad. Si una puerta de enlace emite 507 mientras que el origen devuelve 200, trato a la puerta de enlace como la capa emisora y pruebo cada salto de forma independiente.

Errores comunes

• Devolver 507 para una solicitud sobredimensionada → los cambios de capacidad no pueden hacer válida esa carga útil → usa 413 para una política fija de tamaño de solicitud.
• Reintentar cada 507 inmediatamente → un recurso lleno se vuelve más disputado → usa backoff acotado y un límite de tiempo para la operación.
• Reproducir una carga después de un timeout → la escritura original puede haberse confirmado → consulta el estado o reutiliza una clave de idempotencia.
• Decir "el disco está lleno" sin ubicar el límite → las cuotas, los inodos, el staging y el almacenamiento de objetos pueden fallar de forma independiente → identifica la capa emisora y la dimensión agotada.
• Reportar rutas sin procesar y nombres de host a los clientes → la topología interna y los datos de los tenants pueden filtrarse → devuelve un tipo de problema estable y un ID de solicitud, manteniendo los diagnósticos en registros protegidos.

Preguntas de seguimiento y respuestas

¿Debería un cliente reintentar HTTP 507?

Solo cuando sea seguro reintentar la operación y se espere que la capacidad se recupere. Usa una clave de idempotencia o búsqueda de estado para las escrituras, backoff exponencial y un tiempo límite. Si el error representa una cuota estricta de tenant, presenta opciones de remediación en lugar de reintentar.

¿Cómo diferencias 507 de 503?

507 identifica la incapacidad de registrar un estado de recurso válido porque se agotó un límite de almacenamiento o del servidor. 503 es una incapacidad temporal más amplia para atender la solicitud y puede abarcar mantenimiento o sobrecarga. Utiliza el límite de fallo medido y una política de servicio coherente en lugar de adivinar únicamente a partir de la capa HTTP.

¿Qué pasa si el origen tuvo éxito pero un proxy devolvió 507?

Captura los ID de solicitud y compara las solicitudes directas al origen, a través del proxy y con caché fría. El proxy es la capa emisora y puede tener su propio búfer o cuota. Reconcilia el estado final del cliente antes de reintentar, ya que el origen podría contener ya el recurso.