Global Office Directory
Share this page
Home > Community > Technical Blogs > Getting to Know Sitecore > Introducing the Sitecore Event Queue
Today, Sitecore 6.3 (formerly known as Twin Peaks) was released. This is an important release because it brings true enterprise class scalability to Sitecore CMS. It is now possible to create content management (CM) and content delivery (CD) clusters that consist of geographically-separated machines.
Some important architectural changes make this possible. One of these changes is the addition of the "event queue". This post explains what the event queue is and how it works.
The way communication is typically handled in Sitecore is through events. When an item is saved, an event is triggered. But events are isolated to a single server. If an item is saved, the "saved item" event is only triggered on the server used to actually save the item. How do the other servers in the cluster know the item was saved?
This is where the event queue comes in. Sitecore 6.3 introduces the concept of "remote events". Consider a CM cluster with 5 nodes. When an item is saved, an event it triggered on 1 of the nodes. This is the "saved item" event. The event is replayed on the other 4 nodes as a remote event. This allows all 5 servers in the cluster to stay in sync.
That's my quick explanation of the event queue. And since a picture is worth a thousand words, here's a video that illustrates how the event queue works.
Tags: Architecture, Scalability
- Arnold Zokas July 19, 2010 at 3:07 PM
- Alex de Groot July 19, 2010 at 10:30 PM
- Erick Mott August 10, 2010 at 5:01 PM
Adam is a technical architect on Sitecore's Product Marketing Team. He is responsible for spreading technical knowledge inside and outside of the company, with an emphasis on external systems and applications.
This website is designed to be fully functional with scripts disabled in browser. Please contact the webmaster for any suggestions