Event Queues. Why ? How ? When ?

CMS documentation:

Event Queues [ aka EQs ] are needed to ensure data and cache coherence and support communication between Sitecore instances.

In simple words - all the data changes are there.

No matter if you do publishing, content editing, or any other modifications, Sitecore will record those changes into Event Queue, and spread them among other instances.

WHY? 

Use-case:

• Andy visits panda site page. He sees 'Panda in zoo' article title
• Sitecore renders the requested page:

• fetches needed items from DB
• puts them to cache

If Bob visits same panda page, Sitecore would NOT read data from database, as all the needed info in cache!

So far good. But here comes the content change:

• Content author Leo modifies items for panda page, so that article title is 'Panda is Free'
• Leo publishes changes, and data gets modified in web database
• Leo goes to live site and requests panda page
• He sees that 'Panda is Free' now

How come ? Sitecore cached all the needed item data to built page. As a result Bob`s request was served without a single SQL query fired. . .
However Leo saw modified content, not cached one.

Event queue mechanism allows to apply changes from one instance to others.
Live server had processed changes introduced by publishing instance, and had removed obsolete data from cache before Leo request in our example.

HOW? WHEN?

Each Sitecore instance would read fresh events raised by other instances and apply them locally every 2 seconds by default.

All Sitecore content databases have their own 'EventQueue' table which stores following data:

• InstanceData - huggeee JSON document with Event details !
• EventType (f.e. item saved, property changed, publish ended)
• Who is responsible for doing that ( UserName )
• Which Sitecore instance did that ( InstanceName )
• When was is done ( Created )
• Stamp ( monotonously increasing value )

The last processed stamp by previous iteration is stored in Properties table (key-value storage) with EQStamp_InstanceName ( f.e. EQSTAMP_WS-NMI2-SC72REV140526 ) as plain number (f.e. 566174).

Sitecore CMS would read fresh events in similar SQL query:

SELECT * FROM EventQueue WHERE InstanceName!=CurrentInstance AND STAMP>lastProcessed

HOW LONG SHOULD EVENT QUEUE ROW BE KEPT ?

Once all the Sitecore instances have processed given event, it becomes useless.
It make sense to remove event queue rows shortly after they were processed to make SQL Server life simpler.

WHAT PROBLEMS COULD BE CAUSED BY EQ?

In case events are fired faster than being processed, a delay in showing new content can be introduced.

In case a lot of already processed events are stored in EventQueue table, the SQL performance would drop, and processing of new events would occur slower.

In next chapter I will show basic ways of troubleshooting kinda issues.