---
title: Events and event providers
slug: cms-13/docs/events-and-event-providers
docTags: 
createdAt: 2026-07-30T20:22:08.991Z
---

Use the event system to distribute events between Optimizely Content Management System (CMS) websites in a load-balanced environment. The event system keeps data consistent across instances by broadcasting changes (such as cache invalidations) from one site to all others. The system is provider-based: use the built-in provider, the Azure provider, or develop a custom provider for your hosting environment.

## Event providers

Optimizely offers an [Azure event provider](https://nuget.episerver.com/package-details/?packageId=EPiServer.Azure) on the NuGet feed, optimized for [Microsoft Azure](docId\:K2_xGil1cnFT8xjCZ17A9). The Azure provider uses Service Bus for distributing events and requires no server or network configuration.

Develop a custom event provider if your hosting environment requires a different transport mechanism.

## Configure an event provider

Register a custom event provider in `Startup.cs` by replacing the default provider in the service container. The following example registers `MyEventProvider`:

```csharp
public void ConfigureServices(IServiceCollection services)
{
    services.AddCmsEvents();
    services.AddSingleton<EventProvider, MyEventProvider>();
}
```

For information on defining and publishing custom event types, see [Send and receive custom events](docId\:bSjUhLQxeEnes-rOTiJ2N).

## Event system process flow

The following list describes the event system lifecycle from startup through message delivery.

1. When a CMS website starts, the system performs these actions:
   a. Creates a secret if one does not exist in the site database.
   b. Initializes the event host for sending and receiving remote event messages.
   c. Initializes each configured event provider.
   d. Enables the event system after initialization completes.
2. Application code calls `IEventPublisher.PublishAsync` to publish an event object.
3. The system invokes `HandleAsync` on each registered `IEventSubscriber<T>` that matches the event type.
4. `IEventPublisher` passes the message to the registered `EventProvider` for remote delivery.
5. The `EventProvider` on the receiving instance delivers the message to the event host.
6. The event host calls `IEventPublisher`, which invokes all matching `IEventSubscriber<T>` services with a context argument indicating that the event was broadcast.

## Test the event system

CMS uses the event system for cache invalidation across instances. To verify that cache events propagate correctly, edit a page on one CMS site and confirm that the change appears on a second load-balanced site:

1. On CMS #1, go to a page in the example website.
2. On CMS #2, enter edit view and go to the same page as in step 1.
3. On CMS #2, add, edit, or delete text on the page and click **Publish**.
4. On CMS #1, refresh the page and confirm it reflects the changes from step 3.