Durchgang durch einen Datei-Upload-Dienst: Tickets direkt zum Speicher, asynchrones Scannen und Kontingente

Ziel

Clients direkt in den Objektspeicher hochladen lassen, Anwendungsserver aus dem Bytepfad heraushalten und eine Datei erst nach Prüfung und Anrechnung auf ein Kontingent im Produkt zulassen.

Voraussetzungen

Objektspeicher, der zeitlich begrenzte signierte Upload-URLs ausstellt, ein als Job laufender Scanner, ein Kontingent pro Eigentümer sowie die bestehenden Validierungsregeln für Typen und Namen.

Schritte

1. Randbedingungen: Anwendungsserver leiten nie Bytes weiter; eine Datei ist unsichtbar, bis sie geprüft wurde; abgebrochene Uploads dürfen weder Kontingent noch Speicherplatz dauerhaft belegen.
2. Komponenten: eine Upload-API, die Tickets ausstellt; ein Bucket mit den Präfixen incoming/ und ready/ (oder zwei Buckets); ein Abschluss-Endpunkt oder ein Konsument von Storage-Events; ein Scan-Worker; ein Kontingentbuch; ein Auslieferungspfad mit kurzlebigen signierten Download-URLs.
3. Ablauf: Der Client fordert ein Ticket mit angegebener Grösse und Typ an; die API prüft das Kontingent, reserviert die angegebene Grösse, protokolliert das Ticket und gibt eine signierte PUT-URL für einen Objektschlüssel mit einer Gültigkeit von wenigen Minuten zurück. Die S3-Dokumentation beschreibt vorsignierte URLs als begrenzt durch die Berechtigungen der Identität, die sie erstellt hat, weshalb die signierende Identität nur nach incoming/ schreiben können sollte. Nach dem Upload ruft der Client den Abschluss auf; der Dienst liest die tatsächliche Grösse und den Typ aus dem Speicher, weist Abweichungen zurück und reiht einen Scan ein. Der Worker verschiebt das Objekt nach ready/ oder löscht es und hält den Grund fest.
4. Datenmodell: 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), aktualisiert in derselben Transaktion wie jede Statusänderung.
5. Fehlerfälle: nie abgeschlossene Tickets (ein Ablaufjob gibt die Reservierung frei; eine Lebenszyklusregel löscht veraltete incoming/-Objekte, und S3 dokumentiert eine Lebenszyklusaktion AbortIncompleteMultipartUpload für unvollständige mehrteilige Uploads); zwei Uploads, die um das Kontingent wettlaufen (unter einer Zeilensperre reservieren); Scan-Rückstand, der Dateien im Status scanning belässt (den Status anzeigen, bei Alter der Warteschlange alarmieren); eine Datei, die geteilt wird, bevor der Scan abgeschlossen ist (nur aus ready/ ausliefern); ein gespeichertes Objekt, dessen Abschlussaufruf verloren ging (einen späten Abschluss akzeptieren, mit Speicherlisten abgleichen).
6. Messen: Zeit von Ticket bis Ready, Anteil abgelaufener Tickets, Alter der Scan-Warteschlange, Ablehnungsgründe, wegen Kontingent abgelehnte Anfragen, durch Abgleich gefundene verwaiste Objekte.
7. Nicht zuerst: fortsetzbare mehrteilige Uploads für kleine Dateien, Bildableitungen, Deduplizierung nach Hash, clientseitige Verschlüsselung, Ordner.

Erwartetes Ergebnis

Bytes fliessen vom Client zum Speicher; der Dienst verwaltet nur Metadaten, und jedes gespeicherte Objekt ist einer Zeile zugeordnet, deren Status erklärt, warum es existiert.

Grenzen und Prüfbasis

Vorgeschlagenes Design, keine Messungen. Die Validierung von Namen und Typen wird vom bestehenden Artikel zu Uploads abgedeckt. Ob ein signiertes PUT die Objektgrösse begrenzen kann, hängt vom Speicherprodukt ab, weshalb die Grösse erst nach dem Upload verifiziert wird.