Guide complet gratuit

système de synchronisation de fichiers

Concevez système de synchronisation de fichiers.

Points de contrôle de pratique

Le rythme de l’entretien reste compact, pour que la page consacre son attention aux vraies décisions de conception.

01
Clarifier le périmètre
02
Besoins + échelle
03
API + modèle de données
04
Dessiner l’architecture
05
Deep dive
06
Décision de compromis

Les besoins qui façonnent la conception

Ne vous contentez pas d’énoncer les besoins : demandez-les. Chaque carte associe la contrainte de conception à une question de clarification que vous pouvez dire à voix haute avant de dessiner l’architecture.

Besoins fonctionnels

01Quelle taille maximale pour un seul fichier ?

Les utilisateurs téléversent et téléchargent depuis n’importe quel appareil, avec des fichiers jusqu’à 50 GB.

02La synchronisation est-elle automatique, et qu'advient-il des modifications hors ligne ?

Les fichiers se synchronisent automatiquement sur tous les appareils. Les modifications faites hors ligne sont fusionnées à la reconnexion de l'appareil. La copie serveur fait foi.

03Que signifie le partage — une copie, ou le même fichier ?

Le partage donne accès au même fichier, pas à une copie. Les destinataires le voient dans leur propre vue. Toute mise à jour parvient à tous ceux qui y ont accès.

04Les dossiers, déplacements et renommages sont-ils des opérations sur fichiers ?

Non. Les dossiers ne sont que des métadonnées. Déplacer et renommer ne changent que les métadonnées et ne touchent jamais les blocs stockés, donc ils restent instantanés à n'importe quelle taille de fichier.

05Le partage porte-t-il des permissions — lecture seule vs édition ?

Oui. Chaque partage porte un rôle (lecteur/éditeur), et le service de métadonnées l'applique. Les URLs présignées sont limitées au rôle qui les a demandées.

06Les suppressions se synchronisent-elles, et un utilisateur peut-il récupérer un fichier supprimé ?

Les suppressions se synchronisent comme toute autre modification, via des tombstones. Les blocs restent dans une fenêtre de corbeille avant d'être récupérés. Une erreur synchronisée a besoin d'un moyen d'être annulée.

Hors périmètreÉdition collaborative en place (c'est la question de l'édition collaborative de documents) · Aperçu et rendu sans téléchargement · Interface d'historique des versions (le modèle de données conserve latest_version, mais parcourir l'historique est hors périmètre)

Besoins non fonctionnels

01Quand le réseau se partitionne, qu'est-ce qui doit continuer à fonctionner ?

Disponibilité plutôt que cohérence : une liste de fichiers périmée pendant quelques secondes, c'est acceptable ; faire échouer un téléversement, non.

02Que se passe-t-il quand un téléversement de 50 Go meurt à 49 Go ?

Il reprend depuis le dernier bloc vérifié — jamais de redémarrage. L'état des blocs est suivi côté serveur, donc n'importe quel appareil peut poursuivre le téléversement.

03Comment savons-nous qu'un fichier n'a pas été corrompu en transit ?

Chaque chunk et le fichier entier portent des empreintes SHA-256. Un chunk n'est marqué comme uploadé qu'après confirmation des octets par la couche de stockage.

04Deux utilisateurs téléversent la même vidéo de 2 Go — la stocke-t-on deux fois ?

Non : des empreintes identiques signifient un contenu identique — les métadonnées pointent les deux utilisateurs vers les mêmes blocs stockés.

05À quel point la synchronisation entre appareils doit-elle être fraîche ?

Des secondes : les appareils en ligne reçoivent des notifications de changement par push, avec un sondage périodique comme filet de sécurité.

Continuez à demander — l’entretien est une conversation

Les vrais entretiens sondent bien plus qu’une liste propre. Ces questions de périmètre séparent ceux qui interrogent le problème de ceux qui le récitent.

Quelle est la taille maximale d'un fichier — des mégaoctets ou des dizaines de gigaoctets ?
L'édition collaborative en place est-elle dans le périmètre, ou seulement les fichiers-en-blobs ?
Quand deux appareils modifient le même fichier hors ligne, que doit finir par voir l'utilisateur ?
Avons-nous besoin de l'historique des versions, ou seulement de la dernière version ?
Un contenu identique téléversé par différents utilisateurs doit-il être stocké une seule fois ?

Les chiffres qui forcent les décisions d’architecture

Traitez chaque estimation comme une pression qui justifie un composant : cache, file, partition, réplica, pool de workers ou chemin de repli.

Blocs par gros fichier

fichier de 50 Go ÷ blocs de 5 Mo50,000 MB ÷ 5 MB = 10,000 blocs

Cela fait dix mille uploads qui tournent en parallèle et peuvent chacun reprendre tout seuls. Voilà pourquoi un seul POST géant ne peut jamais marcher.

Coût de reprise après échec

Le téléversement meurt à 98 %réessai = les ~200 blocs restants, pas 10,000

Le suivi de l'état des blocs transforme un redémarrage catastrophique en un complément de 2 %.

Gain de déduplication

Même fichier téléversé par N utilisateurs, empreintes concordantescoût de stockage = 1 copie + N lignes de métadonnées

Le stockage adressé par contenu rend le deuxième téléversement et tous les suivants presque gratuits.

Modifier un octet

Découpage à taille fixe vs découpage défini par le contenu (CDC)fixe : une insertion de 1 octet décale chaque frontière → presque tous les blocs se re-téléversent · CDC : seuls les blocs touchés

Le CDC (rolling hash) est ce qui rend la synchronisation delta bon marché pour les fichiers modifiés.

