Skip to content

Event Driven

Jump to bottom
Tomas Tulka edited this page Mar 27, 2023 · 19 revisions

Request driven software speaks when spoken to, event driven software speaks when it has something to say. (Jon Udell)

Eventual Consistency

  • You need to let go of the notion of ever being done.
  • Eventually consistent system never expects to be done. Instead, is perpetually working to achieve equilibrium.

Types of Events

It's important to distinguish between types of event. Even there are same from the technical perspective, there are different from the design perspective (how people reason about them).

Notification Events

They represent something that happened in the real world but include no expectation of any future action. They travel in only one direction and expect no response (sometimes called “fire and forget”), but one may be “synthesized” from a subsequent event.

  • Events are sent to everyone else, not just those components that are going to react.
  • The sender is just broadcasting the event, he does not need to know who is interested and who will respond.

Commands

Commands are actions—requests for some operation to be performed by another service, something that will change the state of the system. Commands execute synchronously and typically indicate completion, although they may also include a result.

Sending commands from a service to another service violates autonomy of a service business capability.

Queries

Queries are a request to look something up. Unlike events or commands, queries are free of side effects; they leave the state of the system unchanged.

Event Streams as a Shared Source of Truth

Problems with today approaches:

  • Service interfaces form tight point-to-point couplings, make it hard to share data at any level of scale, and leave the unanswered question: how do you join the many islands of state back together?
  • Shared databases concentrate use cases into a single place, and this stifles progress.
  • Messaging moves data from a tightly coupled place (the originating service) to a loosely coupled place (the service that is using the data). Unfortunately, messaging systems provide no historical reference, which means it’s harder to bootstrap new applications, and this can lead to data quality issues over time (The Data Divergence Problem).

Database Inside Out

“The database inside out” is an analogy for stream processing where the same components we find in a database—a commit log, views, indexes, caches—are not confined to a single place, but instead can be made available wherever they are needed.

  • The log makes data available centrally as a shared source of truth but with the simplest possible contract. This keeps applications loosely coupled.
  • Query functionality is not shared; it is private to each service, allowing teams to move quickly by retaining control of the datasets they use.

The “database inside out” idea is important because a replayable log, combined with a set of views, is a far more malleable entity than a single shared database. The different views can be tuned to different people’s needs, but are all derived from the same source of truth: the log.

Event Sourcing

Event sourcing is an implementation strategy for the persistence of state, e.g. of aggregates. This strategy should not be exposed beyond the boundaries of aggregates.

  • The source of truth for all data is the event log.
  • An event that's published to an event log should be described in its entirety.
  • There is no canonical event model for the event log. Producers have control over the data format of the events they deliver, and consumers will adapt to that.

References

Clone this wiki locally