In a previous article I launched some event messaging options, based on .NET sockets. At the end of that, I briefly mentioned that a separate piece of message broker software may be needed in certain situations. Redis is such a kind of message broker software, and this article is about using that.

Using Redis, with its PubSub commands, for event messaging is not an entirely new idea, since I launched the idea back in 2017. So, this is kind of an update to the old provider.

When to use a Redis event provider?

The sockets-based event provider (using either UDP or TCP) is very good for a few static servers in the same network, which never changes address and never scales out and in.

But if you cannot use my multicast event provider and you cannot define a fixed number of unicast endpoints, then the sockets event providers are not for you.

On the other hand, if your site is hosted on an unbounded number of transient hosts (not guaranteed to be there for long) then this Redis event provider might be a good match for you.

Consider these hosting scenarios, where the Redis event provider would be well-suiting:

• The site is hosted on static servers, but a Redis-instance is already running somewhere reachable.
• The site is hosted in Docker, Kubernetes or a similar private cloud.
• The site is hosted in a DMZ network, the edit server is in a separate network and no exceptions can be made for network-crossing event message sockets.

How to use it?

The Redis event provider is very similar to my other event providers. In fact, the source code is hosted in the same repository.

To get started, simply install the StefanOlsen.Optimizely.Events.Redis package (from the Optimizely NuGet feed) in Visual Studio or by running the following command:

dotnet add package StefanOlsen.Optimizely.Events.Redis

Then proceed with configuring the event provider according to the documentation. Of course, this assumes that you already have a running Redis server and a working connection string.

Words of warning

My Redis-based event provider is using Redis PubSub commands. This means that when a server sends a message to the queue, it is immediately sent to all servers that are online and listening.

Message delivery is not guaranteed, as it is when using event providers based on Azure Service Bus or Mass Transit. If a server is down or loses its Redis connection, then it will miss messages. Just like the case of UDP sockets.

The consequences of this should be minimal, though, since event messages are only meant for online servers. But in case your website relies on event messages to maintain some local server state (like a cache folder or a temp folder on each server), then this should be your least concern, to be honest.