The Light Weight Event System (LWES) is an open source toolkit allowing the exchange of information between machines in a platform agnostic, language neutral, decoupled way. The exchange of information is done in a connectionless fashion using multicast or unicast UDP, using self-describing data so that any platform or language can translate it into its local dialect.

This leads to a system with the following features:

• Fire and forget messaging
• Decoupling of senders (emitter) from receivers (listeners)
• Centerless, no single point of failure
• Support for many to many communications where nodes can enter and leave the system at any time
• Computer language and hardware platform independent

The system consists of two major components:

• Emitter: a source of events, this is usually a server or process that wants to announce something
• Listener: a sink of events which deserializes and processes events on the fly as they are received.

Optionally, one can run a "journaller", which is a listener that writes raw events to a compressed log instead of deserializing the data, effectively deferring deserialization to a later time.

LWES uses key-value pair data types and supports strings as keys and a set of primitive types as values. Note that LWES does not support complex types or nested objects. This was a deliberate design decision in order to constrain the scope of the system and limit data exchanges to just key-value pairs. If you need to exchange complex types or do RPC, tools such as Thrift or Protocol Buffers are probably more appropriate for you.

The Light Weight Event System was originally developed at GoTo.com, which became Overture, which was acquired by Yahoo!, where it was open sourced in 2007. Currently, it is maintained by developers at OpenX as well as some of the original contributors.

LWES is specifically designed for non-blocking, best-effort delivery of data from a sender (emitter) to a set of receivers (listeners). The LWES library provides UDP unicast and multicast implementations of emitters and listeners which provide these functions in various programming languages. However, you could easily write your own transport and only use the LWES API and serialization methods to generate network-ordered byte arrays. But the original intention was to use UDP to provide connectionless, best effort delivery of data.

But Isn't UDP Unreliable?

One of the most common questions regarding the Light Weight Event System is the design choice to use UDP multicast by default. Packets can get dropped, machines can have hardware issues, and networks can get congested, in which case data can be lost forever. This should be taken account before using LWES -- it is a best-effort system designed to provide minimal impact to applications that are senders (emitters). Some key points:

• Establishing TCP connections is expensive. If you don't need reliable, guaranteed delivery, it can be overkill.
• You can run multiple journallers or listeners when using multicast, to protect against listener failure.
• Implementing non-blocking clients over TCP (for example, using libevent) is non-trivial.
• When getting data from point A to point B, you have to do flow control somewhere. LWES puts the burden of flow control on the receiver so that applications sending data are minimally impacted from a performance standpoint.
• You can always implement your own transport if you don't like UDP.

Taking these considerations into account, LWES is useful in a number of specialized scenarios:

• Monitoring and Instrumentation: machines can report about their status using LWES, and applications are minimally blocked by its presence. Other machines can receive these events and process them. MonDemand is an implementation of an monitoring and instrumentation system using LWES.
• Logging: machines can log events remotely over LWES to journaller machines to be processed in batch at a later date. The LWES deserialization and access methods perform very well on batch systems such as Hadoop.
• Feedback Loops: services can report their status, and a separate listener can make feedback decisions and pass the data back to the running service.
• Ad-Hoc Debugging: if a system is sending diagnostic events over UDP multicast, you could easily start up a listener and start to see what's happening in real-time. When you're finished, you simply stop the listener and the system is unaffected.