Event-Driven Architecture – How to Handle Initial State in an Event-Driven Architecture?

Architectureevent-programming

In an event-driven architecture each component only acts when an event is sent through the system.

Imagine a hypothetical car with a brake pedal and a brake light.

The brake light turns on when it receives a brake_on event, and off when it receives a brake_off event.
The brake pedal sends a brake_on event when it is pressed down, and a brake_off event when it is released.

This is all well and good, until you have the situation where the car is turned on with the brake pedal already pressed down. Since the brake light never received a brake_on event, it will stay off – clearly an undesirable situation. Turning the brake light on by default only reverses the situation.

What could be done to resolve this 'initial state problem'?

EDIT: Thank you for all the responses. My question was not about an actual car. In cars they solved this problem by continuously sending the state – therefore there is no startup issue in that domain. In my software domain, that solution would use many unnecessary CPU cycles.

EDIT 2: In addition to @gbjbaanb's answer, I'm going for a system in which:

the hypothetical brake pedal, after initialization, sends an event with its state, and
the hypothetical brake light, after initialization, sends an event requesting a state event from the brake pedal.

With this solution, there are no dependencies between components, no race conditions, no message queues to go stale, and no 'master' components.

Best Answer

There are many ways to do this, but I prefer to keep a message-based system as decoupled as possible. This means the overall system cannot read the state of any component, nor any component read the state of any other (as that way lies spaghetti ties of dependancies).

So, while the running system will look after itself, we need a way to tell each component to start itself up, and we already have such a thing in the component registration, ie at startup the core system has to inform each component that it is now registered (or will ask each component to return its details so it can be registered). This is the stage at which the component can perform its startup tasks, and can send messages as it would do in normal operation.

So the brake pedal, when the ignition is started, would receive a registration/check message from the car management and it would return not only a "I'm here and working" message, but it would then check its own state and send the messages for that state (eg a pedal depressed message).

The problem then becomes one of startup dependancies, as if the brake light is not yet registered then it will not receive the message, but this is easily resolved by queuing all of these messages until the core system has completed its startup, registration and check routine.

The biggest benefit is that there is no special code required to handle initialisation except that you already have to write (ok, if your message-sending for brake pedal events is in a brake-pedal handler you will have to call that in your initialisation too, but that's usually not a problem unless you've written that code tied heavily to the handler logic) and no interaction between components except those that they already send to each other as normal. Message passing architectures are very good because of this!

Related Solutions

Handling events and incoming Web API calls simultaneously

From what you're describing, it strikes me that you could have a problem with the threading model for your event processing loop (ie. the RabbitMQ message handler) and how ASP.NET's concurrency works.

There's two ways to tackle this: in-process and out-of-process.

In-process:

Use a dedicated background thread for your event loop, one that is isolated from the threads that are processing HTTP requests.
Do this in Application_Start. That will give you the concurrency you're looking for: handling incoming HTTP requests & listening for messages at the same time.

Unfortunately, you're doing this in an application framework that's not been designed for this style of work processing. Phil Haack explores why a long running background thread, and an event processing loop is exactly that, in ASP.NET is problematic So, depending on your context, you may be happy to ignore the problems surface in that post. The main one to consider is that application pools, by default, get torn down after 20 minutes. That's fundamentally in-compatible with the always-on process model an event pulling loop needs.

Out-of-process:

Stop handling RabbitMQ messages in your application and expose each type of message processing as an HTTP triggered RESTy API call instead. Introduce a RabbitMQ-to-HTTP bridge process (a windows service, or even a console application) that will listen for Rabbit messages and trigger the appropriate RESTy method.

The downside of this approach is increased deployment complexity and you have to consider distribution as part of your failure scenarios. The nice bit is that your main application runs off HTTP only and your RabbitMQ message processor itself is very straightforward, with no threading worries. All this should facilitate development and testing, despite the increased level of distribution.

Variation: instead of going HTTP-centric for your main application, go Rabbit-centric, and build an HTTP -> RabbitMQ bridge instead and convert your existing REST calls into message triggered equivalents. I don't recommend that, because you're always dependent on a very particular message broker to do work, while HTTP is a ubiquitous integration technology.

Java – Event Driven Microservice Race Condition

Think of your situation as data and processes that depend on it. What results is this:

Service A creates entity a
Service B creates entity b
Service D performs a process d which depends on a and b
The decision on when d should happen is made by service C

D has to do its duty when C tells it to, but C does not provide all dependencies for that process.

Thats the problem how i see it. Now on to the solution: If you want to keep D as simple as possible, C has to provide all necessary information to D. There is no way around that.

If it is acceptable to put some logic into D (depending on the language and frameworks in use, that logic might happen to be 2 LoC), you can wait for all data in D:

Entity a is created with ID 11
Entity b is created with ID 22 and referes to a#11
C listens for the create-event of b and then tells D the following: "As soon as you have a#11 and b#22, do d with them.
D waits for both events and then does its thing.

If you are using tools like Promises and ReactiveX, this becomes a really simple thing:

// within C
class EntityEvents
    Observable<EntityCreatedEvent<T>> onCreated(Class<T> entityClass)

entityEvents.onCreated(EntityB.class).subscribe(b -> d.doYourThing(b.aId, b.id));

// within D
class EntityRepository
    Promise<EntityA> getExistingOrOnCreated(long aId)
    Promise<EntityB> getExistingOrOnCreated(long bId)

// within D - when the call "doYourThing" from C is received
Promise.all(
   entityRepository.getExistingOrOnCreated(aId),
   entityRepository.getExistingOrOnCreated(bId)
).then((entityA, entityB) -> {
   // do whatever it is you need to do
})

This gets a lot harder when you have to persists the waits for the entities. In that case, a scheduled job may be the better choice.

Best Answer

Related Solutions

Handling events and incoming Web API calls simultaneously

Java – Event Driven Microservice Race Condition

Related Topic