Surprising Qualities of Event Driven System

Few discoveries I made during the last two years working on a small java project (that grow big) for a client using Java 8, Vertx.io, RxJava and OSGi.

I consider these new (to me) as I don't recall reading about them anywhere else. Comments are welcomed.

Fail and Retry

Normally when exception happens you need to address the exception by different means, but what if you want to try again?

Let's imagine we are calling a remote system or waiting for a network device to reconnect, the most sensible process will be to retry the operation, now on a normal call a service process you will have to develop some loop of try catch to keep trying the call until successful, this creates ugly code that appears in many places in the codebase and hard to test and refactor.

If the process was triggered with an event (assuming you have some bus that delivered this event to you) you can apply a retry strategy by simply wrap the event in a retry event with information about the time to wait or the number of attempts and publish the event again. The retry event handler job is just to handle the wait/sleep and trigger the inner event again (and again). Your business login only needs to give information about the retry strategy (delay/attempts) and nothing more. All the login is handled in one place which is the event retry strategy handler.

Never leak API specification

Designing API is hard (it is really hard) because any change you make to your API you have to refactor all the consumers (and tests) and they may have cascading effects for the change in unexpected places.

How about events? if you are an event subscriber you only interested in consuming the event and you are not publishing any API as no one is calling you. This means you don't have an API to manage.

You can still provide output by using the event bus and not to any direct callers.

Parallel features and refactoring

Well, with event-driven design you can simply develop your new feature as a separate parallel effort, there is no need to change the old code, once the feature/fix is in place we can simply disable the old process (handler) and the system will not know of the change (this is simplified of course as you need to make sure all the work the old code was doing is not needed anymore or replaced with the new code).

The best example I know of is CQRS, where there can be many subscribers to an event, each implementing a different process handling the information delivered, the term coined is projections.

In principle, the old and new event handlers can happily live together in the system (in case they don't override each other work), this eliminates the need to refactor the old handler to be the new handler. Switch one ON and switch the other OFF.

Thanks for reading.