Notes produit
Une base qui grandit discrètement
Les utilisateurs arrivent en nombre. C’est une bonne nouvelle, mais combien de temps la base actuelle pourra-t-elle les accueillir ? Authrim prépare le stockage des nouveaux comptes en amont, pour que la croissance ne commence pas par un projet de migration.
Ajouter du stockage avant de déplacer les données
Cloudflare D1, utilisé par Authrim, limite la taille d’une base : 500 Mo avec l’offre gratuite, 10 Go avec l’offre payante. À mesure que les utilisateurs et leurs données augmentent, un autre emplacement devient nécessaire.
Authrim peut répartir les comptes entre plusieurs bases dès le départ, sans devoir déplacer tous les comptes existants. Chaque unité de stockage est appelée un shard, ou partition.
Les comptes existants restent en place ; de nouveaux emplacements accueillent les nouveaux comptes. C’est le principe de l’extension du stockage.
Toutes les données ne grandissent pas au même rythme
Authrim sépare les réglages des tenants — clients OAuth et politiques —, les comptes et données personnelles, et les index permettant de retrouver un compte à partir d’une adresse e-mail.
Une hausse du nombre d’utilisateurs n’exige pas d’agrandir toutes les bases ensemble. Comptes et index ont des volumes et des rythmes différents. La capacité est ajoutée là où elle est nécessaire.
Surveiller les places encore disponibles
Un nouveau compte est affecté à un shard disponible pour son tenant. Les shards sains dont le nombre de comptes est faible par rapport à leur objectif sont privilégiés.
Le critère n’est pas l’occupation du disque, mais le nombre de comptes encore acceptables selon l’objectif configuré. Pour une cible de 100 000 comptes, une marge restante de 20 000 aide à décider quand préparer la suite.
Lorsque la marge devient faible, un shard de réserve est affecté. Le principe vaut pour les shards partagés entre tenants comme pour ceux réservés à un seul tenant.
Tenants en stockage partagé
Tenants en stockage dédié
Stockages partagé et dédié
Ce que l’exploitation quotidienne n’exige plus
Une fois l’approvisionnement automatique configuré, l’opérateur n’a plus à créer une base, préparer ses tables et raccorder un nouvel emplacement à chaque hausse des inscriptions. Chaque ajout de capacité n’exige pas non plus un plan de migration des comptes existants.
L’opérateur vérifie l’avancement, les échecs, l’utilisation et les coûts. Il intervient en cas de permissions manquantes ou de limites du service. Avec cette répartition des tâches, Authrim prépare le stockage suivant.
L’espace libre actuel ne suffit pas
Avec 20 000 places restantes, un service gagnant 100 comptes par jour dispose de beaucoup plus de temps qu’un service en gagnant 10 000 par heure.
Authrim estime donc les besoins à partir du rythme récent des inscriptions et des allocations actuelles, pour les comptes comme pour les index. Une tâche s’exécute chaque minute ; les prévisions des comptes sont aussi actualisées après leur affectation.
Les shards en cours de création comptent dans l’estimation, pour éviter que plusieurs processus constatant le même manque créent chacun une base inutile.
De la création à l’utilisation
Quand les réserves ne suffisent plus, Authrim crée des bases D1 via l’API de gestion Cloudflare. Il prépare les tables, configure l’accès des Workers et distribue les emplacements. La base devient disponible pour l’affectation après validation des lectures et écritures.
L’approvisionnement automatique doit être activé, avec des jetons API distincts pour D1 et Workers. S’il ne peut pas s’exécuter automatiquement, l’opérateur poursuit via l’outil de configuration.
L’avancement est conservé. Une panne temporaire permet de reprendre à partir de cet état. Les problèmes de droits ou de limites de ressources nécessitent une intervention avant la reprise.
Si la préparation prend du retard et que les places sont épuisées, les nouvelles inscriptions peuvent devoir réessayer. L’anticipation vise à réduire cette attente.
L’opérateur décide des déplacements
Ajouter de la capacité et déplacer des données sont deux opérations distinctes. Passer un tenant d’un shard partagé à un shard dédié nécessite aussi de copier ses données existantes.
L’opérateur décide de lancer la migration. Après accord, Authrim assure la synchronisation, la vérification et la bascule.
Le changement actuellement pris en charge va du partagé vers le dédié. Le retour au partagé et le rééquilibrage automatique des comptes existants ne sont pas implémentés.
Supprimer un shard retiré demande également un accord. La croissance ne déclenche pas à elle seule le déplacement ou la suppression des données existantes.
Ce qui a été mesuré
Lors d’un test de juillet 2026 avec 200 000 comptes, Core occupait environ 208 Mo, PII 238 Mo et Lookup 426 Mo. Chacun restait sous 5 % de la limite de 10 Go par base payante. L’utilisation réelle dépend des attributs et index stockés.
L’objectif par défaut est de 100 000 comptes par shard, afin de garder une marge pour préparer le suivant plutôt que de remplir jusqu’à la limite physique.
Authrim est pré-1.0. L’expérience de production prolongée à grande échelle reste à construire. Mesurer le stockage de 200 000 comptes de test n’équivaut pas à exploiter un service utilisé quotidiennement par des millions de personnes.
Moins de migrations à planifier
Un petit service peut commencer avec quelques shards, puis ajouter des emplacements lorsque les inscriptions augmentent. Authrim intègre la préparation et les procédures nécessaires.
Quand les utilisateurs arrivent, préparer un déménagement de base ne devrait pas devenir la première tâche. Réduire ce travail laisse davantage de temps au service lui-même.
Mesure du 30 juillet 2026 sur 200 000 comptes de test. Mo exprimés en unités décimales. Limites D1 : documentation Cloudflare.