Étude de cas d'un service de téléversement de fichiers : tickets directs vers le stockage, analyse asynchrone et quotas

Objectif

Permettre aux clients de téléverser des fichiers directement vers le stockage d'objets, garder les serveurs d'application hors du chemin des octets, et n'admettre un fichier dans le produit qu'après vérification et décompte par rapport à un quota.

Prérequis

Un stockage d'objets capable d'émettre des URL de téléversement signées à durée limitée, un scanner qui s'exécute comme un job, un quota par propriétaire, et les règles de validation existantes pour les types et les noms.

Étapes

1. Contraintes : les serveurs d'application ne relaient jamais les octets ; un fichier reste invisible tant qu'il n'a pas été vérifié ; les téléversements abandonnés ne doivent pas retenir indéfiniment de quota ou de stockage.
2. Composants : une API de téléversement qui émet les tickets ; un bucket avec les préfixes incoming/ et ready/ (ou deux buckets) ; un point de terminaison de finalisation ou un consommateur d'événements de stockage ; un worker d'analyse ; un registre de quotas ; un chemin de service avec des URL de téléchargement signées à courte durée de vie.
3. Flux : le client demande un ticket avec la taille et le type déclarés ; l'API vérifie le quota, réserve la taille déclarée, enregistre le ticket et renvoie une URL PUT signée pour une clé d'objet, avec une expiration de l'ordre de quelques minutes. La documentation S3 décrit les URL présignées comme limitées par les permissions de l'identité qui les a créées, donc l'identité de signature ne devrait pouvoir écrire que dans incoming/. Après le téléversement, le client appelle complete ; le service lit la taille et le type réels depuis le stockage, rejette les incohérences et met une analyse en file d'attente. Le worker déplace l'objet vers ready/ ou le supprime, et consigne le motif.
4. Modèle de données : 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), mis à jour dans la même transaction que chaque changement de statut.
5. Modes de défaillance : des tickets jamais finalisés (un job d'expiration libère la réservation ; une règle de cycle de vie supprime les objets incoming/ périmés, et S3 documente une action de cycle de vie AbortIncompleteMultipartUpload pour les téléversements multipart inachevés) ; deux téléversements en concurrence dépassant le quota (réserver sous un verrou de ligne) ; un arriéré du scanner laissant des fichiers en scanning (afficher le statut, alerter sur l'âge de la file) ; un fichier partagé avant la fin de l'analyse (ne servir que depuis ready/) ; un objet stocké dont l'appel complete a été perdu (accepter un complete tardif, réconcilier avec les listages du stockage).
6. Mesurer : le temps entre l'émission du ticket et le passage à ready, la proportion de tickets expirés, l'âge de la file d'analyse, les motifs de rejet, les requêtes refusées pour quota, les objets orphelins trouvés par réconciliation.
7. Pas en priorité : le multipart reprenable pour les petits fichiers, les dérivés d'images, la déduplication par hash, le chiffrement côté client, les dossiers.

Résultat attendu

Les octets circulent directement du client vers le stockage ; le service ne gère que les métadonnées, et chaque objet stocké correspond à une ligne dont le statut explique pourquoi il existe.

Limites et base de vérification

Conception proposée, sans mesures. La validation des noms et des types est couverte par l'article existant sur le téléversement. La capacité d'une URL PUT signée à borner la taille de l'objet dépend du produit de stockage, c'est pourquoi la taille est vérifiée après le téléversement.