Implementation of metrics

The implementation of a metric is split into two parts:

1. root element receiving all inbound messages
2. sub-elements doing the real work

For example, the page impression root element receives a tracking event. It has three sub-nodes which care about writing data to (1) cache, to (2) database and (3) reading content from cache.

Writing to cache is the default way. It is done for each inbound event. Updating the database is carried out once within a configured timespan. The root node installs a scheduler event which is fired and forwards a message to the cache reader telling it to collect page impressions for a specific contractor and send them to the database writer.

From an architectural point of view, it splits the metrics handling component into a functional element and technical sub-elements.

The core challenge is to handle the actor instantiation properly. The database nodes must be created below a common database root providing all sub-nodes with connectivity and failure recovery features.

Therefore all actors must be registered with the parent nodes they will belong to and are created by them. This creates a separation of concerns when it comes to providing supervisor hierarchies that have a pure technical reason, eg. database connectivity.

As the creating node only knows that the new component must receive, eg. a database connection, the constructors of child elements must follow a common pattern. Additional information, required for setting up a node must be retrieved from a central location either by direct access or message passing.