Skip to content
Granit
Blog

ADR-002: Redis via StackExchange.Redis — Distributed Cache

Date: 2026-02-21 Authors: Jean-Francois Meyers Scope: granit-dotnet (Granit.Caching, Granit.Caching.StackExchangeRedis) — FusionCache uses Redis as L2 backend and backplane

Context

Section titled “Context”

The Granit framework provides cache abstractions (Granit.Caching) and requires a distributed cache backend for:

  • Performance: reducing latency for frequent reads (settings, translations, templates, permissions)
  • Scalability: shared cache across Kubernetes instances (sticky sessions impossible in an ISO 27001 context — high availability required)
  • Idempotency: HTTP idempotency key storage
  • SignalR: Redis backplane for real-time notifications

The choice of cache backend determines the implementation of Granit.Caching.StackExchangeRedis and the L1+L2 pattern in Granit.Caching (FusionCache).

Decision

Section titled “Decision”

Redis via StackExchange.Redis as the distributed cache backend (L2), combined with FusionCache for the L1+L2 pattern (see ADR-018).

Alternatives considered

Section titled “Alternatives considered”

Option 1: Redis via StackExchange.Redis (selected)

Section titled “Option 1: Redis via StackExchange.Redis (selected)”
  • License: MIT (StackExchange.Redis)
  • Advantage: de facto standard, native IDistributedCache integration, FusionCache L2 + backplane support, Pub/Sub for invalidation, SignalR backplane

Option 2: Memcached

Section titled “Option 2: Memcached”
  • Advantage: simple, lightweight, performant for pure key-value
  • Disadvantage: no Pub/Sub, no advanced data structures, no persistence, no SignalR backplane

Option 3: NCache

Section titled “Option 3: NCache”
  • Advantage: .NET native solution, advanced topologies
  • Disadvantage: commercial license, limited community, no standard HybridCache integration

Option 4: Microsoft Garnet

Section titled “Option 4: Microsoft Garnet”
  • Advantage: Redis protocol compatible, superior performance
  • Disadvantage: recent project (2024), no managed service, stability risk for ISO 27001 production use

Justification

Section titled “Justification”
CriterionSE.RedisMemcachedNCacheGarnet
Client licenseMITApache-2.0FreemiumMIT
IDistributedCacheNative MSThird-partyThird-partyCompatible
FusionCache L2YesNoNoCompatible
Pub/SubYesNoYesYes
SignalR backplaneYes (MS official)NoNoUntested
Maturity10+ yearsMatureMatureRecent

Consequences

Section titled “Consequences”

Positive

Section titled “Positive”
  • Native integration with Microsoft DI (IDistributedCache, FusionCache)
  • MIT client, stable and very widely adopted
  • Pub/Sub for FusionCache backplane and SignalR backplane
  • Transparent L1+L2 FusionCache pipeline via Granit.Caching

Negative

Section titled “Negative”
  • Redis is an additional infrastructure dependency to operate
  • Redis 7.4+ license (SSPL): to monitor if self-hosted
  • Complex object serialization requires a consistent strategy

Re-evaluation conditions

Section titled “Re-evaluation conditions”

This decision should be re-evaluated if:

  • Microsoft Garnet reaches production maturity and offers a managed service
  • The Redis license (SSPL) becomes problematic for self-hosted deployment
  • Cache needs evolve toward a pattern incompatible with Redis (e.g. geographically distributed cache)

References

Section titled “References”