GeoServer Active/Active: separate serving from authoring

A GeoServer installation has more than geospatial data. Its catalog, service settings and styles tell the server how to expose that data. Adding query-serving instances creates a second coordination problem: carrying configuration changes to those instances.

The extension addressed internal configuration propagation. It did not make shapefiles, raster files or databases replicate through JMS. That boundary matters because a replica with the right catalog can still point at missing or different spatial data.

GeoServer instances use Java, Spring and JMS messaging through ActiveMQ. An authoring instance persists configuration and publishes changes; subscribing instances apply received configuration to their in-memory catalog and persist it locally. Multiple instances can serve OGC queries concurrently.

The topology drawn here is a documented design with private data directories and a designated configuration writer. It is an original reconstruction of the published architecture, not a deployment inventory. A broker can be standalone or embedded; the training also describes broker networks.

Durable subscriptions support delivery of changes missed while a registered replica is offline. They concern the configuration message channel. Spatial sources and accompanying files still need their own sharing or synchronization arrangements.

Active/Active query service does not imply safe concurrent catalog editing. The documentation warns about concurrent writes to shared directories and recommends directing frequent configuration changes through one authoring node with failover. A pure replica should not receive REST or UI configuration edits.

Private directories avoid treating a shared filesystem as a concurrent configuration database, but place catch-up responsibility on messaging and replica persistence. A shared-directory topology has different operational constraints, including separate instance configuration locations.

A retrospective alternative is a declarative configuration rollout: distribute a versioned artifact and reload serving instances through a controlled procedure. That can improve auditability but trades immediate fine-grained propagation for rollout coordination. It is an alternative I would evaluate today, not a claim that it was implemented in this work.

I was the sole developer of the original plugin and author of the related articles during 2010–2014. The original work was committed in SVN and later migrated to Git. The current community module includes subsequent maintenance by others; its present contents should not all be attributed to me.

The public documentation remains available and explains configuration propagation and deployment choices. This case claims a delivered extension and documented architecture, without converting that evidence into a throughput, availability or customer-count result.

The most useful design lesson is to name what is consistent: a catalog object, a style, an external graphic and a dataset are different things. A service can remain available for queries while a replica is temporarily behind on publishing configuration.

For a new implementation, I would test a configuration edit while the broker is unavailable, a crash between persistence and publication, a replica reconnecting to a durable subscription, mutable catalog objects across serialization, duplicate/reordered events and safe writer failover. Those are reliability questions raised by this architecture, not invented incidents from its history.