Keyboard shortcuts

Press ← or → to navigate between chapters

Press S or / to search in the book

Press ? to show this help

Press Esc to hide this help

Quotas, limites & versionnage lim Décidé

L'auth est stateless (le ticket est auto-porteur), seul le backup a une session. Les quotas se comptent exactement par tenant, les dépassements échouent proprement, et les évolutions sont additives — les données survivent au protocole.

L’auth est stateless — seul le backup a une session

En clair — le contrôleur lit le billet sans appeler la billetterie Le ticket journalier est auto-porteur : ses claims (tenant, machine, scopes) sont signés dedans — le serveur le valide sans consulter la moindre base à chaque requête. Il n'y a donc aucune session d'authentification côté serveur. La seule vraie session est la session de backup — parce qu'elle seule a un état réel à tenir (les épinglages). Jolie symétrie : de l'état là où il y en a, nulle part ailleurs.

Décision 1 — Le quota se compte en octets stockés, par tenant

Un détail élégant gagné par construction : la portée de dédup = le tenant → chaque chunk appartient à exactement un tenant. La somme des chunks du tenant est donc un compteur exact, trivial à tenir à l’ingest — pas d’ambiguïté « qui paie le chunk partagé ? » au niveau de l’enforcement (la question tarifaire entre les clients d’un même revendeur reste un sujet de facturation, section G). Sous-quotas par machine possibles (allocation du revendeur, via la config à trois étages).

Décision 2 — Seuils doux, arrêt net, jamais de casse

En clair — pas de cartons éventrés dans le couloir Avertissements à 80 et 90 % (dashboard + rapport). Au plafond dur : uploads rejetés avec une erreur explicite → le backup échoue proprement (erreur fatale, pas de boucle de retry — la discipline existante). Et la beauté du système de sessions : un backup stoppé par le quota ne laisse aucun débris — pas de racine committée (le snapshot n'existe pas à moitié), et les chunks déjà montés redeviennent collectables à l'expiration de la session. Le déménagement interrompu ne laisse pas de cartons éventrés dans le couloir : ils repartent à la benne, proprement.

Décision 3 — Rate limiting sur trois axes, accroché aux claims

  • Checks d'existence — plafond par machine. Un backup légitime fait peu de requêtes (lots de 1 000) → un plafond bas attrape le client compromis qui sonde l'oracle en masse. Le sujet « prévention d'abus » de la section I reçoit ici son mécanisme.
  • Bande passante serveur — token-bucket par tenant, côté serveur : l'équité entre tenants (un client qui sature n'affame pas les autres). Complète le throttling client — lui protège le réseau du client, ici on protège le serveur.
  • Enrôlement — anti-brute-force sur les codes (déjà courts et à usage unique : ceinture et bretelles).

Réponses standard : 429 + Retry-After — le backoff client existe déjà.

Décision 4 — Une seule session de backup active par machine

Deux backups simultanés de la même machine n’ont aucun sens — le second reçoit un 409. Les restaurations, elles, sont libres. Zéro coût, et ça évite toute interaction étrange entre épinglages et commits concurrents.

Versionnage — additif d’abord

  • Décision 5 — Additif par défaut. CBOR à clés entières + la règle « les champs inconnus sont ignorés » = la quasi-totalité des évolutions sont additives (nouveau champ optionnel avec défaut, nouvel endpoint), sans changer de version. Le /v2/ n'apparaît que pour un vrai changement de sémantique — et coexiste avec /v1/ pendant la fenêtre de migration.
  • Décision 6 — La politique de flotte. Les agents se mettent à jour en vague (rollout progressif) → le serveur parle toujours à des vieux clients. Compatibilité garantie 12 mois glissants ; au-delà, erreur explicite « client trop ancien, mise à jour requise » — que l'auto-update rend rarissime. La négociation fine (tailles de batch, features H3…) passe par l'endpoint de capacités.
Décision 7 — Les données survivent au protocole La version du protocole est indépendante de la version du format des nœuds (l'octet de version CBOR gravé dans chaque nœud). Un snapshot écrit par un client v1 reste lisible pour toujours, quel que soit le protocole du jour. Le protocole est un tuyau qu'on peut remplacer ; les données sont un patrimoine qu'on ne renégocie jamais. C'est le sujet « format sur disque & versionnage » de la section O, vu depuis le réseau.