Christian Posta bio photo

Christian Posta

Chief Architect, cloud application development @ Red Hat, author Microservices for Java Developers, open-source enthusiast, committer @ Apache, Cloud, Integration, Kubernetes, Docker, OpenShift, Fabric8, #blogger

Twitter Google+ LinkedIn Github Stackoverflow

Over the weekend I read an excellent essay called “Programming Without a Call Stack - Event-driven Architectures” by Gregor Hohpe that does an excellent job of explaining how an event-driven architecture (EDA) differs drastically from the traditional, procedural, call-stack style of programming that most are used to and comfortable with. The EDA approach is nothing new: it’s employed in many embedded systems, high-throughput web companies (think Amazon), and is the backbone of creating highly concurrent applications (the Actor model from Erlang/Scala?).

Gregor starts by describing what an EDA would look like and describes some of the characteristics EDAs usually exhibit. The focus of an EDA is to drastically reduce coupling and assumptions between the individual components so that the components can vary independently, so that they system as a whole can achieve great throughput and concurrency, and finally so that system state can be replayed, recreated, and analyzed in ways that cannot be done (or would be very difficult) with traditional architectural styles. The primary philosophy shift between the call-stack approach and the EDA approach is in responsibility and interaction. The responsibility of “knowing what to do” is shifted from the caller to callee and the only interaction is with fine-grained asynchronous messages passed in one direction. Compare this to the call-stack model, where one thread of execution delegates to sub routines, waits for a response, then takes that data and operates on it or calls other sub routines. There is always one trace of execution, the sub routines are always fast, and the location of the subroutines is known at compile/build time. The responsibility in the call-stack approach is on the caller and the interactions depend on a context, synchronization with the calling thread, and knowing exactly how and what to call next.

Gregor also puts forth that doing EDA properly, although elegant when done correctly, is not easy and without proper tooling and visualization of the composed system, debugging and verifying that the components were put together properly can be very difficult.

Gregor gave a talk on this topic during the OOPSLA 2005. I could not find a video archive of this talk specifically, but the essay is posted as a PDF at this website here:

If anyone has a link to the video (if there is one?), I would be grateful if you could provide it.