Sunday, April 23, 2006

EDA Lessons Learned - Event History

See EDA Lessons Learned for the list

Events Driven Architecture is about as loosely coupled as it gets.

One event can result in the generation of other events that can result in still more events ad infinitum. This is how our system works - there are many events. For example, one user click is 1 event, but it very often results in 10+ other events. The "event type" typically stays the same, but different attributes on the event change (e.g., the status). Also, the event is re-published to different destinations.

When there are problems in the system (e.g., an event is routed to an error queue), it is very useful to know where the event came from. Event history is also very useful in bringing new developers up to speed on how the system works. In a system that has many different types of events and many different services processing events, it is very easy to get confused. Also, documentation doesn't always keep up with the system. Event history is a form of system self documentation ;)

We record basic history on events. Each time an event is generated, history is appended to it. We track information like service name, service type, destination name, destination type, and host name. We are using JMS so we record the history in a message property.

No comments: