Route vs Replicate

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

Average rating: 0 No reviews

Outline

At a glance

Architectural Choice: Routing provides real-time resolution; Replication synchronizes data into the CMS database.
Database Health: Routing prevents tblContent bloat for massive external catalogs like PIM data.
Editor Workflow: Replication supports native IContent features like drag-and-drop and standard search.
Resilience: Circuit breakers and layered caching are mandatory to decouple CMS performance from external API latency.

In modern digital experience platforms, content is rarely a monolith stored in a single database. For Optimizely CMS 13, integration architects must frequently incorporate data from external systems—Product Information Management (PIM) platforms, third-party news aggregators, or proprietary legacy databases—without sacrificing system performance or the intuitive editing experience.

The architectural approach typically follows one of two distinct patterns: Partial Routing (Dynamic Resolution) or Replication (Data Synchronization). Selecting the appropriate methodology avoids database bloat, poor SEO performance, and fragmented editor workspaces. The following analysis explores the technical nuances of both patterns to ensure a scalable implementation.

1. Decision Framework for Content Federation

Determining the integration strategy requires an assessment of the nature and behavior of the external data. The following criteria serve as a primary framework for the architectural selection:

1. Content Velocity and Real-Time Requirements

External data that changes frequently, such as live inventory levels or dynamic pricing, favors the use of Partial Routing. This pattern allows the CMS to act as a real-time window into the system of record.

Functional Mechanics: Every request to a dynamic URL triggers a call to the registered router, which executes a request to the source API.
The Benefit: This approach eliminates "synchronization latency." The end-user receives the absolute most current state of the data without the need for complex cache-clearing logic within the CMS whenever the source system updates.

2. Dataset Volume and Database Overhead

Scale is a primary driver of long-term system health. While replicating 5,000 blog posts is manageable, replicating millions of product variants into the CMS database is technically prohibitive.

System Impact: Every item stored in Optimizely CMS generates associated rows in the tblContent table. High-volume datasets favor Partial Routing to maintain a lean database. This ensures that maintenance tasks—such as background indexing, backup/restore operations, and system startup times—remain performant even as the external catalog grows.

3. Editor Workflow and Integration

The requirement for marketers to interact with external data within the Optimizely UI often dictates the choice.

Replication Pattern: Since items are persisted as native IContent objects, they appear within the content tree. This allows editors to use standard search panes and drag-and-drop functionality to place external items within ContentArea properties.
Routing Pattern: Because the resolution is virtual, items do not exist in the CMS database and generally do not appear in the content tree. To provide a similar experience, developers must often implement custom "External Content Pickers" to allow marketers to search and select external IDs from the source system API.

4. SEO and Metadata Management

The need for granular control over SEO elements, such as Title tags and Meta Descriptions, varies by organizational requirement.

Replication Pattern: SEO specialists can use the standard Optimizely UI to refine metadata on synchronized pages just as they would for native articles. No custom development is required to store these overrides.
Routing Pattern: Overriding SEO data requires a custom storage mechanism to hold the metadata alongside the virtual segments. The routing logic must then merge the external data with the CMS-stored overrides during execution.

2. Pattern A: Dynamic Resolution with IPartialRouter

Partial routing is a feature of the Optimizely CMS routing engine that handles dynamic URL segments mapping to external objects. It enables the CMS to resolve a parent page but delegate the resolution of the remaining URL segments to a custom handler.

Technical Implementation

In the .NET 8 middleware pipeline, the standard UrlResolver identifies the native parent page (e.g., /products/). If unmatched segments remain, the resolver invokes the registered IPartialRouter assigned to that page type. The router then resolves the segments and returns the associated external object.

public class ExternalProductRouter : IPartialRouter<ProductListingPage, ExternalProduct>
{
    private readonly IExternalProductService _productService;

    public ExternalProductRouter(IExternalProductService productService)
    {
        _productService = productService;
    }

    public object RoutePartial(ProductListingPage content, SegmentContext context)
    {
        // context.RemainingSegments is a queue of URL parts to process.
        var nextSegment = context.GetNextValue(context.RemainingSegments);
        var skuCode = nextSegment.Next;

        if (string.IsNullOrEmpty(skuCode)) return null;

        // Perform the external lookup. Resilience and caching are recommended here.
        var product = _productService.GetBySku(skuCode);

        if (product != null)
        {
            // Update context to indicate the segments have been consumed.
            context.RemainingSegments = nextSegment.Remaining;
            context.RoutedContentLink = content.ContentLink;
            return product;
        }

        return null;
    }

    public PartialRouteData GetPartialVirtualPath(ExternalProduct content, UrlGeneratorContext context)
    {
        // Handles outgoing URL generation for the external object.
        return new PartialRouteData
        {
            BasePathIdentifier = content.ParentLink, 
            PartialVirtualPath = $"{content.Sku}/"
        };
    }
}

Rendering Requirements

Since external objects are typically POCOs (Plain Old CLR Objects), the CMS requires an explicit renderer. A TemplateDescriptor or a Controller must be registered for the relevant type to prevent "Renderer Not Found" errors during the dynamic resolution process.

3. Pattern B: Data Synchronization (Replication)

Replication creates a local proxy of external data within the CMS database. This shifts complexity from request-time resolution to a background synchronization process.

Synchronization Workflow

Implementations typically utilize a ScheduledJob or a BackgroundService that follows a standardized loop:

Ingestion: Retrieve incremental updates from the external system to minimize data transfer.
Mapping: Map external properties to a native Optimizely content type (e.g., ExternalProductPage : PageData).
Persistence: Invoke IContentRepository.Save(content, SaveAction.Publish) to enable native CMS behaviors.

Advantages of Replication

Resilience: If the source system becomes unavailable, the website remains operational using the last synchronized copy stored in the CMS database.
Standard Features: Core functionalities such as breadcrumbs, XML sitemaps, and standard search indexing (via Optimizely Graph) operate natively without additional integration logic.
Editorial Flexibility: Marketers can add native blocks or additional content areas to synchronized pages, allowing for a hybrid content experience.

4. Resilience and Performance Strategies

External integrations introduce latency and potential failure points. Defensive programming is required to ensure site stability.

The Circuit Breaker Pattern

Utilizing the Polly library within the external service layer provides a safety mechanism. If the external API fails consistently, the circuit breaker triggers, allowing the router to immediately return a cached fallback or a 404 error. This prevents thread pool saturation and ensures the CMS remains responsive under load.

Advanced Caching Methodology

To maintain performance for dynamic routing, a layered caching strategy is recommended:

In-Memory L1 Cache: Utilize ISynchronizedObjectInstanceCache for high-frequency object resolution.
Stale-While-Revalidate: Return cached content immediately while triggering an asynchronous update of that cache in the background. This keeps the Time to First Byte (TTFB) low while refreshing the data state.

Conclusion

Choosing between Partial Routing and Replication depends on the balance between data velocity and editorial requirements. Partial Routing excels in handling massive, real-time datasets with minimal database impact, while Replication offers the most seamless experience for editors and leverages native CMS features at the cost of synchronization overhead. Effective architecture in Optimizely CMS 13 often involves a hybrid approach tailored to specific content types.