AEM replication strategies: agent chains and cross-data center sync
AEM replication is the asynchronous movement of content between repository instances, usually from an authoring environment to publishing environments. In a traditional AEM 6.x deployment, a replication agent packages changed content, places it on an outbound queue, and delivers it over a protected connection. The source commit can therefore succeed while a remote publish is still waiting, retrying, or blocked by invalid configuration.
For Australian organisations, the design becomes more than a technical choice because Sydney and Melbourne carry much of the market’s digital traffic, while Perth offices can sit on a materially different network path. A distributed publishing plan should account for latency, regulatory obligations, and the way distributed teams hand over work: an east-coast “arvo” check may be the first sign that a Perth replica has fallen behind.
Map the replication flow
Start with the role each endpoint plays. An author-to-publish agent sends authored content to a publish instance; a publish-to-publish agent distributes already-published content to another data centre; and a dispatcher flush agent invalidates selected cache entries. These are distinct jobs, even when AEM presents them in the same administration area.
An agent chain is an ordered set of agents executed serially. A common authoring chain publishes a package and then triggers cache invalidation, while a cross-centre chain can distribute the published package and coordinate invalidation at the remote dispatcher. The sequence provides organisation, not a transaction: a successful first step does not compensate for a failed second step, so each link needs its own queue, retry policy and alert.
Replication also has boundaries. It moves selected repository paths and properties, not every change in the underlying database. Users, groups, ACL changes and deployment-specific configuration require separate treatment. Where AEM feeds a Drupal or other open-source platform, test the handoff for missing packages and duplicate processing; a Drupal community gathering can offer a useful adjacent perspective on interoperability and community-led testing.
Design agent chains deliberately
Build chains around content classes and service boundaries, not one universal sequence. Keep standard page publication separate from large asset transfers, and give time-sensitive campaigns a path that avoids low-priority bulk work. When a remote publish is involved, confirm that the destination dispatcher is invalidated rather than assuming a source-side flush reaches a cache in another data centre.
Treat credentials and key material as part of the topology. The author publish key guide explains why author-side and publish-side configuration must be understood separately; use distinct service accounts, least-privilege repository access and managed certificate rotation for each trust path. A copied configuration that happens to work in a test may fail during failover if both regions trust the same identity or key.
Personalisation adds another boundary. Live Salesforce responses should not be replicated as though they were authored pages. Replicate stable content and configuration, evaluate personalisation at request time, and apply filters that prevent transient or customer-specific payloads from entering cross-centre queues. This keeps personalisation logic available in both regions without distributing sensitive runtime data unnecessarily.
Synchronise across Australian data centres
Choose the direction of authority before choosing agents. In a one-way model, one data centre is the source of truth and publish-to-publish agents distribute its output; this is easier to audit and gives operators a clear recovery path. In a bidirectional or active-active model, teams can publish in either location, but AEM is not a conflict-free synchronised database, so concurrent edits require defined ownership, version checks and a manual merge process.
The physical geography sharpens those trade-offs. Sydney and Melbourne are the main hubs for many Australian enterprise, retail and government workloads, whereas Perth can experience a slower path to east-coast infrastructure. Local cloud investment commonly improves the eastern footprint but does not remove every cross-region delay. For regulated organisations, replication may also move personal information outside Australia, making Privacy Act 1988 obligations, the Australian Privacy Principles and contractual controls part of the architecture review rather than a later compliance check.
Bidirectional publish-to-publish agents need explicit loop prevention. Incoming content can otherwise be observed and sent onward, while simultaneous changes can overwrite one another without a domain-aware conflict model. Define which region owns shared paths, use filters or metadata that identify replication origins, prohibit uncontrolled fan-out, and test a partial network failure before launch. The ICF Olson speaker profile is a useful starting point for examining AEM architecture through the responsibilities of architects, developers and operations teams.
Control queues, keys and failure modes
Replication is only healthy when content arrives, remains fresh and leaves the intended cache. Monitor queue depth, retry counts, delivery latency, failed packages and the time between a source revision and its appearance at each destination. Record expected freshness by content type: a campaign page may tolerate minutes, while a regulatory notice or transaction-related template may need a much tighter service level.
Treat every cross-centre endpoint as a privileged service. Use TLS, allow-listing where practical, rotated credentials, and separate monitoring from administration access. Security teams can borrow the threat-modelling agenda from a security conference programme and apply it to spoofed agents, credential theft, replay and traffic surges. Runbooks should identify who can pause a queue, reroute content and validate a recovered instance.
Two concise checklists separate design intent from live checks:
Design controls
- Give each region one named owner for shared content.
- Map every agent, queue, endpoint and cache flush path.
- Define filters and origin rules that prevent re-replication.
- Store credentials and keys separately for each trust path.
Operational controls
- Alert on queue growth, repeated retries and oversized packages.
- Compare source and destination revisions during scheduled checks.
- Confirm dispatcher invalidation after remote publication.
- Rehearse a broken link and a complete regional failover.
Choose, test and operate the topology
The right choice balances control, consistency and operational effort. For AEM as a Cloud Service, confirm which replication actions are service-managed before copying an on-premises agent design; Adobe manages content distribution and publish infrastructure, so custom chains should not be assumed. For self-managed AEM, teams have more control but also own certificate trust, queue monitoring, capacity and failure recovery.
These options trade simplicity for direct control:
| Topology | Suitable operating model | Main advantage | Main constraint |
|---|---|---|---|
| Single-region author and publish | One authoring hub with local publishing | Simple support model and short local paths | A regional outage affects the whole service |
| One-way cross-centre sync | Nominated source publishes to remote sites | Clear authority and repeatable delivery | Changes depend on the source region’s availability |
| Bidirectional publish sync | Each region can publish shared content | Local teams can release without a remote dependency | Conflicts, loops and governance need active control |
| Managed multi-region delivery | Cloud service distributes content across regions | Less infrastructure ownership | Fewer custom agent controls |
Measure the design with failed-agent, lost-link and failed-dispatcher scenarios. Capture publication latency, cache convergence, queue recovery time and the exact steps required to restore a healthy source of truth. A request-time dependency also needs testing: the CIRCUIT Salesforce integration session shows why a personalised result must not be mistaken for replicated source content.
Use the CIRCUIT session archive to align Java developers, front-end specialists, architects and systems engineers before the next release. Choose one topology, document every hop and schedule the first controlled failure test before production traffic depends on it.