Nutzer sollen Dateien bis zwei Gigabyte hochladen können. Wie würdest du das von Ende zu Ende bauen?

Leite die Bytes nicht durch deine API. Lass den Client eine Presigned Upload URL anfordern, direkt in den Object Storage hochladen, bei großen Dateien mit Multipart Upload, und danach deinen Service benachrichtigen, der das Objekt prüft und die Metadaten schreibt. Validier Content-Type und Größenlimits auf Policy-Ebene, scanne asynchron, bevor die Datei nutzbar wird, und erzeug für Downloads kurzlebige signierte URLs, statt Objekte öffentlich zu machen.

Die erste Entscheidung ist, dass die Datei nie durch meine API geht, denn zwei Gigabyte durch einen Request-Handler blockieren einen Worker, kosten Bandbreite doppelt und brechen in dem Moment, in dem eine Verbindung abreißt. Der Client fragt also bei meinem Service eine Presigned Upload URL an, eng auf einen Key, einen Content-Type und eine kurze Gültigkeit begrenzt, und lädt direkt in den Object Storage. Bei dieser Größe nehme ich Multipart Upload, was mir Wiederaufnahme gibt, denn ein fehlgeschlagener Part wird wiederholt statt der ganzen Datei. Ist der Upload fertig, ruft der Client zurück, oder besser, der Storage emittiert ein Event, und mein Service prüft, dass das Objekt existiert und der erwarteten Größe entspricht, bevor er Metadaten schreibt. Die Datei startet in einem Pending-Status und wird erst nach der asynchronen Verarbeitung nutzbar: Scannen, den echten Content-Type aus den Bytes prüfen statt der Endung zu vertrauen, und Thumbnails erzeugen. Downloads laufen über eine kurzlebige signierte URL, ausgestellt nach einer Autorisierungsprüfung, nie über einen öffentlichen Bucket, woher überraschend viele Datenlecks stammen.