Los usuarios necesitan subir archivos de hasta dos gigabytes. ¿Cómo lo diseñarías de extremo a extremo?

No hagas pasar los bytes por tu API. Que el cliente pida una URL de subida prefirmada, suba directamente al almacenamiento de objetos con subida multiparte para archivos grandes y luego avise a tu servicio, que verifica el objeto y guarda los metadatos. Valida el tipo de contenido y los límites de tamaño en la propia política, escanea de forma asíncrona antes de que el archivo sea usable, y genera URLs firmadas de vida corta para las descargas en lugar de hacer públicos los objetos.

La primera decisión es que el archivo nunca pasa por mi API, porque dos gigabytes a través de un manejador de peticiones bloquean un worker, cuestan ancho de banda dos veces y se rompen en cuanto se cae una conexión. Así que el cliente pide a mi servicio una URL de subida prefirmada, acotada con precisión a una clave, un tipo de contenido y una caducidad corta, y sube directamente al almacenamiento de objetos. Para archivos de este tamaño uso subida multiparte, que me da reanudación, porque una parte fallida se reintenta en vez de todo el archivo. Cuando la subida termina el cliente llama de vuelta o, mejor, el almacenamiento emite un evento, y mi servicio verifica que el objeto existe y coincide con el tamaño esperado antes de escribir los metadatos. El archivo empieza en estado pendiente y solo pasa a usable tras el procesamiento asíncrono: escaneo, comprobar el tipo de contenido real a partir de los bytes en lugar de fiarse de la extensión, y generar las miniaturas que hagan falta. Las descargas van por una URL firmada de vida corta emitida tras una comprobación de autorización, nunca por un bucket público, que es de donde vienen sorprendentemente muchas filtraciones de datos.