Continuity of publishing using native Arc XP infrastructure

This guide describes a native Arc XP architecture that provides reader-facing continuity during a regional outage (e.g., AWS US-East), without performing live DNS changes, deploying new code during the incident, or requiring full CMS failover.

The homepage or any selected page content remains served from stale cache, and a dormant client-side block activates only when a Kill Switch (hosted in a secondary Arc XP org’s Outbound Feeds) is enabled. Mobile apps and downstream services can continue to receive published content from the secondary org via View API.

This approach aligns with Arc XP’s documented continuity model:

• Cached pages continue to load
• Client-side JavaScript patches content
• Story pages can be served from a pre-provisioned alternate domain

For the third-party vendor-based continuity approach, see Continuity of publishing in a global outage.

High-level architecture

Component breakdown

A) Dormant continuity block (Org A homepage)

The continuity block ships inside the main PageBuilder bundle. It renders nothing server-side and only executes logic client-side after mount. If any errors occur, it fails closed and does nothing.

Arc XP’s rendering model supports server-side vs client-side separation. See Server-side versus client-side rendering for background.

Design principles

• Must ship inside the main PageBuilder bundle
• Must render nothing server-side
• Must only execute logic client-side (after mount)
• Must fail closed (do nothing if errors occur)

Activation logic

On mount:
  1) Fetch Kill Switch JSON (OBF Org B)
  2) If enabled == false → exit
  3) If enabled == true:
       - Fetch View API collections
       - Patch homepage modules
       - Rewrite story URLs

B) Kill switch hosted in Outbound Feeds (Org B)

The kill switch is a lightweight endpoint hosted in the secondary org’s Outbound Feeds environment. Outbound Feeds provides a dedicated environment, custom output types, and lightweight template rendering — making it suitable for a low-dependency control signal that remains available even when Org A is impaired.

See Getting Started with Outbound Feeds and Custom Block Development & Outbound Feeds.

Kill switch endpoint

https://dr.example.com/arc/outboundfeeds/dr/flag.json

Response

{
  "enabled": true,
  "message": "Continuity mode active",
  "updatedAt": "2026-02-17T09:20:00Z"
}

Requirements

• Must return a small JSON payload
• Must allow browser access
• Should have a short TTL
• Must fail closed in the client if unreachable

Caution

Outbound Feeds content sources often rely on Content API and Site Service. If a broader Arc-wide outage occurs, OBF may also be affected.

• ✔ Suitable for regional org outage
• ⚠ Not ideal for an AWS vendor-wide outage

See Content Sources with Outbound Feeds.

C) Backup content source: View API (Org B)

The dormant block fetches minimal data from Org B using the View API — collections by alias, section feeds, or specific list endpoints.

View API characteristics

• Uses a public X-API-Key
• Rate limits: 50 r/s (single), 30 r/s (list)
• Caching layer serves stale content when possible

See View API.

Example endpoint pattern

GET /collections/by-alias/homepage-hero
GET /collections/by-alias/top-rail
GET /collections/by-alias/breaking-now

Operational model

Normal state

• Editors work only in Org A
• Org B content may optionally be replicated continuously depending on client requirements (see Optional: Cross-org content synchronization below)
• Kill switch is disabled

During an incident

1. Org A region is impaired
2. Org B team enables the kill switch in Outbound Feeds
3. Homepage or selected pages auto-patch for readers
4. Editors publish in Org B

Optional: Cross-organization content synchronization (Org A → Org B)

For clients who require historical content availability in the backup region, a continuous synchronization layer can be introduced between Org A and Org B. This enables Org B to act as a fully functional content mirror rather than a publish-only fallback environment.

When synchronization is needed

• Homepage continuity must include existing content, not only newly published stories
• Editors require full editorial context during failover
• Content parity is required for elections coverage, financial/news-critical platforms, or regulatory RPO expectations
• SEO continuity is important (partial support)

When synchronization is NOT needed

• Only new stories published during the outage are required
• A limited live updates rail is sufficient
• Simplicity and cost are prioritized
• Outage scenarios are expected to be short-lived

In this mode, Org B acts as a publish-only continuity environment and no replication infrastructure is required.

Synchronization architecture

Content is replicated from Org A to Org B using an external service layer.

Org A (Content Creation)
   │
   ▼
Content Event Stream (Kinesis / IFX / Polling)
   │
   ▼
Replication Service (Transformation + Mapping)
   │
   ▼
Org B (Ingestion via Migration Center or Draft API)

What gets synchronized

• Stories (ANS documents)
• Collections (for homepage modules)
• Media references (photos/videos)
• Taxonomy (sections, tags)
• Related content references

Key technical considerations

• ID mapping — Content and media IDs differ across orgs. A mapping layer is required; all references must be rewritten during ingestion. Org A ID → Org B ID
• Media replication — Images and videos must be re-created in Org B. Binary access and permissions must be handled. Missing media can break layouts during failover.
• Content operations gaps — Some operations are not fully covered by event streams and require additional handling: deletes, unpublishes, and scheduled updates.
• Editorial conflict model — Normal state: Org A is the only writable system. Failover: Org B becomes writable. Avoid dual-writing across orgs.
• Non-content configuration is not replicated — Users and permissions, integrations (APIs, webhooks), Identity/subscriptions, paywall configuration, and analytics/ads setup must be configured independently in Org B.
• Reconciliation & drift detection — A periodic reconciliation job is recommended to detect missing or outdated content, reprocess failed events, and ensure parity between orgs.

Trade-offs

Capability	With Sync	Without Sync
Historical content in Org B	✔ Yes	❌ No
Complexity	🔴 High	🟢 Low
Cost	🔴 Higher	🟢 Lower
Operational overhead	🔴 Significant	🟢 Minimal
Use case	Full continuity	Breaking-only

Note

Synchronization should be positioned as an optional enhancement, not a default requirement. Most clients can achieve their continuity goals using View API fallback, kill switch control, and a publish-only Org B. Synchronization should be introduced only when there is a clear business need for content parity.

Limitations and risk analysis

Area	Limitation
SEO	Client-side patches may not be fully visible to crawlers
First-hit caching	If the page or template is not cached, continuity logic won’t execute
JS dependency	If the JS bundle is not cached, logic won’t run
OBF dependency	Kill switch depends on Org B OBF availability
View API limits	Strict rate limits apply (50 r/s single, 30 r/s list)
Identity/Paywall	Cross-domain session complexity unless pre-configured with a third party
Scope	Reader continuity only — not a full CMS failover

For general continuity pattern limitations, see Continuity of publishing in a global outage.

Required pre-configuration

The following must be completed before any incident occurs.

• DR block deployed in homepage bundle
• JS bundle widely cached
• dr.example.com provisioned (DNS + SSL)
• Org B View API provisioned
• Collections aligned between orgs
• Kill switch endpoint tested
• Endpoints pre-warmed in View API

For domain and SSL provisioning, see Arc XP Domain Management and SSL Certification Provisioning.

When this architecture is appropriate

• ✔ Regional outage resilience
• ✔ Election coverage continuity
• ✔ Breaking news continuity
• ✔ Cost-sensitive DR model

Summary

This architecture provides:

• No live DNS changes
• No emergency deployment required
• Homepage continuity via cached HTML
• Selective module override via dormant block
• Controlled activation from Org B
• Lower cost and complexity than full dual-primary DR
• Continued content delivery to apps and downstream services via View API
• Optional cross-org synchronization for historical content parity

This is a controlled degradation model, not a full platform failover.