Understanding sync

By Optimizely Education
Published: Mar 11, 2026
Rating 1 star 2 stars 3 stars 4 stars 5 stars

Average rating: 0 No reviews

Outline

At a glance

Continuous Sync: Real-time event-driven updates ensure high-fidelity content delivery across the Optimizely ecosystem.
Efficiency: Document hashing prevents redundant updates, significantly reducing outbound bandwidth and processing overhead.
Resilience: Scheduled jobs and configurable retry logic maintain index integrity even during transient network failures.
Performance Tuning: Developers can optimize batch sizes and parallelism to balance indexing speed with CMS server performance.

In an Optimizely CMS 13 environment, the synchronization between the authoring hub (CMS) and the delivery hub (Optimizely Graph) is a continuous, managed process. This module details the technical mechanics of the synchronization agent—defining what data is updated, the triggers that initiate those updates, and the architectural rationale behind this "Graph-first" synchronization model.

1. Architectural Rationale

The primary objective of CMS-to-Graph synchronization is to maintain a high-fidelity, globally distributed representation of authored content. By offloading content storage to the Graph, the platform achieves several technical goals:

Near-Zero Latency Delivery: Content is moved from the heavy relational structure of SQL to a high-performance GraphQL index optimized for read operations.
Cross-Product Interoperability: Synchronization ensures that content authored in the CMS is immediately available to other Optimizely One components, such as Optimizely Opal (AI agents) and Content Marketing Platform (CMP).
Resilience: The delivery layer remains independent of the CMS application state. Even if the CMS is undergoing background maintenance, the Graph continues to serve published content.

2. What Updates: The Scope of Indexing

Synchronization is not a simple "copy-paste" of the database. The integration agent transforms CMS entities into JSON-based Global Contracts.

Data Entities Included:

Structured Content: All pages, blocks, and folders registered in the CMS.
Media and Assets: Images and files, including extracted searchable text from documents.
Metadata Layer: Internal routing information, language context, access rights, and standard system properties (e.g., _Metadata, _Modified).
Schema Definitions: During the initial application startup, the system provisions the GraphQL schema itself based on the C# class definitions in the solution.

Document Hashing

To optimize performance, the synchronization agent calculates a document hash for every content item. During a synchronization event, the system compares the local hash with the version in the Graph. If the hashes match, the update is bypassed, significantly reducing outbound bandwidth and processing overhead for large-scale sites.

3. When Updates Occur: The Sync Lifecycle

Updates occur via three distinct mechanisms, each serving a specific role in the content lifecycle.

A. Event-Driven Synchronization (Real-time)

The integration agent hooks into the standard IContentEvents pipeline. Whenever an editor performs a relevant action, a "delta update" is triggered for that specific entity.

Action Triggers: Publish, Move, Delete, Expire, and Undo-Delete.
Expectation: Changes typically reflect in the Graph within seconds of the CMS action.

B. Scheduled Background Job (Delta/Full)

The "Content Graph Synchronization" scheduled job serves as a safety net. It identifies any content items that may have failed event-driven synchronization due to transient network issues.

Configuration: Developers can trigger a manual "Full Sync" via the CMS Admin interface to completely rebuild the Graph index from the CMS source.

C. Startup Provisioning

Upon application initialization, the system performs a structural check. If the Global Contracts or schemas are missing from the Graph instance, the integration agent automatically provisions them before allowing content to flow.

4. Tuning Synchronization Performance

For high-volume enterprise environments, default synchronization settings may require adjustment to balance indexing speed with CMS server performance. Developers can tune these parameters within the AddContentGraph configuration.

services.AddContentGraph(options => {
    // Defines the delay before batching multiple events (milliseconds)
    options.BufferedIndexingGracePeriod = 30000; 

    // Limits the number of items per sync request
    options.MaxBatchSize = 100; 

    // Controls the threading for parallel indexing
    options.MaxDegreeOfParallelism = 4; 
});

5. Monitoring and Retry Logic

A robust architecture assumes that network failures will occur. Optimizely Graph implementations include configurable retry logic for synchronization background jobs to ensure environment consistency.

Configuring Retry Behavior:

The intervals at which the application checks for synchronization status and handles failures can be defined globally:

services.ConfigureScheduleJob(
    checkStatusInterval: TimeSpan.FromSeconds(15), 
    checkStatusSleepOnFailure: TimeSpan.FromSeconds(10), 
    waitUntilFinalResult: true 
);

Log Indicators

Developers must monitor the application logs for successful "Handshake" and "Sync" events. A healthy environment will consistently report:

Job Content Graph Synchronization completed successfully.
Content [ID] successfully synchronized to Content Graph.

Conclusion

Understanding the synchronization lifecycle is essential for managing developer expectations regarding content freshness and environment readiness. By utilizing event-driven triggers for real-time updates and scheduled jobs for index integrity, the system ensures that the Optimizely Graph remains a reliable, high-fidelity delivery hub. Technical teams should prioritize the use of hashing and batch tuning to maintain performance, ensuring that the shift to Graph-backed delivery remains transparent to content editors while yielding significant scalability benefits.