Après avoir passé beaucoup de temps dans les centres commerciaux, ce qu'on entend le plus souvent, ce sont les projets qui vantent leurs performances, exhibent leurs coûts ou affichent leurs chiffres de taille. On dirait qu'en poussant ces indicateurs vers le haut, tous les problèmes peuvent être résolus. Mais en réalité, ce ne sont que des façades, la véritable question qui détermine si un système peut survivre à long terme ne se trouve pas là.

Le vrai problème central est en fait d'une simplicité effrayante : dans trois ans, la structure de données que vous utilisez aujourd'hui pourra-t-elle encore supporter la charge ?

Cette question est souvent oubliée de manière sélective par beaucoup. Prenez une application de taille moyenne qui met à jour son état entre quatre et huit fois par jour, chaque mise à jour représentant entre 30 et 60 KB. En calculant, cela donne entre 35 et 70 GB de données historiques accumulées en un an. Le problème, c’est que ces données ne sont pas des données froides rangées dans un coin à prendre la poussière, elles peuvent nécessiter des retours en arrière ou une réutilisation à tout moment. Et la réalité ? Beaucoup de systèmes ne tiennent pas deux ans avant de commencer à lutter avec leurs propres données historiques.

Pourquoi cette peur ? Au fond, c’est à cause de ces pièges : compatibilité cauchemardesque, verrouillage rigide de la structure de données, toute tentative de modification pouvant provoquer un effet domino. La solution adoptée par la majorité des équipes est donc : ajouter une couche de cache, dupliquer les données, appliquer des correctifs. Au final, cela conduit à une prudence accrue des développeurs, à une impossibilité d’innover, et la soi-disant « long-termisme » devient une simple discussion théorique.

Le protocole Walrus adopte une approche différente. Il ne prévoit pas de cacher ou de supprimer l’historique, mais considère plutôt l’historique comme une partie intégrante du système lui-même. Dans cette conception, les objets ne sont pas remplacés ou disparus lors des mises à jour, ils existent en permanence et évoluent avec le système. Ce que vous écrivez n’est pas une donnée ponctuelle, mais plutôt comme l’incubation d’un organisme capable de croître progressivement.

La puissance de cette philosophie de conception réside dans le fait qu’elle ne modifie pas seulement la logique d’exécution technique, mais peut aussi changer fondamentalement l’état d’esprit des développeurs en matière d’innovation.