AEM and Redis Session Persistence Across Publish Instances
Adobe Experience Manager (AEM) publish environments are designed to serve content quickly and reliably, yet authenticated experiences introduce a familiar operational problem. A visitor may begin a session on one publish node and then reach another node a moment later. If the session exists only in the first JVM, the second request can lose its login state, shopping basket, form progress, or personalisation context.
Redis provides a practical external session store for this situation. Instead of keeping session data inside an individual AEM publish instance, the application can write it to a shared, low-latency data service that every node can reach. This approach is particularly useful when a dispatcher or load balancer distributes traffic across several publish servers.
The design needs to fit the AEM version, deployment model, authentication method, and Adobe support boundaries. A custom session adapter may be required, and the implementation must account for serialization, expiry, failover, network security, and rolling deployments. Redis is a useful building block, not an automatic replacement for every AEM session mechanism.
The subject was highly relevant to the kind of Java and AEM engineering discussed at CIRCUIT in Chicago. Teams maintaining a content platform for users in Sydney, Melbourne, Brisbane, or Perth will recognise the same concern: a small session failure can become a visible customer issue, especially when traffic crosses regions or a campaign creates a sudden peak.
Why Publish Sessions Become Distributed
A typical AEM architecture places one or more publish instances behind a dispatcher and load balancer. Sticky sessions can keep a browser attached to the same node, but affinity is a routing convenience rather than durable persistence. Nodes can be restarted, removed during deployment, or bypassed when health checks change.
A visitor might authenticate through publish-a, receive a session cookie, and then send the next request to publish-b. If publish-b cannot locate the associated server-side state, the user may appear anonymous or be asked to repeat an action. The symptoms can include intermittent logouts, inconsistent checkout steps, incomplete forms, and difficult-to-reproduce support tickets.
Externalising the session gives each publish node access to a common source of short-lived state. Redis is well suited to this pattern because it offers in-memory reads and writes, key expiry, replication options, and mature Java clients. It should still be used selectively: large objects, permanent content, and business records belong in appropriate persistent systems rather than in a session cache.
Where Redis Fits In An AEM Stack
Redis sits beside the publish tier rather than inside the content repository. A request reaches the dispatcher and an AEM publish instance, where the application reads or updates session attributes through a configured integration layer. That layer maps the session identifier to a Redis key, serialises the attributes, and applies a time-to-live.
AEM does not mean that every deployment has a ready-made Redis switch. Depending on the product release and hosting arrangement, engineers may need an OSGi service, a servlet filter, a supported HTTP session integration, or an application component that manages state explicitly. Before implementation, check the exact AEM documentation and Adobe support position for the target version.
For teams comparing approaches, the CIRCUIT archive offers useful context on the event’s focus on AEM architecture, integrations, Java development, and systems engineering. Those themes matter here because session persistence sits between application code, infrastructure, and operational governance.
Designing The Session Data Model
A Redis-backed session should contain only what the application needs for the next request. User identity references, CSRF values, cart identifiers, temporary preferences, and workflow progress may be appropriate. Full profile objects, large search results, uploaded documents, and repository content generally create unnecessary memory pressure and complicate invalidation.
Serialisation requires special care. Java native serialisation can create security and compatibility concerns, especially when classes change during a deployment. JSON or a carefully defined binary format is often easier to inspect and version, provided that sensitive values are protected and type handling is predictable.
Use namespaced keys such as an environment, application, and session identifier. Set an explicit TTL so abandoned sessions disappear without manual cleanup. Session renewal should refresh the expiry when policy allows, while logout must delete or invalidate the Redis record rather than merely removing a browser cookie.
Availability, Consistency, And Failure Behaviour
A single Redis process is a single point of failure. Production designs commonly use managed Redis, replication with automated failover, Sentinel, or a cluster arrangement, depending on data size and availability requirements. The choice should reflect the session workload rather than treating Redis as a general-purpose database.
The application also needs a defined response when Redis is unavailable. Failing every request may protect consistency but create a broad outage. Falling back to local memory may keep pages loading while producing confusing authentication behaviour when traffic moves between nodes. For many sites, a short, controlled failure path with clear logging is safer than silently creating divergent sessions.
Time-outs should be bounded and observable. A Redis client that waits too long can consume AEM request threads and make a cache problem look like a publish outage. Configure connection pools, command time-outs, retry limits, and circuit-breaking behaviour, then test them under realistic load.
Security And Australian Hosting Considerations
Session identifiers must be protected with secure, HTTP-only cookies and an appropriate SameSite policy. Redis traffic should use TLS where available, and access should be restricted through private networking, firewall rules, authentication, and least-privilege credentials. Never expose an unauthenticated Redis endpoint to the public internet.
Australian organisations also need to consider the Privacy Act, contractual data-handling duties, and internal requirements for data residency. A platform serving customers in Melbourne may use an AWS or other cloud region in Sydney, but the decision should be documented rather than assumed. Session values can contain personal information, so retention, access logging, encryption, and deletion policies still apply.
Latency is another local consideration. A Brisbane publish tier writing to a distant Redis service can add delay to every authenticated request, while a Perth deployment may need particular attention to inter-region network performance. A regional Redis service close to the publish nodes generally produces a more predictable result than a central store selected purely for convenience.
Testing Across Publish Nodes
A useful test begins with a browser login against publish-a and then deliberately routes subsequent requests to publish-b and publish-c. Confirm that authentication, cart state, consent records, and form progress remain available. Repeat the test while restarting a node, clearing a dispatcher connection, and performing a rolling deployment.
Load testing should measure Redis commands, session payload size, connection counts, latency percentiles, and eviction activity. A realistic Australian retail campaign may produce sharp peaks around a national promotion, a public holiday, or a major sporting event. A design that works in a quiet staging environment may fail when thousands of users renew sessions at once.
Observability should connect AEM request identifiers with Redis operation timing without recording secrets or raw personal data. Alert on connection failures, rising command latency, unusual key growth, rejected writes, and failover events. These signals help distinguish an AEM code regression from an infrastructure fault.
Connecting AEM Services With Java Components
Many AEM projects combine Sling components, OSGi services, external APIs, and separate Java applications. A Redis session arrangement should define which layer owns each piece of state. If a Spring Boot service participates in login or checkout, it must agree with AEM on identity, cookie scope, expiry, logout, and failure handling rather than independently inventing a second session.
The Spring Boot integration guide is relevant when a publish tier communicates with a microservice backend. The integration boundary should pass a minimal, verifiable identity or session reference, with authorisation checked by the receiving service. Sharing an opaque Redis key across systems without ownership rules can create security and lifecycle problems.
Avoid coupling business-critical transactions to an uncommitted session write. For example, a completed order should be recorded in a durable transactional system before the session is cleared. Redis can remember the temporary journey, but it should not be the authoritative ledger for payments, stock, customer entitlements, or compliance records.
Practical Decisions For A Production Rollout
A staged rollout makes it easier to isolate application, network, and cache issues. Start with a non-production publish farm, use synthetic accounts, and verify behaviour through the dispatcher. Then run a limited production release with dashboards and a documented rollback that does not strand active users.
Keep the implementation small and explicit. A session adapter should handle read, write, touch, invalidate, expiry, and error reporting without hiding business logic inside infrastructure code. Document the Redis topology, key format, ownership, retention period, backup expectations, and emergency access procedure.
Useful decisions to record before approval include:
- Which AEM and dispatcher versions support the selected session integration
- Which attributes are stored, their maximum size, and their sensitivity
- How Redis failover, TLS, credentials, and network access are managed
- What users experience when the session store is temporarily unavailable
- Which dashboards, alerts, and runbooks the operations team will maintain
The event app is a reminder of the practical side of technical conferences: useful architecture depends on details that developers, operators, and stakeholders can share. The same principle applies to an AEM and Redis design. Clear ownership and tested procedures matter as much as the choice of data store.
AEM and Redis for session persistence in publish instances can provide reliable cross-node continuity when it is implemented as part of a complete platform design. Validate Adobe compatibility, keep session data lean, place Redis near the publish tier, protect every connection, and test node failure as deliberately as normal traffic. Teams can then move from sticky-session dependence to a more resilient publish architecture with measurable behaviour and a clear operational response.