EVENT-DRIVEN CONTENT RENDERING
Decouple public content delivery from the CMS, APIs, databases, and other systems that produce it. StreamX processes content when source data changes and distributes the resulting output before users request it.
Scale delivery independently
Keep published content available
Update without cache complexity
Modern websites pull content and data from multiple systems: CMS platforms, APIs, databases, commerce systems, search, and other operational services.
When those systems participate in page delivery, their latency, capacity, and availability become part of the request path.
Caching, static generation, and revalidation reduce that dependency, but introduce their own operational trade-offs. Teams still need to decide what to cache, when to rebuild or revalidate it, and which related outputs need to change when the underlying data changes.
Event-driven content rendering takes a different approach: process the change when it happens, then make the resulting content ready for delivery before traffic arrives.
Already-processed content remains available independently of the systems that produced it. If a CMS, API, or database slows down or becomes unavailable, the latest successfully processed version can continue to be served.
A page can depend on content and data from several systems, and one change may affect multiple outputs. Those relationships are defined in the service mesh, so the relevant processing runs when an input changes without rebuilding everything or manually coordinating cache invalidation across sources.
Backend work follows source changes rather than pageviews. Once content has been processed and distributed, higher traffic increases load on the delivery layer without proportionally increasing work across the systems behind it.
CMS platforms, APIs, and databases remain systems of record without having to serve every public request. Read-heavy traffic is handled independently by the delivery layer.
Updates are triggered by source events rather than TTLs, cache expiry, or a request that causes regeneration. The publication flow determines when content changes become available.
Requests are served without waiting for CMS, API, or database responses. Removing source-system latency and rendering work from the request path reduces one source of performance variability and provides a stronger foundation for consistently good Core Web Vitals.
StreamX provides the event-driven processing and delivery layer between the systems that own your content and the users that consume it.
StreamX calls this model continuous materialization: instead of building content on a schedule or computing it when a request arrives, changes continuously trigger the processing needed to produce and distribute updated output. The delivery state evolves as source data changes, so it is already materialized when users request it.
1
Publication and data changes enter StreamX as events from connected source systems.
2
The service mesh defines which processing should execute in response to each event.
3
Triggered services render pages and fragments or generate other required outputs, such as search records, feeds, or sitemap entries.
4
Updated output is distributed to the delivery layer so it is available before a user requests it.
Materialize before request
Public, read-heavy content whose state can be known in advance: content pages, product information, documentation, announcements, navigation, listings, fragments, search documents, sitemaps, feeds, and other derived delivery data.
Keep live at request time
Authentication, payments, transactions, account state, live eligibility decisions, and other operations whose result depends on the exact user or system state at request time should continue to use controlled runtime APIs.
HOW IT COMPARES
|
Approach |
When work happens |
What happens on request |
Main trade-off |
||||||||
|---|---|---|---|---|---|---|---|---|---|---|---|
|
Static site generation |
Build time |
Serve pre-built output |
Large or frequent rebuilds can become operationally expensive |
||||||||
|
ISR/revalidation |
Build, request or revalidation time |
Usually serve cached output; some requests trigger regeneration |
Freshness and runtime behavior depend on revalidation/cache sta |
||||||||
|
Server-side rendering |
Request time |
Render using runtime compute and data |
Rendering and required backends remain on the request path |
||||||||
|
Client-side rendering |
Browser/request time |
Browser fetches data and renders |
Runtime APIs and browser execution remain part of delivery |
||||||||
|
CDN caching |
After content has been requested/generated |
Serve cached response on a hit; go upstream on a miss/revalidation |
Origin/runtime dependencies still exist behind the cache |
||||||||
|
Event-driven |
Source-change time |
Serve already-processed content from the delivery layer |
Requires an event-processing layer and configured processing logic |
The difference is when the work happens
A CDN can protect an existing request path by serving cached responses. ISR can avoid regenerating every page on every request. Static generation can remove runtime rendering entirely.
StreamX starts from a different trigger: the source change itself. That event runs the processing defined in the service mesh and distributes the resulting output before demand arrives.
Event-driven content rendering is especially valuable for large, read-heavy digital experiences where content changes frequently, traffic can spike unexpectedly, and published information needs to remain available independently of source systems. These characteristics appear across industries, from news and public services to travel, retail, financial services, and telecommunications.
Answers to some of the most common questions about how StreamX renders and delivers content.
The main difference is when rendering happens. Static generation renders at build time, ISR regenerates based on revalidation, and SSR renders on request. StreamX renders when source content changes, then distributes the resulting output before users request it.
The processing logic and dependencies are defined in the StreamX service mesh. When a source change enters the mesh as an event, that configuration determines which processing runs and which outputs are updated. This allows changes to be handled incrementally instead of rebuilding unrelated content.
StreamX can render pages, fragments, and other content with a layout. It can also generate outputs such as search records, sitemap entries, feeds, and metadata that other services consume programmatically.
Anything that depends on the exact state of a user or system at request time should stay live. This includes transactions, payments, account data, authentication, eligibility checks, and other request-specific operations.
StreamX processes updates from the moment it receives the source event rather than waiting for a rebuild, crawl, or user request. Publication-to-delivery latency is usually under 200ms.
Already-processed content remains available from the delivery layer. Users can continue receiving the latest successfully rendered version without waiting for the source system to recover. New changes from that source cannot be processed until it becomes available again.
A CDN typically serves a cached response when one is available and falls back to the upstream request path when content needs to be fetched or revalidated. StreamX moves eligible rendering work earlier: source changes trigger processing and the resulting output is distributed before a user request arrives.
It is best suited to content whose state can be prepared before the request. Transactions, personal account state, payments, live eligibility decisions, and other operations that must evaluate the current state when the user acts should continue to use runtime APIs.
Tad Reeves
Principal AEM Architect,
Arbory Digital
"Even with a move to AEM Edge Delivery (Helix), one is still faced with the problem of how to architect around the availability and performance of backend systems that you now have to stitch together at the CLIENT side.
That’s where StreamX (...) can be used as a potential for dramatically increasing speed and reliability for complicated web/mobile experiences."
From article in Arbory Digital Blog
Ready to see what StreamX can do for you?