Doom tourne sur AWS Lambda Web Functions avec état partagé entre environnements
Sommaire
En bref
- Un développeur a porté le moteur de Doom en WebAssembly et l'héberge sur AWS Lambda Web Functions, une plateforme serverless sans affinité de session.
- L'état du jeu est stocké dans DynamoDB et rejoué en cas de bascule entre environnements d'exécution, avec une latence de 120 ms imperceptible en jeu.
- Chaque frame ne consomme que 0,15 ms de CPU (0,5% d'un vCPU), et les changements seuls sont transmis au navigateur pour limiter la bande passante à environ 500 KB/s.
Ce que dit la source
L'auteur pose une question technique : AWS Lambda Web Functions peut-il gérer un état complexe et long terme sans affinité de session entre requêtes ? Doom, avec son moteur déterministe et ses mises à jour 35 fois par seconde, sert de test en conditions réelles. Le défi central est que chaque client WebSocket reste ouvert plusieurs minutes avec des millions de changements d'état, situation qu'aucune requête stateless classique n'affronte. L'auteur présente cette implémentation comme une démonstration faisable, non comme une recommandation pour produire.
- doomgeneric compilé en WASI via zig cc, chargé dans Node.js 24 comme module WebAssembly natif, sans code C dans la fonction elle-même
- Stockage des entrées (pas de l'état complet : plusieurs Mo à chaque tic) dans une table DynamoDB avec trois artefacts : un bail, un journal d'entrées, une inbox pour les ordres en transit
- Bascule entre environnements en transaction DynamoDB unique, avec rejoue du journal (30 ms par minute de jeu) pour reconstruire l'état exact
- Latence de basculement environ 120 ms, communiquée au joueur et imperceptible en jeu normal
- Streaming binaire brut plutôt que Server-Sent Events, avec delta frames (seuls les pixels changés envoyés), réduisant la bande passante de 890 KB/s à 500 KB/s
- Pas de WebSockets supportés ; le jeu utilise une réponse HTTP longue pour le streaming, chaque appui clavier remontant en POST séparé
- Perte maximale de 2,5 secondes d'entrées en cas de défaillance du propriétaire (délai de heartbeat) avant basculement automatique
- Support des spectateurs : autre client peut regarder le même jeu via son propre flux, contruit en rejoue si sur un environnement différent
Dans les commentaires
Débat absent : zéro commentaire fourni. Le sujet technique est solide (architecture déterministe pour résoudre un problème réel d'absence de session affinity), mais l'absence d'engagement suggère soit un post très récent, soit un intérêt marginal sur HN.
- Aucun débat substantiel exploitable : zéro commentaire fourni au moment de la capture.
Notre lecture
Cas d'école intéressant pour les équipes AWS ou les architectes serverless : montre comment contourner les limitations de session affinity en serverless (pas d'affinité = pas de problème si l'état est rejoué depuis un log deterministe). La rejouabilité via entrées est une technique applicable bien au-delà de Doom (jeux collaboratifs temps réel, simulation cloud). Aucune implication business directe pour une DSI, mais à consulter si vous évaluez AWS Lambda Web Functions pour des workloads interactifs stateful. Le bémol : la complexité de DynamoDB + heartbeat + rejoue est manageable ici, mais ne généralise pas forcément à tout état complexe. Probablement du bruit pour la plupart, pertinent pour architectes spécialistes.