# In-memory cache

> Cache slow-changing data between C# module endpoints to speed up response times and reduce calls to other services.

You need a fast response time when a client makes a server call. While calling other UGS services in Cloud Code is fast, each request adds latency. For information that doesn't change often, you can introduce a cache to speed up response times. For example, you can cache game configurations stored in [Remote Config](/remote-config.md) or [Cloud Save](/cloud-save.md).

When a C# module runs on a worker, the worker shares memory between module endpoints. You can create an [in-memory cache](https://learn.microsoft.com/en-us/aspnet/core/performance/caching/memory?view=aspnetcore-8.0) (Microsoft) to use between these endpoints. This allows your code to load some information from another service, such as [Remote Config](/remote-config.md), into the in-memory cache and use that cache for the next request. This means your code doesn't have to call out to Remote Config again until the cache expires.

## Limitations

There are some caveats to using an in-memory cache:

* There's no guarantee that the module state persists between calls. The deployment of a module, a cold-start after inactivity, or routine maintenance can cause the module to load onto a different worker.
* Workers can reload for multiple reasons, so don't depend on the data and don't store data that needs to persist long term.
* Requests from the same user might go to different workers, so don't use in-memory caching to cache player data. This includes caching Remote Config with [Game Overrides](/remote-config/game-overrides-and-settings.md), unless the Game Override targets all players.
* A [worker has the limit](../reference/limits) of 128 Mb of memory, so the cache can't hold large amounts of data.