In this new post to his site Herberto Graca has posted the latest part of his "The Software Architecture Chronicles* series, focusing this time on event-driven architectures.

This post is part of The Software Architecture Chronicles, a series of posts about Software Architecture. In them, I write about what I’ve learned on Software Architecture, how I think of it, and how I use that knowledge. The contents of this post might make more sense if you read the previous posts in this series.

Using events to design applications is a practice that seems to be around since the late 1980s. We can use events anywhere in the frontend or backend. When a button is pressed, when some data changes or some backend action is performed.

But what is it exactly? When should we use it and how? What are the downsides?

He starts by talking about the "what", "when" and "why" of using events to drive the architecture of the system, going into each of the topics in a bit more depth:

• To decouple components
• To perform async tasks
• To keep track of state changes (audit log)

He then goes on to talk about common patterns for event-driven applications including event notification, event-carried state transfer and event sourcing.