Using Redis for Custom Object Shared Storage in Sitecore

Sitecore XM PaaS uses Redis for its Session State and it’s a common option to use Redis in this instance for Sitecore in other scenarios (ex. XP, XM on IaaS, etc.). However, what if you have custom objects that require shared storage? This is where adding a second Redis instance for your custom objects comes into play.

Why Not Use the Same Redis for Sitecore’s Session State?

You should always preserve Sitecore’s Redis for Session State independent of any custom objects. Session State is meant for quick and lightweight transactions and adding custom objects creates larger entries that Redis has to chew through, slowing down and possibly negating your Session Storage to the point where you are welcoming backups and site crashes.

Per Sitecore:

Avoid storing custom objects in the session. The session mechanism can become a bottleneck if there is a large session size. Use custom caches or shared storages instead. | Known Issues – Excessive load on ASP.NET Session State store

You can, and should, however, tune your Redis Session State to maximize its effectiveness.

Why Use a Shared Storage Redis for Custom Objects?

There is a time and place to store custom objects in shared storage. It could be that you have a commerce solution with custom objects or anything else you want to carry alongside the user’s journey.

Creating a custom Redis for shared storage of key value cached pairs will keep your app stateless for better performance rather than maintaining sticky sessions across nodes because of custom objects.

What Resources Can I Use to Leverage Redis as Custom Object Shared Storage?

Once you have decided to use Redis for shared storage of your custom objects, the next step is to determine how best to implement your solution.

Fortunately, Microsoft has a ton of resources available and Sitecore already uses the preferred StackExchange.Redis.dll for its Redis Session State. With this in mind, you can download the .dll into JeBrains dotPeek (or the dll inspector of your choice) to decompile and view the available methods/implementations.

Beyond Sitecore, you can get more details and step by steps via the following links. In particular, the Microsoft Learn articles take you from Redis instance creation all the way through to code implementation and are a must read for shared storage implementation:

• .NET and Redis
• GitHub – StackExchange/StackExchange.Redis: General purpose redis client
• Create an ASP.NET web app with Azure Cache for Redis – Azure Cache for Redis | Microsoft Learn
• Create an ASP.NET Core web app with Azure Cache for Redis – Azure Cache for Redis | Microsoft Learn

If the cost of a hosted Redis implementation is prohibitive, you can easily install and run a locally hosted development version of Redis. I also like to use Redis Insight to inspect what is written to storage:

• Install Redis on Windows | Docs (assuming you install Ubuntu via WSL per Install WSL | Microsoft Learn)
• Redis Insight

Keep in mind that Redis is best suited for key value pairs, so if you require storing more complex objects such as nested objects you may want to consider MessagePack (MessagePack: It’s like JSON. but fast and small.)

Conclusion

Bottom line, if you plan to store any custom objects… do not under any circumstances use the Redis instance Sitecore is using for Session State. Instead, leverage a separate Redis instance for your shared storage of custom objects. If you have “heavier” or nested objects, really try to avoid using them and refactor or consider a solution like MessagePack.