_1.png)
Event-Driven Architecture in Kentico: A Practical Guide
Event-driven architecture in Xperience by Kentico means custom code reacts automatically to global events content changes, object updates, user actions instead of external systems polling the platform or waiting on a live request. Xperience implements this through global event handlers, async/await support, and background task queues, letting integrations run independently of the main request without blocking editors or risking a failed third-party call.
In this guide, we'll cover:
- Why tightly-coupled, request-driven integrations become a bottleneck at scale
- How Xperience by Kentico's event system actually works, from trigger to handler
- Where event-driven patterns genuinely help, and where they add unnecessary complexity
The Problem With Request-Driven, Tightly-Coupled Integrations
Most CMS integrations start out simple: when something happens, call the other system directly and wait for a response. That pattern works fine at small scale, but it creates specific, recurring problems as a platform grows:
- The calling system is blocked until the external system responds, slowing down the editor's or user's action.
- If the external system is down or slow, the operation inside the CMS can fail or hang along with it.
- Every new integration requires modifying the core code path that triggers it, increasing the risk of breaking existing functionality.
- Systems become aware of each other's internal details, making each one harder to change or replace independently.
- Scaling becomes difficult, because a single slow dependency can throttle the entire request chain.
Xperience by Kentico's own documentation acknowledges this directly, describing two ways to build integrations: tightly-coupled patterns with shared resources and high dependence between components, and decoupled patterns built around independent components and asynchronous communication.
The Core Idea: React to Change, Don't Wait for It
1. Global Events as the Trigger Mechanism
Global events allow custom code to execute automatically whenever specific actions occur in Xperience whether from a user's action or from the application's own internal logic. Instead of a developer manually inserting integration calls throughout the codebase, a handler is attached once to the relevant event and Xperience takes care of invoking it whenever that event fires.
2. Object and Content Events as the Most Common Source
Object events are the most frequent type of global event in Xperience, firing whenever objects are created, updated, or deleted. In practice, this covers most real integration triggers: a new page published, a form submitted, a product updated, a user record changed.
3. Asynchronous Processing to Avoid Blocking the Request
The Xperience API supports implementing both object and content event handlers using the async/await pattern, and provides a ThreadQueueWorker class specifically for processing queued jobs on a background thread. This means a slow external call sending an email, generating a PDF, notifying a third-party service — doesn't have to hold up the page save, publish, or form submission that triggered it.
4. Decoupled Integration as the Resulting Architecture
Put together, these pieces let Xperience by Kentico support decoupled integrations: independent components communicating asynchronously, rather than systems calling each other directly and waiting. Kentico's guidance on integration tooling explicitly recommends this pattern for scenarios like synchronizing a custom CRM whenever a corresponding Xperience object changes, or sending a notification whenever an important field is updated.
The Tightly-Coupled Journey (Traditional Request-Driven Approach)
Here's what happens when an integration is built as a direct, synchronous call.
Step 1 — An Action Triggers an Immediate Call
A page is published, and the code path directly calls an external API as part of that same operation.
Step 2 — The Request Waits for a Response
The publishing action is held up until the external system responds, whether that takes 50 milliseconds or 5 seconds.
Step 3 — A Failure Propagates Backward
If the external system errors out or times out, that failure can interrupt or fail the original publishing action, even though the two are logically separate concerns.
Step 4 — Every New Integration Touches the Same Code Path
Adding a second integration means editing the same core logic again, increasing the surface area for regressions with each addition.
The Event-Driven Journey (Xperience by Kentico Approach)
Here's the same scenario, restructured around global events and async handling.
Step 1 — An Action Occurs in the System
A page is published. Xperience's core publish logic runs and completes independently of any external integration.
Step 2 — A Global Event Is Raised
The publish action raises a content or object event automatically, without the core logic needing to know what if anything is listening.
Step 3 — An Event Handler Executes
A previously registered handler picks up the event and runs its custom logic, using async/await where the work involves I/O such as an external API call.
Step 4 — Background Processing Handles the Slow Part
If the integration involves a batch of work or a slow external call, it's queued through a background worker, so the original publish action was never actually held up waiting for it.
Implementation Detail: Async Support Is Built Into the Event Handler Pattern Itself
Worth calling out specifically: Xperience doesn't require bolting async handling onto event handlers as an afterthought. The Xperience API provides full support for object and content event handlers written with the async/await pattern directly, and separately offers a ThreadQueueWorker<TItem, TWorker> class for batched background processing — the kind of thing the platform's own Lucene search integration uses internally to log and queue indexing tasks.
Request-Driven vs Event-Driven in Xperience by Kentico
| Aspect | Request-Driven / Tightly Coupled | Event-Driven in Xperience by Kentico |
|---|---|---|
| Trigger mechanism | Direct call embedded in core logic | Global event handler attached separately |
| Blocking behavior | Caller waits for a response | Handler can run async or on a background thread |
| Failure isolation | External failure can break the original action | External failure is isolated from the triggering action |
| Adding a new integration | Requires editing the core code path | Requires registering a new handler only |
| System awareness | Systems know about each other directly | Systems don't need to know who's listening |
| Best suited for | Operations that need an immediate response before continuing | Notifications, sync jobs, and integrations that can run independently |
What's Working Well
No Core Code Changes for New Integrations. Once a global event handler pattern is in place, adding a new integration is a matter of registering another handler not modifying the logic that triggers page saves, publishes, or workflow transitions.
Failure Isolation. Because handlers run independently and can be queued asynchronously, a failing or slow third-party service doesn't automatically fail the editor's original action.
Native async/await Support. Developers aren't working around the platform to write non-blocking integration code — async event handlers are a directly supported part of the Xperience API.
A Path for Both Simple and Batch Scenarios. Small-scale reactions, like sending a notification on a field update, and larger-scale synchronization jobs both have a supported pattern, from a single async handler to a ThreadQueueWorker-based background queue.
The Honest Trade-Offs
Debugging Gets Less Direct. When code runs in reaction to an event rather than as a visible call in the main logic, tracing what happened and in what order takes more deliberate logging than following a single synchronous call stack.
Not Every Scenario Should Be Async. If an operation genuinely needs to confirm success before the calling process continues — for example, validating a payment before completing checkout — a direct, synchronous call is still the more appropriate pattern than a fire-and-forget event.
Ordering and Retries Require Planning. Asynchronous, queued processing means events may be handled slightly after the triggering action, and a team needs to decide deliberately how failed or retried tasks are tracked, rather than relying on an immediate error at the point of failure.
It Adds a Layer of Indirection. A developer new to a project has to learn where event handlers are registered before they can trace what actually happens when, for instance, a page gets published that knowledge isn't visible directly in the triggering code.
Surprising Decisions Worth Noting
The Platform's Own Search Indexing Uses This Pattern. Xperience's Lucene search integration uses global event handlers to log indexing tasks, which are then queued on a background thread by a class derived from ThreadQueueWorker the same pattern available for custom integrations is the one the platform relies on internally.
Event Handlers Can React to Custom Object Types, Not Just Built-In Ones. Because Xperience allows custom object types to integrate fully with the platform, including relationships to system classes, global event handlers can be attached to changes on those custom types just as easily as on standard content.
The Platform Explicitly Recommends Deciding a Source of Truth First. Kentico's own integration guidance recommends storing and managing data inside Xperience and syncing changes outward when possible and when that isn't feasible, clearly defining which system is the source of truth before wiring up event-driven synchronization, since ambiguity here tends to cause hard-to-diagnose data conflicts later.
The End Result
Event-driven architecture in Xperience by Kentico isn't a separate product layer it's built from the same event handler system developers already use for customization, combined with native async support and a background processing utility for heavier jobs. The result is an integration approach where new systems can react to changes in content without needing to be wired directly into the core save or publish logic.
That doesn't mean every integration should be event-driven. Scenarios that genuinely need an immediate, confirmed response are still better served by a direct call. But for the much larger category of integrations — notifications, synchronization, logging, third-party updates — building them as decoupled reactions to global events keeps the core platform faster, more resilient to third-party outages, and easier to extend without re-touching existing code.
If your team is planning integrations on Xperience by Kentico, or evaluating a migration where existing integrations were built as tightly-coupled, synchronous calls, this is usually the first architectural decision worth revisiting.
Frequently Asked Questions
What is event-driven architecture in Xperience by Kentico?
Event-driven architecture in Xperience by Kentico is a way of building integrations and custom logic that react to changes in the system — such as content being created, updated, or deleted — through global event handlers, instead of the external system having to poll or make a direct synchronous request.
Does Xperience by Kentico support asynchronous event handling?
Yes. The Xperience API supports implementing object and content event handlers using the async/await pattern, and provides a ThreadQueueWorker class for processing tasks on a background thread so integrations don't block the main request.
What is the difference between tightly-coupled and decoupled integrations in Kentico?
A tightly-coupled integration shares resources directly and depends heavily on the other system being available and responsive at the moment of the call. A decoupled integration uses independent components and asynchronous communication, so systems can react to events without depending on each other's uptime or response time.
What triggers a global event in Xperience by Kentico?
Global events are triggered by actions inside the system, both from user interaction and from the application's own logic. Object events are the most common type, firing when objects such as pages or content items are created, updated, or deleted.
When should I use event-driven architecture instead of a direct API call in Kentico?
Event-driven architecture fits best when an integration needs to react to changes without blocking the editor's workflow, when multiple systems need to know about the same change, or when the external system may be temporarily unavailable. Direct, synchronous API calls remain a better fit when an immediate response is required before the current operation can continue.
Ready to Build Event-Driven Integrations on Xperience by Kentico?
[CTA PLACEHOLDER — insert your team's specific call to action here, e.g. "Talk to our Kentico architecture team about your integration plan" with a link to a relevant contact/consultation page.]
.png)