Skip to main content
daniel-strmecki
Adobe Champion, Community Advisor, UG Leader
Adobe Champion, Community Advisor, UG Leader
October 11, 2026

AEM Universal Editor: Solving Stale Previews with Pod Affinity

  • October 11, 2026
  • 0 replies
  • 6 views

 

AEM Universal Editor: Solving Stale Previews with Pod Affinity

by @daniel-strmecki

 

Introduction

 

Adobe Experience Manager (AEM) Universal Editor enables enterprises to combine visual content authoring with modern, decoupled frontend applications built using frameworks such as Next.js. However, separating content editing from frontend rendering introduces new architectural challenges, particularly when authors expect their changes to appear immediately in the preview.

In one of our recent implementations using AEM as a Cloud Service (AEMaaCS), Universal Editor, and Next.js, we encountered an intermittent issue: content changes were successfully saved in AEM, but the preview occasionally continued displaying outdated content.

Initially, this appeared to be a frontend caching problem. However, our investigation revealed a different root cause. Universal Editor and Next.js were communicating with different AEM Author pods, and updated content was not immediately visible across all pods.

In this article, we explain how AEM pod affinity works, why this issue occurs in decoupled architectures, and how we improved preview consistency by propagating the AEM affinity cookie to our Next.js application.

 

Key Points

 

When Saving Content Doesn't Update the Preview

Universal Editor successfully saves content changes in AEM, but the decoupled frontend may continue displaying outdated values. The issue is intermittent, making it particularly difficult to troubleshoot and frustrating for content authors.

 

Why Frontend Caching Is Not Always the Problem

When a Next.js preview displays outdated content, caching is an obvious suspect. However, disabling frontend caching does not help if the underlying AEM API returns outdated data. In our case, the problem was related to request routing and content consistency between AEM Author pods.

 

Understanding Content Consistency Across AEM Author Pods

AEMaaCS operates on distributed infrastructure with multiple Author pods. Content changes are not necessarily visible across all pods immediately. In our implementation, we observed a short delay, typically around 1–2 seconds, during which different pods could return different content versions.

 

Why Decoupled Frontends Make This More Visible

Universal Editor saves content through AEM Author, while Next.js independently retrieves content through server-side API requests. If the save reaches Pod A but the subsequent preview request reaches Pod B before the content update becomes visible there, the frontend renders outdated content.

 

Understanding AEM Pod Affinity

AEM uses an affinity cookie to help route subsequent requests from the same client to the same application pod. However, a decoupled Next.js application acts as a separate HTTP client, meaning its server-side requests do not automatically inherit the author's affinity cookie.

 

Forwarding the AEM Affinity Cookie

Instead of introducing artificial delays or retrying content requests, we decided to propagate the AEM affinity cookie to Next.js. This allows the frontend to forward the same affinity value when making server-side API requests to AEM Author, improving the consistency of the editing preview.

 

Integrating Affinity into the Universal Editor URL

We implemented a custom Sling Servlet Filter that intercepts the standard AEM page-opening endpoint (/bin/wcmcommand) when cmd=open. The filter retrieves the affinity cookie and includes its value in the Universal Editor preview URL, making it available to the decoupled frontend.

 

Security and Operational Considerations

Passing an affinity cookie through URL parameters requires careful handling because URLs may appear in logs, browser history, and monitoring tools. This workaround should be restricted to protected authoring environments, with appropriate safeguards. Pod affinity is also a routing preference rather than a guarantee, so applications must handle missing or invalid affinity assignments.

 

Improving Preview Consistency Without Artificial Delays

By propagating the affinity cookie from AEM to Next.js and forwarding it with subsequent API requests, we significantly improved preview consistency without introducing additional waiting time or repeated requests.

 

The Broader Lesson for Decoupled AEM Architectures

Building reliable headless experiences involves more than connecting a frontend framework to AEM APIs. Content consistency, request routing, authentication, caching, and rendering all influence the authoring experience. Understanding these dependencies is essential when implementing Universal Editor with an independently hosted frontend.

 

Full Article

Read the full article on https://meticulous.digital/blog/f/universal-editor-preview-not-updating-fixing-aem-pod-affinity to find out more. 

 

Q&A

Please use this thread to ask questions relating to this article