Sitecore Event Queue - The Scalability King

Sitecore EventQueue architecture gives great scalability to Sitecore, launched with version 6.3. Enabling it can allows clustering of Content Management Servers (CMs) and Content Delivery Servers (CDs). It allows events on one server to be executed on other servers in a cluster.

Suppose, there are two instances of CM. Now, think how an item changed on CM1 will be reflected to CM2? There should be something like triggering mechanism to communicate both CMs. Event Queues are playing very important role to make both CMs synced.

How Event Queue works

  1. When any item is saved on CM1, "item:saved" event is executed, it creates an instance of Remote Event (SavedItemRemoteEvent).
  2. 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.
  3. Each Sitecore Instance has a trigger to check this event queue periodically and collects all events to be processed.
  4. 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.
  5. 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. :)

Configure  Event Queues

To enable EventQueues, from web.config, find EnableEventQueues setting. Set its value to true. This setting can also be set from \App_Config\Include\ScalabilitySettings.config, which will be given more precedence over web.config settings.
If enabled, Sitecore sends local events to the event queue available to remote instances, 
and handles events in the queue from remote instances. -->
      <setting name="EnableEventQueues">
        <patch:attribute name="value">true</patch:attribute>
<!--  Event Queue's processing interval. 
Event Queue will be requested to process after below given interval -->

Things to take care regarding Event Queue

  1. If we have more than one instances in an environment, it is must to EnableEventQueue on all the instances
  2. The processinginterval should be as minimum as we can set, say 2 seconds, so each server gets synced in no time.
  3. All CM instance should have exact time.
    If two instances have time difference of 5 minutes, then there the instance running late will get updates of other instance after 5 minutes, so sync will never be done between them.
  4. When events are not triggered on time on the remote(other) servers, clear the EventQueue table from database.

    Let's consider a practical case, once a user by mistake published 10k items and publishing is going on through PI. There are few others items queued after it, which are more important. Now, we found that we have to stop the 10k items' to give priority to other items. We have only one option to restart PI. But after PI restart, once we found once that those 10,000 items started publishing again (No one added them again)!! Ufff.. finally we came to know there was some issue with Event Queue processing/clearing. We cleared Event Queue and restarted PI again, now good to see, problem is solved. :)

Different events handled by EventQueue

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.

Suppose, we have a separate PI to do publishing apart from a CM. Now, each publish set from the CM is done by PI, how? It is just because of Event Queues. CM sends an event for PI to do publish. So, PI will trigger the event and starts doing actual publish.

When items are published from CM or PI, CD should be notified when the publish is completed, CD starts clearing html cache accordingly. This happens by Event Queue on web database.

Great Sitecore Event Queue architecture!!


  1. hey yogesh, it's really nice article explaining how eventqueue works !!

  2. Thank you Vinar, it's really interesting to learn about eventqueue.

  3. Which is better, ScalabilitySettings.config or EnableEventQueues in web.config, to enable event queue

    1. Hi, it's always better to have all such configuration changes in patch config files i.e., ScalabilitySettings.Config for better maintenance and clean Web.config

  4. yes that's right , i always recommeded everyone for creating a patch file insted of changing the web.config

  5. Hi,
    How sitecore identifying the instance name? Which means which instance is doing action? is there any config settings for that?

    1. Sitecore application's instance name is identified by MACHINE NAME - IIS WEBSITE NAME, which you can also find instance name in logs when application is started.

      There is no config for mentioning which instance should do which action except publishing. We can assign publishing to a specific instance, so that while publishing from any sitecore instance, it will be done on the specified only, which is managed by event queue. You can find "Publishing.PublishingInstance" setting from the Sitecore.config / ScalabilitySettings.config file.

  6. Hi,

    I have the EventsQueue setting enabled in Sitecore.config and the same is commented in ScalabilitySettings.config. Is there any chance my setting in Sitecore.config overriden by ScalabilitySettings.config? Because sometimes my web index is not rebuilding on CD server.


    1. Hi Vijay, I do not think this setting is overridden in your case. Check http://CD-Domain/sitecore/admin/showconfig.aspx (on your CD server), it should be enabled only as per your configurations.

      If it's enabled, then you should check your index update strategy (, or check error logs while publishing happens to troubleshoot.