Der Build-Warm-Pool von Vercel hält eine Menge vorgewärmter Container bereit, damit Builds sofort starten können, ohne auf neue Rechenkapazität warten zu müssen. Drei Arten von Zustand wurden in Redis gespeichert: Container-Status, Authentifizierungstoken und Billing-Mappings, die jeden laufenden Build einer abzurechnenden Deployment-Instanz zuordnen. Während Token und Status bei einem Verlust innerhalb von etwa zehn Minuten wiederhergestellt werden können, sind die Billing-Mappings unwiederbringlich – geht ein Mapping verloren, wird der zugehörige Build nie abgerechnet. Da Redis als ephemerer Cache betrieben wurde, war diese Konstellation ein wachsendes Risiko. Vercel entschied sich für DynamoDB als dauerhaften Zielspeicher, primär wegen nativer TTL-Unterstützung, On-Demand-Skalierung für bursty Deployment-Traffic und dem Wegfall von Connection-Management bei hoher Nebenläufigkeit. Das neue Datenschema stellte die Container-ID als Sort-Key in den Mittelpunkt; Token werden nur als Hash gespeichert, sodass ein Tabellen-Read nie eine nutzbare Credential liefert. Für die zwei Access-Patterns, die kein reines Key-Lookup erlaubten – zeitabhängige Statuszählungen und Billing-Lookups –, wurden ein zeitbewusster Index und eine separate kleine Tabelle angelegt. Die Migration selbst lief in fünf Feature-Flag-gesteuerten Phasen unter Vollproduktionslast, ohne dass der Pool je pausiert wurde.