Recorrido por un servicio de carga de archivos: tickets directos al almacenamiento, escaneo asíncrono y cuotas

Objetivo

Permitir que los clientes carguen archivos directamente al almacenamiento de objetos, mantener a los servidores de aplicación fuera de la ruta de los bytes, y admitir un archivo en el producto solo después de haberlo comprobado y de haberlo contabilizado contra una cuota.

Requisitos previos

Un almacenamiento de objetos que emita URL de carga firmadas con tiempo limitado, un escáner que se ejecute como job, una cuota por propietario y las reglas de validación de tipos y nombres ya existentes.

Pasos

1. Restricciones: los servidores de aplicación nunca actúan de proxy de los bytes; un archivo permanece invisible hasta que se comprueba; las cargas abandonadas no deben retener cuota ni almacenamiento indefinidamente.
2. Componentes: una API de carga que emite tickets; un bucket con los prefijos incoming/ y ready/ (o dos buckets); un endpoint de finalización o un consumidor de eventos de almacenamiento; un worker de escaneo; un libro de cuotas; una ruta de entrega con URL de descarga firmadas de corta duración.
3. Flujo: el cliente solicita un ticket con el tamaño y el tipo declarados; la API comprueba la cuota, reserva el tamaño declarado, registra el ticket y devuelve una URL PUT firmada para una clave de objeto, con una expiración de minutos. La documentación de S3 describe las URL prefirmadas como limitadas por los permisos de la identidad que las creó, así que la identidad firmante solo debería poder escribir en incoming/. Tras la carga, el cliente llama a complete; el servicio lee del almacenamiento el tamaño y el tipo reales, rechaza las discrepancias y encola un escaneo. El worker mueve el objeto a ready/ o lo elimina, y registra el motivo.
4. Modelo de datos: upload(id, owner, status: ticketed|uploaded|scanning|ready|rejected|expired, declared_bytes, actual_bytes, content_type, storage_key, ticket_expires_at, created_at); quota(owner, limit_bytes, used_bytes, reserved_bytes), actualizado en la misma transacción que cada cambio de estado.
5. Modos de fallo: tickets que nunca se completan (un job de expiración libera la reserva; una regla de ciclo de vida elimina los objetos obsoletos de incoming/, y S3 documenta una acción de ciclo de vida AbortIncompleteMultipartUpload para las cargas multiparte sin terminar); dos cargas compitiendo por rebasar la cuota (reservar bajo un bloqueo de fila); acumulación en el escáner que deja archivos en scanning (mostrar el estado, alertar por la antigüedad de la cola); un archivo compartido antes de que termine el escaneo (servir únicamente desde ready/); un objeto almacenado cuya llamada a complete se perdió (aceptar un complete tardío, reconciliar contra los listados de almacenamiento).
6. Medir: el tiempo de ticket a ready, la proporción de tickets expirados, la antigüedad de la cola de escaneo, los motivos de rechazo, las solicitudes denegadas por cuota, los objetos huérfanos encontrados por reconciliación.
7. No es prioritario: la carga multiparte reanudable para archivos pequeños, las derivadas de imagen, la deduplicación por hash, el cifrado del lado del cliente, las carpetas.

Resultado esperado

Los bytes fluyen del cliente al almacenamiento; el servicio solo maneja metadatos, y cada objeto almacenado corresponde a una fila cuyo estado explica por qué existe.

Límites y base de verificación

Diseño propuesto, sin mediciones. La validación de nombres y tipos está cubierta por el artículo de carga existente. Que una URL PUT firmada pueda acotar el tamaño del objeto depende del producto de almacenamiento, razón por la cual el tamaño se verifica después de la carga.