Memcached
En 2003, Brad Fitzpatrick se retrouve face à un casse-tête de taille. LiveJournal, la plateforme de blogs qu'il a créée, explose littéralement : plus de 2,5 millions de comptes et une infrastructure qui commence à montrer ses limites. Quelque 70 machines tournent jour et nuit, mais les bases de données craquent sous la pression des requêtes. Le site affiche une particularité qui complique tout : chaque contenu possède différents niveaux de sécurité et s'insère dans de multiples vues. Impossible de générer des pages statiques quand les éléments qui les composent vivent chacun à leur rythme.
Fitzpatrick observe alors une réalité technique qui va orienter toute sa démarche. Les processeurs gagnent en vitesse, année après année, tandis que les disques durs traînent la patte. Pourquoi ne pas exploiter cette puissance de calcul plutôt que de s'épuiser en accès disques interminables ? L'idée germe d'utiliser la RAM qui sommeille dans les serveurs web, cette mémoire vive qui ne demande qu'à servir.
Un premier prototype voit le jour en Perl. L'essai se révèle décevant : trop lent, trop gourmand en mémoire. Fitzpatrick reprend tout en C et bâtit un démon mono-processus, mono-thread, qui s'appuie sur des entrées-sorties asynchrones. Pour garantir que son système fonctionne partout, il intègre libevent, une bibliothèque qui choisit automatiquement la meilleure stratégie de gestion des descripteurs de fichiers selon l'environnement d'exécution.
Le principe de Memcached tient en quelques mots : transformer la mémoire disponible des serveurs en un vaste réservoir partagé. Une table de hachage distribuée où les données circulent entre les machines grâce à un système de hachage cohérent. Rien de superflu dans l'architecture : le serveur ne bavarde pas avec ses congénères, ne conserve rien sur disque, propose trois opérations basiques – set, get, delete – et c'est tout. Cette austérité voulue procure des performances redoutables, avec des algorithmes en O(1) qui répondent du tac au tac. L'allocateur de mémoire par tranches évite la fragmentation qui pourrissait la vie des premières versions utilisant malloc.
Facebook adopte Memcached en 2007 et développe mcrouter, une variante enrichie de fonctions de sharding. Twitter suit avec twemcache, taillé pour ses besoins propres. Ces géants du web valident l'approche de Fitzpatrick et font de Memcached un standard de fait.
Les chiffres donnent le vertige. Chez Facebook, le système traite des milliards de requêtes par seconde et stocke des milliers de milliards d'objets. Le taux de réussite du cache atteint régulièrement 92 % : seule une poignée de requêtes doit vraiment interroger la base de données. La charge s'allège d'autant. Le système introduit les « leases » pour gérer les conflits d'écriture et éviter que des hordes de clients tentent tous en même temps de régénérer une entrée expirée.
L'architecture distribuée autorise une souplesse bienvenue. On ajoute ou retire des serveurs du pool à la volée, le système s'ajuste sans broncher. Cette capacité de montée en charge horizontale devient vite une pratique courante dans la conception des infrastructures web modernes.
La communauté s'empare du projet. Des bibliothèques clientes fleurissent pour PHP, Python, Ruby, Java, C#, et ajoutent sérialisation d'objets et compression transparente, rendant l'outil plus maniable dans des contextes variés. Le code source continue d'évoluer grâce aux contributions d'une communauté active qui ne faiblit pas.
En 2024, Memcached tient toujours son rang dans les infrastructures web. Le projet conserve sa philosophie initiale : rester simple, rapide, fiable. Cette approche minimaliste tranche avec des alternatives plus baroques comme Redis, mais répond parfaitement aux besoins de mise en cache pure. Memcached démontre qu'une solution élégante et dépouillée résout parfois mieux les problèmes complexes qu'une machinerie sophistiquée.