AEM clustering with active-active author and publish

Adobe Experience Manager (AEM) clustering can support high availability, controlled maintenance, and better resilience when an implementation is designed around active-active author and publish environments. The model allows multiple instances to serve users at the same time, rather than keeping one server permanently idle as a standby.

For Australian organisations, this architecture is relevant to large retail, government, education, financial services, and media platforms that must serve visitors across Sydney, Melbourne, Brisbane, Perth, and regional areas. It can also help teams manage traffic spikes during end-of-financial-year campaigns, major sporting events, or public service announcements.

Active-active deployment is not achieved by simply adding more AEM servers behind a load balancer. Repository behaviour, replication, shared storage, session handling, dispatching, indexing, deployment processes, and failure recovery all need to work together. A practical design begins by separating authoring concerns from public delivery and then defining how each tier participates in the cluster.

Understanding the two AEM tiers

The author environment is where content teams create, review, approve, and publish material. In an active-active author setup, two or more author instances can be available to editors through a load balancer. This provides continuity if an instance requires maintenance or becomes unavailable, although it introduces coordination requirements for repository access and author sessions.

The publish tier delivers approved content to visitors. Multiple publish instances are commonly placed behind a dispatcher and load balancer, with each instance serving requests concurrently. This is generally easier to scale horizontally than the author tier because publish instances are usually treated as equivalent delivery nodes.

AEM installations often use separate author and publish farms because their workloads differ. Authors need secure access, workflows, asset processing, and administrative tools, while publish nodes need fast response times, caching, and protection from public traffic. Keeping these responsibilities distinct makes capacity planning and troubleshooting clearer.

Choosing the right repository design

AEM clustering depends heavily on the underlying repository technology and supported topology. Older deployments may use TarMK with cold standby patterns, while newer environments can use MongoMK for a shared document-oriented repository. The correct option depends on the AEM version, Adobe support matrix, expected scale, operational expertise, and recovery objectives.

TarMK is often valued for performance and operational simplicity on a single node, but multi-node active-active authoring requires careful validation. MongoMK can provide a shared repository foundation for clustered author instances, yet it introduces database operations, network dependencies, monitoring needs, and tuning work. Treating the repository as an afterthought is a common cause of instability.

Shared binaries and data stores also need deliberate planning. Large digital assets can create heavy I/O and network demands, especially for organisations managing product photography, video, PDFs, or campaign artwork. Australian teams should account for hosting location, cross-region latency, and data residency expectations when selecting cloud regions or colocation facilities.

Building the author cluster

A load balancer should distribute author traffic only to healthy instances and should support predictable session behaviour. Sticky sessions can reduce disruption for browser-based authoring, but they do not replace repository consistency. Health checks should test meaningful AEM availability rather than merely confirming that a TCP port is open.

Author nodes must share compatible configuration, code, OSGi bundles, indexes, run modes, and service credentials. Content packages should be deployed through a controlled pipeline instead of being installed manually on individual servers. Differences between nodes can create misleading defects where a dialog, workflow step, or servlet works on one instance but fails on another.

Operational access needs to be restricted to corporate networks, VPNs, or a zero-trust access layer. This matters for organisations with distributed teams in Sydney and Melbourne, as well as agencies working across several client environments. Administrative endpoints should never be exposed through the same public path used by site visitors.

Designing publish delivery and caching

The publish cluster normally sits behind a web application firewall, load balancer, and AEM Dispatcher. The dispatcher should cache eligible responses, filter unsafe requests, and route traffic only to available publish instances. Cache rules need to reflect authentication, personalisation, query parameters, response headers, and content invalidation behaviour.

When an editor activates content, replication agents or a supported distribution mechanism must deliver the change to every relevant publish node. A successful response from one target does not prove that all nodes have received the update. Monitoring should therefore track queue depth, delivery failures, replication latency, and content parity across the farm.

