Getting started with event-driven systems

Martin Fowler's article What do you mean by "Event-Driven"? is a nice intro to terms used when working with event-driven system. It defines "event notification", "event-carried state transfer", "event-sourcing" and "CQRS". This article also contains links to more in depth articles, and also a further reading section, so make sure to check those out!

Event sourcing is not something you have to do when creating event-driven systems, but it is something that you should know about. It is an interesting architecture pattern that can have great benefits, but also be quite complex.

EventStoreDB's intro to Event Sourcing is an easy-to-read, high-level introduction to event sourcing. It also introduces other related concepts (such as domain-driven design) that are nice to know. Be aware that the article use some terminology specific to EventStoreDB and introduce the "EventStoreDB way" of doing event sourcing. It's still a very nice article if event sourcing is new to you, though.

Martin Fowler's Event Sourcing is a longer, very interesting read that goes in depth on event sourcing that I recommend reading. I've read this one many times over the last year, and I learn something new every time. Like the previous article from Martin Fowler, make sure to check out the links to related articles.

This article explains the differences between event sourcing and event streaming. It is a reply to the article Event sourcing is hard, which presents a mostly critical view of architectures using event sourcing. The latter article has some valid points, and even though it is conflating event sourcing and event streaming, it is worth a read.

Event streaming usually includes some form of message broker that systems can write to, and read from. Many message brokers exist and they do have different properties, different names for the same concepts. Gently down the stream is an introduction to Apache Kafka, styled as a children's book. It is general enough to be useful even if you're using another message broker.

From the CAP theorem we know that we can't have consistency, availability and partition-tolerance at the same time, but have to choose two. In many event-driven systems, that means accepting that systems are eventually consistent (because availability and partition-tolerance are usually more important). (Micro-)services benefits from being decoupled, but have to deal with these consistency issues when state changes are transmitted as events.

Cockroach Labs' blog explains how to work with duplicate events, idempotency and out-of-order events. event-driven.io has many good articles related to event-driven systems, but this article about outboxes, inboxes and delivery guarantees is especially interesting.