Caching Strategy

The introduction of Optimizely Graph has fundamentally changed the caching equation for PaaS developers. In older CMS architectures, caching was mostly a local concern centered on object instance caches and reducing SQL round-trips. In CMS 13, the primary delivery layer has shifted from the application server toward the global edge. That requires a more deliberate, multi-tiered strategy spanning the application node, the Graph delivery layer, and the client-side consumer.

This module explains how to build a high-performance delivery path that combines local caching with edge intelligence to produce fast, globally distributed experiences while still keeping content fresh.

1. The Multi-Tiered Cache Architecture

A resilient CMS 13 implementation typically uses several layers of caching, each acting as a filter that reduces pressure on the tier below it while increasing the speed of delivery to the user.

1.1 Layer 1: The Local Object Cache (ISynchronizedObjectInstanceCache)

This remains the first line of defense for server-side code such as Razor views, ViewComponents, and background services. When application code calls IContentLoader.Get<T>(), the engine first checks the high-speed in-memory object cache.

• Synchronization: In a multi-node DXP environment, these caches are synchronized through Azure Service Bus. When content is published on one instance, invalidation signals are propagated across the rest of the cluster.
• Thread safety: Objects are returned as IReadOnly to help ensure immutability across concurrent request execution.

1.2 Layer 2: The Optimizely Graph Edge Cache

When content is synchronized into Optimizely Graph, it is served through a globally distributed delivery layer. GraphQL queries can be cached at points of presence geographically closer to the user, allowing read traffic to bypass the origin DXP application service entirely.

• Stateless scaling: Traffic spikes from campaigns place far less pressure on the origin because the edge layer serves the majority of repeat reads.
• Active revalidation: Once content synchronization completes, the edge cache can be invalidated so new content becomes available globally without waiting on a long TTL.

1.3 Layer 3: Front-End Stale-While-Revalidate (SWR)

In headless front ends such as Next.js or React applications, caching often moves even closer to the browser. With the stale-while-revalidate pattern, the front end can serve the most recent cached JSON immediately while a background refresh fetches the latest data from Graph. This makes the application feel fast even under weaker network conditions.

2. Dynamic Invalidation with Graph Webhooks

In a modern PaaS solution, Graph Webhooks reduce the lag between authoring and delivery. In older architectures, remote rendering heads often remained unaware of backend changes until a cache expired. With Webhooks, Optimizely Graph can notify a remote delivery head the moment relevant content changes.

The technical sequence:

1. Publish: An editor publishes content in the CMS.
2. Push: The CMS synchronization engine sends serialized content to Optimizely Graph.
3. Callback: Graph performs a secure POST to a front-end revalidation endpoint such as /api/revalidate.
4. Flush: The front end clears the relevant page or route cache and re-fetches data from the Graph edge.

3. Technical Constraints: When to Bypass the Cache

Good caching strategy is not just about knowing where to cache. It is also about knowing when not to. Caching works best for content that changes on a human editorial cadence rather than at machine speed.

Conclusion

Caching in an Optimizely CMS 13 PaaS solution is no longer a single-feature concern. It is a coordinated strategy involving local memory, distributed invalidation, and global edge delivery. By using the synchronized object cache for server-side logic, leaning on Optimizely Graph for edge-optimized reads, and wiring Webhooks into front-end revalidation flows, developers can build solutions that remain both fast and fresh. The real skill lies in combining those layers intelligently while knowing when live data should skip the cache entirely.