AEM Dispatch Replication and Reverse Replication
Adobe Experience Manager (AEM) uses replication to move content and related assets between environments. In a typical publishing model, authors work on an author instance, while visitors access pages from one or more publish instances. Dispatcher sits in front of those publish servers, providing caching, request filtering, and protection from unnecessary load.
The phrase “dispatch replication” often creates confusion because Dispatcher does not replicate content in the same way as an AEM replication agent. Instead, AEM publishes content to a publish instance, and a dispatcher flush agent sends cache invalidation requests so that stale files are removed or marked for refresh. Reverse replication follows a different direction and serves a narrower set of use cases.
Understanding the distinction helps teams design reliable authoring workflows, troubleshoot stale pages, and avoid using reverse replication as a substitute for a properly planned content architecture. The same principles apply when AEM is connected to third-party services, mobile channels, analytics platforms, or custom Java applications.
How standard replication works
Forward replication moves activated content from an author environment to a publish environment. An author selects a page, asset, experience fragment, or related resource and activates it. A replication agent then packages the change and sends it to the target publish instance through an authenticated HTTP connection.
The process can include more than the page itself. References, tags, digital assets, permissions, and dependencies may also require deployment, depending on the activation action and project configuration. Replication queues provide visibility into pending, failed, or blocked jobs, making them one of the first places to inspect when published content does not match author content.
Replication agents can be configured for specific targets and purposes. A standard publish agent delivers content, while a flush agent communicates with Dispatcher. Some installations use separate agents for different publish farms, geographic regions, or delivery tiers. Keeping those responsibilities clear makes operational behavior easier to predict.
Where Dispatcher fits
Dispatcher is primarily a caching and security layer, not a content repository. When a page is requested, Dispatcher may serve a cached response without contacting AEM. After content is activated, that cached response can remain available until a flush request invalidates it or the cache expires according to policy.
A dispatcher flush agent sends an invalidation request to the Dispatcher endpoint. The request may remove a specific path, invalidate a directory, or trigger broader invalidation depending on the configured rules. Modern setups often use statfiles and farm-level filters to determine whether a cached file is considered fresh.
A successful activation does not always guarantee a successful cache flush. The publish replication queue and the dispatcher flush queue are separate operational concerns. A page may arrive on publish correctly while an authentication issue, firewall rule, incorrect endpoint, or restrictive filter prevents the cached version from being cleared.
Reverse replication in AEM
Reverse replication transfers selected data from a publish instance back to an author instance. It was designed for scenarios where visitors or users create information on the publish side, such as form submissions, community content, or user-generated data. The information is collected through an outbox mechanism and processed by a reverse replication agent.
This direction is fundamentally different from ordinary author-to-publish delivery. Publish environments should generally remain controlled and minimally privileged, while author environments are trusted workspaces. Enabling broad reverse replication can increase security exposure, create conflicting updates, and complicate governance.
Reverse replication also does not mean that Dispatcher sends cached files back to author. Dispatcher has no role in transporting repository content in reverse. If a business process requires information submitted through a public site to reach an internal system, teams should evaluate reverse replication, direct API integration, message queues, or a dedicated form-processing service.
For integrations that exchange data beyond AEM’s repository, an API integration guide can help frame decisions about authentication, retries, payload validation, and failure handling. Those concerns should be addressed separately from cache invalidation.
Comparing delivery paths
The correct replication design depends on the type of data, its source of truth, and the system that must consume it. A published page usually follows the forward path, while a user submission may require a carefully limited return path or an external integration layer.
| Concern | Forward replication | Dispatcher flush | Reverse replication |
|---|---|---|---|
| Primary direction | Author to publish | AEM to Dispatcher | Publish to author |
| Main purpose | Deliver repository content | Remove stale cached responses | Collect selected publish-side data |
| Typical trigger | Content activation | Activation or invalidation event | User-generated or publish-side content |
| Destination | Publish instance | Dispatcher cache | Author instance |
| Main risk | Queue delays or failed delivery | Stale cache or over-invalidation | Security, conflicts, and uncontrolled data flow |
| Common monitoring point | Replication queue | Flush agent and Dispatcher logs | Outbox and reverse replication queue |
The table also shows why a cache problem should not automatically be treated as a replication problem. If the new content exists on publish but visitors still see an older version, investigate Dispatcher configuration, cache rules, invalidation paths, and upstream caching layers such as a CDN.
Conversely, if a form submission never appears in the author repository, checking only the dispatcher flush log will not help. The relevant evidence may be in the publish application log, the reverse replication outbox, the reverse agent queue, or an external service receiving the submission.
Designing reliable cache invalidation
Dispatcher configuration should be specific enough to protect the cache while still removing affected content promptly. Broad invalidation can create a cache stampede, forcing many requests back to publish at once. Overly narrow invalidation can leave pages, assets, or related navigation elements stale.
Projects should map content dependencies before choosing flush behavior. A change to a product page may affect search results, category listings, personalized fragments, or navigation components. In some cases, invalidating the changed path is sufficient. In others, the application needs targeted invalidation rules or a cache-control strategy that accounts for dependent resources.
Flush requests also need secure endpoints and predictable network access. Use authentication where supported, restrict allowed methods and paths, and avoid exposing administrative Dispatcher operations publicly. Logs should record the request result, target farm, invalidated path, and any HTTP error returned by the Dispatcher endpoint.
Testing should include activation, deactivation, asset replacement, vanity URLs, selectors, query strings, and error responses. Test both a cold cache and a warm cache. A page that looks correct immediately after activation may still be served from a CDN, browser cache, or another intermediary.
Managing reverse replication safely
Reverse replication should begin with a clear data-flow definition. Identify which fields may travel from publish to author, whether the author repository is the system of record, and how duplicate submissions or retries will be handled. Sensitive information should be minimized, encrypted in transit, and protected with strict access controls.
A reverse agent can be affected by queue backlogs, publish outages, repository permissions, malformed payloads, and network failures. Monitoring should expose queue depth, retry counts, last successful delivery, and the age of the oldest pending item. Alerting on failures is more useful than relying on occasional manual checks.
Many modern implementations avoid sending public submissions directly into the author repository. Instead, the publish application sends validated data to a secure backend, CRM, event bus, or serverless endpoint. This can reduce the privilege required by the publish tier and provide better controls for deduplication, retention, moderation, and auditing.
When reverse replication is retained, document the exact paths and node types it handles. Do not enable a broad repository-wide return channel simply because a small form-processing requirement exists. Narrow scope makes incident response, compliance reviews, and future migrations significantly easier.
Supporting mobile and distributed experiences
AEM content can be delivered to responsive websites, native applications, single-page applications, and other channels. Each channel may introduce different caching patterns and activation dependencies. A mobile application might use content fragments or JSON responses, while a responsive site may depend on HTML, client libraries, images, and experience fragments.
The guidance in responsive mobile experiences is especially relevant when deciding which resources must be invalidated together. A mobile-focused endpoint may have a separate cache path and release schedule, so its replication and flush rules should be tested independently from desktop page delivery.
Distributed publish farms add another layer of complexity. A flush request must reach every relevant Dispatcher, and each Dispatcher must point to the correct publish farm. Load balancers, CDNs, health checks, and asynchronous deployment pipelines can make timing differences visible to users.
For high-traffic systems, consider whether invalidation should happen synchronously during activation or through a controlled deployment process. The right choice depends on freshness requirements, traffic volume, and tolerance for temporary inconsistency. Document the expected delay so support teams can distinguish normal propagation from a genuine failure.
Operational checks for production teams
A repeatable diagnostic method prevents teams from changing several components at once. Start by confirming that the content is activated and present on the intended publish instance. Then inspect the standard replication queue, followed by the dispatcher flush queue and the relevant Dispatcher logs.
Useful checks include:
- Confirm the replication agent is enabled, authenticated, and pointed at the correct target.
- Inspect queue status, retry messages, and the timestamp of the last successful delivery.
- Request the page through Dispatcher and compare it with a direct publish request.
- Verify invalidation rules for paths, selectors, extensions, and related assets.
- Review reverse replication scope, outbox health, permissions, and duplicate-handling behavior.
Keep author, publish, Dispatcher, CDN, and integration logs correlated with request identifiers where possible. A single activation can generate several related events, and timestamps alone may be insufficient when queues are asynchronous. Dashboards should show both success rates and latency, since a queue that eventually clears may still violate the site’s freshness objective.
Turning replication into a controlled workflow
AEM replication becomes easier to operate when each path has a defined purpose: forward delivery for approved content, flush invalidation for cached responses, and reverse replication only for narrowly governed publish-side data. Treating these as separate mechanisms clarifies permissions, monitoring, and incident response.
Before changing an agent or Dispatcher farm, trace one representative request from author activation to publish delivery, cache invalidation, and visitor response. For reverse flows, trace a submission from the publish endpoint through validation, queuing, delivery, and author-side processing. Record the expected result at every stage.
Apply these checks to a staging environment, verify queue and cache behavior under failure conditions, and then promote the configuration with monitoring already enabled. A deliberate replication design keeps AEM content fresh without turning Dispatcher or reverse replication into an uncontrolled dependency.