Introduction

In my current project, we work on a module that lends itself to an event-driven architecture design. It almost whispered between the lines: this would be perfect as an event-driven system.

This post explores the indicators that led to that conclusion and discusses how specific domain characteristics guided the architectural choice.

Events

I work in the railway section that receives multiple events from various sources. The main stakeholders and domain experts discuss these events. An example of such an event: the customer tapped their card.

These events are a recurring topic in discussions among stakeholders and domain experts, forming the basis for how they describe the system's behaviour. The customer was able to narrow the potential list of functionality based on them: "We should be able to implement XYZ based on these events, and address functionality R in the next version."

Resilience

During downtime, the system should degrade gracefully, allowing unaffected components to continue operating independently of the unavailable dependency. Once connectivity is restored, it should automatically resume processing from the last successful state, retrying or replaying pending events as needed. This approach ensures continuity without manual intervention — a behaviour that naturally aligns with event-driven design principles.

Observability

Very early on, the domain expert described what he wanted to observe. Based on these events, he would construct a timeline of events and use it extensively for troubleshooting and keeping external contractors "in check". The system would emit events, listen to them itself to drive the operations forward. Additionally, these events serve as a valuable measure of observability. I am not saying that an Event Driven Architecture is the only way to achieve this design. However, it lent itself nicely to it.

Extensibility

Continuing on these events, pushing the workflow forward, and acting as great observability points. They would also be ideal for extending system functionality without necessitating a rebuild or code changes. Interested in a particular piece of data to create insight or functionality? Great, subscribe to the topic and build up your own system. We would park pieces of functionality by saying, "This will be part of the second version, and we have the extensibility endpoint for it"—both a great conversation stopper and starter at the same time.

State Machine

While describing how events trigger state transitions, one of the domain experts and I said simultaneously, "like a state machine?" In many respects, it is akin to a state machine. I always find it a sign of good design when you realise you are building on structures, techniques, and proven methods from the early days of computer science or the experts.

Conclusion

This blog post examined the indicators that suggested adopting an Event-Driven Architecture (EDA) for a railway module project. The key signs included: domain experts naturally discussing events as first-class citizens (like "customer tapped their card"), the need for resilience in handling flaky external dependencies, strong observability requirements through event timelines, built-in extensibility for future functionality, and the recognition that the system operates like a state machine with event-driven state transitions. These characteristics collectively suggested that EDA was the appropriate architectural choice for this particular use case.