Les utilisateurs doivent téléverser des fichiers allant jusqu'à deux gigaoctets. Comment concevriez-vous ça de bout en bout ?

Ne faites pas transiter les octets par votre API. Faites demander au client une URL de téléversement présignée, téléversez directement vers un stockage objet avec un téléversement multipart pour les gros fichiers, puis notifiez votre service, qui vérifie l'objet et enregistre les métadonnées. Validez le type de contenu et les limites de taille au niveau de la politique, scannez de façon asynchrone avant que le fichier soit utilisable, et générez des URL signées à courte durée de vie pour les téléchargements plutôt que de rendre les objets publics.

La première décision, c'est que le fichier ne passe jamais par mon API, parce que deux gigaoctets à travers un gestionnaire de requête mobilisent un worker, coûtent deux fois la bande passante et cassent dès qu'une connexion tombe. Donc le client demande à mon service une URL de téléversement présignée, limitée strictement à une clé, un type de contenu et une expiration courte, et téléverse directement vers le stockage objet. Pour des fichiers de cette taille, j'utilise le téléversement multipart, qui me donne la reprise, puisqu'une partie échouée est rejouée au lieu du fichier entier. Quand le téléversement se termine, le client rappelle, ou mieux, le stockage émet un événement, et mon service vérifie que l'objet existe et correspond à la taille attendue avant d'écrire les métadonnées. Le fichier démarre dans un état en attente et ne devient utilisable qu'après un traitement asynchrone : analyse antivirus, vérification du vrai type de contenu à partir des octets plutôt qu'en faisant confiance à l'extension, et génération des miniatures éventuelles. Les téléchargements passent par une URL signée à courte durée de vie émise après un contrôle d'autorisation, jamais par un bucket public, ce qui est à l'origine d'un nombre surprenant de fuites de données.