Cache invalidation is equally important. A page may be updated on publish while an old response remains in a dispatcher or CDN cache. Flush rules should be tested with nested pages, vanity URLs, content fragments, images, and responsive renditions. For a national retailer, this can prevent a product promotion from showing different prices or availability in different Australian cities.

Handling sessions, workflows, and integrations

AEM authoring includes browser sessions, workflow execution, scheduled jobs, inbox tasks, and background processes. Active-active operation requires teams to identify which services are safe to run on every node and which must be limited to a single leader or assigned instance. Duplicate schedulers can send repeated notifications, process the same asset twice, or create conflicting updates.

External integrations require the same discipline. CRM systems, commerce platforms, search services, analytics tools, identity providers, and marketing automation may use webhooks, queues, or polling. Idempotent APIs and correlation IDs help prevent duplicate transactions when a node retries a request after a timeout.

Session state should preferably be externalised or designed to tolerate node changes. Sticky sessions can improve continuity for short-lived author interactions, but failover still needs testing. Publish applications should avoid storing visitor state locally whenever possible. If personalisation is required, its cache impact and privacy implications must be assessed under Australian privacy obligations.

Monitoring, failover, and recovery

An active-active cluster needs observability at several layers: load balancers, dispatchers, JVMs, repositories, databases, indexes, replication queues, and external dependencies. Useful measures include response time, error rate, heap pressure, repository latency, thread pools, disk usage, cache hit ratio, and queue age. Logs should carry a request or correlation identifier so an incident can be traced across nodes.

Failover tests should be planned rather than left to an emergency. Remove one author node from service, stop a publish instance, interrupt replication, expire a certificate, and simulate a repository dependency failure. Confirm that traffic is redirected, editors receive a usable experience, content remains consistent, and alerts reach the right operations team.

Recovery point and recovery time objectives should be documented in business terms. A government department may prioritise reliable publishing during an emergency, while a media company may focus on fast delivery during a live event. Backups must be restorable, and recovery procedures should cover repository data, configurations, dispatcher rules, certificates, deployment artefacts, and secrets.

Automating deployments across nodes

Infrastructure as code and automated release pipelines reduce configuration drift. The pipeline should promote the same tested artefacts through development, testing, staging, and production, with approvals for sensitive environments. Package versions, dispatcher configurations, index definitions, and environment-specific settings should be visible and traceable.

Rolling deployments can keep a cluster available while individual nodes are upgraded. Before taking a node out of rotation, drain active connections and verify that the remaining capacity is sufficient. After deployment, run smoke tests for login, authoring, activation, page rendering, asset delivery, search, and key integrations before returning the node to service.

Session recordings and technical demonstrations can help teams compare implementation patterns before committing to an architecture. The session video library is a useful reference for reviewing conference material about AEM operations, integrations, and scalable delivery models.

Testing the architecture before launch

Performance testing should represent real traffic rather than a simple page-view average. Include cache misses, asset downloads, search requests, authenticated authoring, activation events, and simultaneous publishing activity. Test from locations that reflect the service footprint, including Australian metropolitan and regional users where latency may differ.

Content consistency testing should compare selected pages, assets, permissions, and metadata across author and publish nodes. It should also verify that activation, deactivation, deletion, and rollback behave consistently. Automated checks are especially valuable after dispatcher changes or AEM service pack updates.

A practical runbook should explain who can remove a node, pause replication, restore a backup, clear a cache, rotate credentials, and escalate an incident. Teams attending technical events or internal workshops can use the event app download to keep schedules and session information accessible while coordinating architecture discussions.

AEM active-active architecture succeeds when availability is treated as a system property rather than a server feature. Validate the repository model, isolate author and publish responsibilities, automate configuration, monitor every dependency, and rehearse failure conditions. With those foundations in place, Australian delivery teams can support reliable digital experiences across national traffic patterns while making maintenance less disruptive.

Use these principles to review your current topology, document its failure modes, and turn the design into a tested operational runbook before production traffic depends on it.