Fenêtre des URL présignées

URL valides ~5 minutes, limitées à un seul blocfenêtre de fuite = minutes · rayon d'impact = un bloc

Des URL à courte durée et à portée étroite constituent l'argument de sécurité du téléversement direct depuis le client.

Exemple de décision

Les chiffres

Un fichier de 50 Go, c'est dix mille blocs de 5 Mo. À cette taille, les problèmes intéressants ne sont pas le stockage — ce sont la reprise, la déduplication, et ce qui arrive quand deux appareils modifient le même fichier.

Mon choix

Les clients découpent et empreignent les fichiers localement, puis uploadent les chunks en parallèle directement vers le blob storage via des URLs présignées de courte durée. L'API ne gère que les métadonnées, et elle vérifie l'ETag de chaque chunk avant de le marquer terminé. La synchronisation marche en poussant une notification, puis chaque appareil se réconcilie contre un curseur changes-since. Pour les conflits, le last write wins pour la copie principale. La modification perdante est gardée en copie de conflit à côté, si bien que l'utilisateur ne perd rien et la résout lui-même.

À éviter

Ce que je NE ferais PAS : router les octets des fichiers à travers mes serveurs d'API. Ils deviennent un goulet d'étranglement de bande passante et une surface d'attaque, pour aucun bénéfice. Et je ne jetterais pas en silence la modification perdante lors d'un conflit. Le pur last-write-wins convient pour une LISTE de fichiers. Mais pour le CONTENU d'un fichier, jeter discrètement l'après-midi de travail de quelqu'un, c'est comme ça qu'on perd des clients.

Changer si

Si l'édition collaborative en place entre dans le périmètre, la synchronisation au niveau des blobs est le mauvais outil. Cela devient des transformations opérationnelles ou des CRDTs sur la structure du document. C'est un design différent, et une autre question d'entretien.

Chemin d’architecture

D’abord une image complète, puis chaque chemin comme son propre schéma — le chemin d’écriture et le chemin de lecture portent un trafic différent et justifient des composants différents.

Image complète

Vue d’ensemble — chaque composant

Les octets des fichiers circulent client → blob storage directement (URLs présignées). Seules les métadonnées passent par l'API. Le service de notification dit aux autres appareils de tirer le curseur des changements.

Chemin 1

Chemin de téléversement — découper, empreinter, direct vers blob

Vérification de déduplication d'abord — une empreinte connue se termine sans téléverser un seul octet. Les blocs se téléversent en parallèle ; le fichier ne passe à terminé qu'après vérification de l'ETag de chaque bloc.

Chemin 2

Chemin de synchronisation — notifier, puis réconcilier

Le push est la sonnette, le curseur des changements est la vérité : même une notification manquée se répare d'elle-même au prochain sondage.

API et modèle de données

Avant d’optimiser, rendez le contrat inspectable : endpoints, entités, propriété, retries et état.

POST/files/presigned-url

req{ name, size, fingerprint, chunk_fingerprints[] }

rés200 { file_id, presigned_urls[] } · 200 { deduplicated: true } quand l'empreinte existe déjà

Le client téléverse les blocs directement vers le stockage blob avec ces URL — les octets du fichier ne passent jamais par les serveurs API.

PATCH/files/{file_id}/chunks

req{ chunk_id, etag }

rés200 statut du chunk

Faire confiance mais vérifier : le serveur accepte le rapport d'avancement du client, puis confirme l'ETag auprès du stockage blob avant de compter le bloc comme téléversé.

GET/files/{file_id}/presigned-url

rés200 { url } (signée par CDN, expiration courte)

Les téléchargements viennent du edge CDN ; des URL signées à courte durée empêchent les liens de partage de devenir des URL publiques permanentes.

GET/files/changes?since={cursor}

rés200 [{ file_id, change, version }]

L'épine dorsale de la synchronisation : le push signale « quelque chose a changé » ; ce point d'accès est la vérité contre laquelle un appareil se réconcilie.

Entités principales

FileMetadata

file_id (PK) · name · size · fingerprint (SHA-256) · latest_version · status · chunks[] {id, fingerprint, status}

file_id (identité) est délibérément séparé de fingerprint (contenu) — un renommage ne change ni le contenu ni les blocs stockés.

SharedFiles

user_id (partition key) · file_id (sort key)

Question

Un utilisateur change quelques octets au milieu d’un fichier de 50 GB. Re-téléverse-t-on tout — comment ne synchroniser que ce qui a changé ?

Réponse

Chunking défini par le contenu : les frontières viennent des octets eux-mêmes, une petite édition ne change que les chunks touchés et la synchro ne re-téléverse que ceux-là.

À éviter

Le chunking à taille fixe pour les fichiers édités — insérer un octet décale toutes les frontières suivantes, presque chaque chunk paraît nouveau et se re-téléverse.

Prêt à vous entraîner ?

Expliquez système de synchronisation de fichiers à voix haute et obtenez une évaluation IA de votre explication.

S’entraîner avec l’IA →

système de synchronisation de fichiers

Points de contrôle de pratique

Les besoins qui façonnent la conception

Besoins fonctionnels

Besoins non fonctionnels

Continuez à demander — l’entretien est une conversation

Les chiffres qui forcent les décisions d’architecture

Chemin d’architecture

Vue d’ensemble — chaque composant

Chemin de téléversement — découper, empreinter, direct vers blob

Chemin de synchronisation — notifier, puis réconcilier

API et modèle de données

Directions de deep dive

Signaux techniques associés

Sources

Références sectorielles

Patterns

Entraînez-vous sur la série associée

Prêt à vous entraîner ?