How does Sitecore propagate events to the core database on CM and CD servers?

Question

How does Sitecore propagate events to the core database on CM and CD servers?

I'm trying to understand the technical details of how Sitecore propagates events like item:added, item:published etc to the core databases on both content management and content delivery servers.

How does Sitecore use publish/subscribe for event propagation? What is the role of the core Sitecore databases like master and web in propagating events between servers? What specific classes and database tables are involved in polling for new events and raising them on CM and CD instances? If I wanted to debug the event propagation process, what are some key places I could put breakpoints or enable logging? What are some key things to check like database connection strings, publishing targets etc to ensure events are flowing properly between servers?

Additionally:

How are events propagated on a full publish/rebuild of the entire database? Are there any differences in how individual item events vs. full rebuild events are propagated to the cores? What should I check if full rebuild events don't seem to be getting picked up properly on the CD servers? Any insights into the internals of Sitecore's event architecture and how to troubleshoot it would be appreciated.

Looking for low-level technical details on how this works behind the scenes.

Answer 1

Each of the databases (core, master and web) has its own EventQueue table.

Every time a Sitecore instance (e.g. CM) executes an action which can potentially result in triggering a handler on another Sitecore instance (e.g. CD), a new row is inserted into the table.

That row contains information like:

• Created
• InstanceName - which Sitecore instance triggered the event
• EventType - e.g. Sitecore.Eventing.Remote.PublishEndRemoteEvent, Sitecore.Kernel, Version=18.0.0.0, Culture=neutral, PublicKeyToken=null
• InstanceData - e.g. {"CompareRevisions":true,"Deep":true,"FromDate":"\/Date(1704379709820)\/","LanguageName":"fr-BE","Mode":3,"PublishDate":"\/Date(1707405142311)\/","PublishingTargets":["{8E080626-DDC3-4EF4-A1D1-F0BE4A200254}"],"RepublishAll":false,"RootItemId":"8aa5d77b-2950-466a-b5f7-5035633774f5","SourceDatabaseName":"master","TargetDatabaseName":"web"}

All the other instances which use that database check the table from time to time and if there is any new event, they process it if necessary.

So e.g. in the scenario above, another instance triggered publishing of an item with descendants to web database in fr-BE language. So if CD server reads that event, it will execute PublishEndRemoteEvent and handle it appropriately.

Answer 2

Events are delivered from one instance to another as records in EventQueue data table. By default, Sitecore uses Core DB for storing these events, but that can be changed in config.

<eventing defaultProvider="sitecore">
  <providers>
    <clear/>
    <add name="sitecore" type="Sitecore.Eventing.EventProvider, Sitecore.Kernel" systemDatabaseName="core"/>
  </providers>
</eventing>

How Event Queue works

• When any item is saved on CM1, "item:saved" event is executed, it creates an instance of Remote Event (SavedItemRemoteEvent).
• Now, the remote event is passed into Event Queue table in the respective Sitecore database. This event contains many things like Item Id, the Sitecore Instance Name on which event occured, Instance Type, Instance Data, User Name, date time when event occured, etc.
• Each Sitecore Instance has a trigger to check this event queue periodically and collects all events to be processed.
• All instances select events raised by other instances (Remote Events) like "item:saved:remote" and should be new or created after the instance's last processed event.
• Suppose, the CM2 finds an event of "SaveItemRemoteEvent", then it clears cache related to the item and update the data of that item. Similarly, each different type of event has its own operations to perform, which are specified in the web.config in pipelines.

According to this architecture, the CMs can have many instances in a cluster, theoretically n numbers of CM or CD instances can work very well in a cluster using EventQueue and gets updated all the time.

Event Queue is used to make CMs in sync when item operations like Save, Creation, Deletion, Recycling, Restore, etc. happens. This sync happens with the help of Master database EventQueue.

References:

https://sitecoreblog.patelyogesh.in/2013/07/sitecore-event-queue-scalability-king.html

https://sitecore-community.github.io/docs/pipelines-and-events/events/

Hope it helps!