Details on DataStoreService for Advanced Developers



Are you sure that set requests do not set the read cache? I believe they do.

local services = {
	data_store = game:GetService("DataStoreService")

--local data_store = services.data_store:GetDataStore("name_0")
--local data_store = services.data_store:GetDataStore("name_1")
local data_store = services.data_store:GetDataStore("name_2")

	local value = data_store:GetAsync("key")
	data_store:SetAsync("key", value == nil and 1 or value + 1)

while true do
	local value = data_store:GetAsync("key")
	game.ReplicatedStorage.RemoteEvent:FireAllClients("Value at: " .. os.time() .. " is " .. tostring(value))

Assuming wait() calls are not taking much longer than the cache time for the thread to be resumed (which they shouldn’t be and aren’t in my testing), this code should always print that the value is the initial value, and never get the incremented value since I am resetting the cache cooldown every ~0.5 seconds. However, in my testing, it does receive the new value.

Perhaps I’m missing something obvious, but it sure seems like GlobalDataStore:SetAsync() does indeed set the read cache for the key.

That aside, great thread! Very helpful. Shame that DataStores are so needlessly complex due to the odd caching mechanism.


All key writes that you do on a particular server will be immediately available on that server. Perhaps I could describe this more clearly, but with “setting the cache” I mean that it sets the cache time (the value is irrelevant in that description). For example, doing an UpdateAsync and then a GetAsync afterwards makes the GetAsync not consume any budget, since UpdateAsync set the cache time. SetAsync does not set the get cache time, so the GetAsync call after that will consume budget, even though the server should know what the most recent value is because of the recent SetAsync.


Ah, the things we learn when we try to reverse engineer and emulate a black-box system. I know what that’s like. Really great work.