4 ms·

In my experience the most important feature of any event driven system should be to have a simple way to lookup all the listeners that exist and what events the

In my experience the most important feature of any event driven system should be to have a simple way to lookup all the listeners that exist and what events they're hooking into and in which exact order. As soon as you start having them all around the code it becomes a nightmare to follow the logic, especially if code has side-effects.

3pt14159 9y ago
How do you do this with disparate systems? For example a ruby application that handles and emits events concurrently with a python one.
- aaronblohowiak 9y ago
  systems report which things they are listening to
- sametmax 9y ago
  The router should provide the feature. E. G crossbar.io router has meta rpc enpoints and pub/sub events letting you inspect and react to any activity taking place. It's expensive on resources so you should use it sparingly, but it's very handy to get a grasp on what the hell is going on.
- Rabidgremlin 9y ago
  Centralized logging, with a track and trace ID that is passed around and logged. I have seen this work to great effect with a dynamic (force directed) based graph been built in real-time showing the flow of calls/messages between systems. Also provided timings and drilldowns to find processing issues and performance problems.
  - convolvatron 9y ago
    this helps a lot, particularly if your event system spans multiple nodes. its invaluable for correctness, but you can learn a lot about performance too
  - chiph 9y ago
    People I've worked with kinda-sorta understand the advantages of having a trace ID (aka context ID, correlation ID, etc), but don't code it into their systems. Or they do something like replace an incoming ID with their own, which negates it's value. For folks who aren't familiar with the concept - at the initiation of any action (user button click, timer firing, automated job starting, etc.) a new ID is created then passed to every single method and external call. This allows you to trace that action as it wends it's way through your distributed systems.
- dragonwriter 9y ago
  You do it on the shared event bus.
jordanlev 9y ago
This makes a ton of sense. Do you have any examples / explanations / tutorials you could point to that demonstrate how this is achieved in code?
- deleted 9y ago
  [deleted]
- snarfy 9y ago
  In a microservice architecture this is known as service discovery and is handled by applications like etcd, consul, and zookeeper. Inside a single process you can accomplish the same thing by having a central interface that all others use to register themselves and query others.
wolco 9y ago
listeners all should be in one place, the routes should be in one place ideally that pattern should apply everywhere.
Chris_Newton 9y ago
In my experience the most important feature of any event driven system should be to have a simple way to lookup all the listeners that exist and what events they're hooking into and in which exact order. I’m with you on the first part: finding all possible listeners to a certain event is sometimes useful in the same way that finding all possible callers of a certain function is useful. I’m not so sure about the “which exact order” part, though. IME, this style of architecture works best when you can entirely decouple event listeners and run them asynchronously, so each event listener is unknown to both the original event source and any other event listeners, except for whatever mechanism is used to register as a listener. If you do need an event to trigger multiple actions in different parts of your system in a specific order, then apparently those parts of the system aren’t entirely independent. In that case, I usually suggest creating a single listener somewhere near them to co-ordinate. It might be very simple, but it makes the dependency between the multiple actions explicit, and now you have a single place in your code with responsibility for triggering each action in the required sequence, without imposing any ordering requirements on your entire event-based architecture.
- ivanhoe 9y ago
  I meant the situation when you have multiple listeners listening on the same event. Even if you're running all handlers asynchronously, knowing the order of their invocation can be helpful when you're trying to figure out what happened by looking in the logs.

In my experience the most important feature of any event driven system should be to have a simple way to lookup all the listeners that exist and what events they're hooking into and in which exact order. As soon as you start having them all around the code it becomes a nightmare to follow the logic, especially if code has side-effects.

3pt14159 9y ago

How do you do this with disparate systems? For example a ruby application that handles and emits events concurrently with a python one.

aaronblohowiak 9y ago
systems report which things they are listening to
sametmax 9y ago
The router should provide the feature. E. G crossbar.io router has meta rpc enpoints and pub/sub events letting you inspect and react to any activity taking place. It's expensive on resources so you should use it sparingly, but it's very handy to get a grasp on what the hell is going on.
Rabidgremlin 9y ago
Centralized logging, with a track and trace ID that is passed around and logged. I have seen this work to great effect with a dynamic (force directed) based graph been built in real-time showing the flow of calls/messages between systems. Also provided timings and drilldowns to find processing issues and performance problems.
- convolvatron 9y ago
  this helps a lot, particularly if your event system spans multiple nodes. its invaluable for correctness, but you can learn a lot about performance too
- chiph 9y ago
  People I've worked with kinda-sorta understand the advantages of having a trace ID (aka context ID, correlation ID, etc), but don't code it into their systems. Or they do something like replace an incoming ID with their own, which negates it's value. For folks who aren't familiar with the concept - at the initiation of any action (user button click, timer firing, automated job starting, etc.) a new ID is created then passed to every single method and external call. This allows you to trace that action as it wends it's way through your distributed systems.
dragonwriter 9y ago
You do it on the shared event bus.

jordanlev 9y ago

This makes a ton of sense. Do you have any examples / explanations / tutorials you could point to that demonstrate how this is achieved in code?

deleted 9y ago
[deleted]
snarfy 9y ago
In a microservice architecture this is known as service discovery and is handled by applications like etcd, consul, and zookeeper. Inside a single process you can accomplish the same thing by having a central interface that all others use to register themselves and query others.

wolco 9y ago

listeners all should be in one place, the routes should be in one place ideally that pattern should apply everywhere.

Chris_Newton 9y ago

In my experience the most important feature of any event driven system should be to have a simple way to lookup all the listeners that exist and what events they're hooking into and in which exact order. I’m with you on the first part: finding all possible listeners to a certain event is sometimes useful in the same way that finding all possible callers of a certain function is useful. I’m not so sure about the “which exact order” part, though. IME, this style of architecture works best when you can entirely decouple event listeners and run them asynchronously, so each event listener is unknown to both the original event source and any other event listeners, except for whatever mechanism is used to register as a listener. If you do need an event to trigger multiple actions in different parts of your system in a specific order, then apparently those parts of the system aren’t entirely independent. In that case, I usually suggest creating a single listener somewhere near them to co-ordinate. It might be very simple, but it makes the dependency between the multiple actions explicit, and now you have a single place in your code with responsibility for triggering each action in the required sequence, without imposing any ordering requirements on your entire event-based architecture.

ivanhoe 9y ago
I meant the situation when you have multiple listeners listening on the same event. Even if you're running all handlers asynchronously, knowing the order of their invocation can be helpful when you're trying to figure out what happened by looking in the logs.