Session state loss during Blue-Green deployment in ASP.NET Core

Direct Answer

No, ASP.NET Core’s session middleware cannot preserve session data when routing to a new instance without sticky sessions if you are using the default in-memory provider. Because in-memory state is local to the process, the Green environment has no access to the Blue environment's memory. To achieve zero-downtime session persistence without sticky sessions, you must migrate to a distributed cache (such as Redis) and share Data Protection keys between environments.

Technical Explanation

The In-Memory Limitation

The default AddDistributedMemoryCache() is a misnomer in the context of multi-instance deployments; it is a local cache. When the load balancer switches traffic to the Green environment, the user's session cookie points to a session ID that does not exist in the Green instance's memory, forcing the application to create a new, empty session.

Serialization and Version Compatibility

ASP.NET Core session state stores data as byte[]. The middleware itself does not dictate the serializer; the developer chooses how to serialize objects before calling ISession.Set().

• JSON Serialization: Generally compatible across minor versions, provided property names remain consistent and the application handles missing or extra fields gracefully.
• Binary Serialization: High risk of SerializationException if the assembly version or class structure changes between the Blue and Green builds.

The Role of Redis and Data Protection

A Redis store eliminates the need for sticky sessions by decoupling state from the compute instance. However, Redis alone is insufficient. ASP.NET Core uses Data Protection APIs to encrypt and sign the session cookie. If Blue and Green use different local key rings, Green will be unable to decrypt the cookie issued by Blue, treating the user as unauthenticated or session-less regardless of the Redis backend.

Required Implementation Steps

1. Implement Distributed Caching: Replace the memory cache with Redis in Program.cs:

   builder.Services.AddStackExchangeRedisCache(options =>
   {
       options.Configuration = "your-redis-connection-string";
       options.InstanceName = "Session_";
   });
   

2. Persist Data Protection Keys: Configure the application to store keys in a shared location (e.g., Azure Blob Storage, AWS S3, or a network share) so both environments share the same cryptographic keys:

   builder.Services.AddDataProtection()
       .PersistKeysToFileSystem(new DirectoryInfo("\\shared-network-path\\keys"))
       .SetApplicationName("shared-app-name");
   

3. Standardize Serialization: Use a consistent JSON serializer (like System.Text.Json) to convert complex objects to strings/bytes before storing them in the session.

Verification Command

To verify the Redis connection is active and receiving data during a cutover, you can use the Redis CLI to monitor keys in real-time:

redis-cli monitor

Missing Diagnostic Detail: Are you using a shared identity provider (like OpenID Connect) or relying solely on the ASP.NET Core Session cookie for authentication state? If using a shared provider, the Data Protection requirement may differ.