Once the partitioning strategy has been defined, in terms of which events and monitors go to which correlators, it is necessary to translate this into an engine topology. This is achieved by connecting source and target event correlators on separate channels, such that events emitted by a source correlator on a specific channel find their way to the correct target correlator. A set of two or more event correlators connected in this way is known as a correlator pipeline, illustrated in the following illustration. This figure represents an example topology for a high-end application – the majority of applications use a single correlator only, or have far simpler topologies.

In the illustration above, an event correlator can perform the function of each of the 7 nodes (router, worker, watcher, tallier). Each target correlator performs some processing before passing the results to a second worker correlator (worker3, worker4) in the form of events, emitted on the default channel (*). tallier collates the results from these correlators for forwarding to any registered receivers. A final correlator, watcher, monitors the events emitted by router on chan1 and chan2 and emits events (possibly containing status information or statistical analysis of the incoming event stream) to any registered receivers.

To deploy an application on a topology like that shown above requires separating the processing performed into a number of self-contained chunks. In figure 3 it is assumed the core processing can be serialized into three chunks, with the first two chunks split across two correlators each (worker1/2 and worker3/4 respectively) and the third chunk residing on a single correlator (tallier). Intermediate results from each stage of processing are passed to the next stage as emitted events, which connected correlators receive by registering on the appropriate channels.

To realize this application structure requires coding each chunk of processing as one or more separate monitors, which emit intermediate results as an event of known type on a pre-determined channel. These monitors can then be loaded onto the appropriate correlator. This may require an existing application, which grows beyond the capacity of a single event correlator, to be re-written as a number of (smaller) monitors to allow partitioning of the application processing into separate chunks in the manner described above.