The real need arrived sooner than we expected: during the first MES 2 deployments it became clear that some services needed horizontal replicas — which means an in-memory cache per replica turns into a desynchronized zoo. We brought Redis back in two roles:
- a distributed cache for sessions and reference data shared between service replicas
- a distributed lock to prevent races when marking events are processed concurrently
We used StackExchange.Redis both directly and via IDistributedCache from Microsoft.Extensions. The latter is nicer for portability, but less flexible when you need Redis-specific commands.
In all honesty: our particular problems could have been solved in other ways too — we just felt like doing it exactly this way.
Decided to pass: for our tasks it's over-engineering. By our estimates we won't need a distributed cache — an in-memory cache per service does the job. Shelving it until a real need shows up.
Started exploring Redis in the context of distributed caching for the microservices architecture. We evaluated it as a replacement for individual services' in-memory caches — especially relevant when a service runs in multiple replicas and you need cache consistency across instances.