Event Sourcing Reactive English - Meetupfiles.meetup.com/14341692/Event Sourcing... · Event Sourcing is an architectural pattern in ... application is being determined by a sequence

Event Sourcing Intro & Challenges

Michael PlödinnoQ

Principal Consultant@bitboss

Most current systems only store the current

state

IncidentRestController

IncidentBusinessService

IncidentDAO

Incident

ID USER_ID DATE TEXT1 23423 11.03.2014 Maus defekt 2 67454 12.03.2014 EMail Empfang3 93729 12.03.2014 Monitor defekt… … … …

Classical Architecture



IncidentDAO

Incident

ID USER_ID DATE TEXT1 23423 11.03.2014 Maus ist kaputt2 67454 12.03.2014 EMail Empfang3 93729 12.03.2014 Monitor defekt… … … …

Update

The dataset is directly being changed, no history

1 Audit Log only with extra effort

2 No replay

3 Snapshots only with extra effort or via backups

? Issues

Many applications are working well with the classic

approach

However there are areas where this approach reaches

it’s limitations

? Reactive

? Responsive

? Resilient

? Elastic

? Message driven



IncidentDAO

Incident

Not quite reactive…

Database

Event Sourcing is an architectural pattern in which the state of the

application is being determined by a

sequence of events

Building Blocks

Applications

Event Queue

Applications issues events to a queue

Event Handler

The Event handler is processing the

events

Event Store

The event store is persisting the

events

An event is something that happened in the past

tjetzt

EventEventEventEventEvent

The names of the Events are part of the

Ubiquitous Language

D D D

ShipmentDeliveredEvent

CustomerVerifiedEvent

CartCheckedOutEvent

CreateCustomerEvent WillSaveItemEvent

DoStuffEvent

Code Examplepublic class CustomerVerifiedEvent {

private String eventId;

private Date eventDate;

private CustomerNumber customerNumber;

private String comment;

public CustomerVerifiedEvent(CustomerNumber custNum, String comment) {this.customerNumber = cusNum;this.comment = comment;this.eventDate = new Date();

}

}

Scope your events on the basis of

Aggregates

D D D

An Event is always immutable!

The sequence of events in the queue is also called

Event Stream

tnow

EventEventEventEventEvent

IncidentCreatedEvent incidentNumber: 1 userNumber: 23423timestamp: 11.03.2014 12:23:23 text: „Maus defekt“status: „offen“

Event Stream Example

IncidentTextChangedEvent incidentNumber: 1 text: „Maus ist Kaputt“

IncidentClosedEvent incidentNumber: 1 solution: „Neue Maus“status: „geschlossen“

Let’s reuse the ESB from the failed SOA

project

NO

NO

NO

!Prefer dumb pipes with smart endpoints as a suitable message broker architecture

1 Complete rebuild is possible

2 Temporal Queries

3 Event Replay

Well known examples

=Version Control Systems

or Database Transaction Logs

The Event Store has a very high business value

There is no delete!!

A delete is just another

event

IncidentCreatedEvent incidentNumber: 1 userNumber: 23423timestamp: 11.03.2014 12:23:23 text: „Maus defekt“status: „offen“

IncidentChangedEvent incidentNumber: 1 text: „Maus ist Kaputt“

IncidentClosedEvent incidentNumber: 1 solution: „Neue Maus“status: „geschlossen“

IncidentRemovedEvent incidentNumber: 1

Aren’t there performance issues attached to this kind of

data storage?

YES!

Application State

Think about applciation state

Application

Event Queue

Event Handler

Event Store

Application State

The application queries the pre-processed application state

CQRS

Command Query Responsibility Separation

IncidentSOAPEndpoint


IncidentDAO

IncidentBusiness Model

Client

Incident DTO

Incident View Model

RDBMS

Incident ER-Model

Netzwerk

Netzwerk

EventHandler EventsEvents

Event Sourcing & CQRSIncidentCommandEndpoint

IncidentCommandService

IncidentCommandDAO

IncidentQueryEndpoint

IncidentQueryService

IncidentQueryDAO

Read Storage

Events

Select * from

Event Store

Event Sourcing is an interesting architectural option. However there are various challanges,

that have to be taken care of

1 Consistency

2 Validation

3 Parallel Updates

YES

!Systems based on CQRS and Event

Sourcing are mostly eventually

consistent


Eventual ConsistencyIncidentCommandEndpoint


IncidentCommandDAO



IncidentQueryDAO

Read Storage

Events

Select * from

Event Store

BUT

!You can build a fully consistent system which follows Event

Sourcing principles

EventHandler

EventsEvents

Full ConsistencyIncidentCommandEndpoint


IncidentCommandDAO



IncidentQueryDAO

Read Storage

EventsSelect * from

Event Store

Your business domain drives the level of consistency not

technologyDeeper Insight

D D D

Increased (but still eventual) consistency

EventHandler

EventsEvents

IncidentCommandEndpoint


IncidentCommandDAO



IncidentQueryDAO

Read Storage

EventsSelect * from

Event Store

async

! There is no standard solution

1 Consistency

2 Validation

3 Parallel Updates

Example DomainUser

Guid idString emailString password

RegisterUserCommand ChangeEmailCommand

UserRegisteredEvent Guid idDate timestampString emailString password

EmailChangedEvent Guid userIdDate timestampString email

We process 2 million+ registrations per day. A user

can change her email address. However the emails address

must be unique

?How high is the

probability that a validation fails

Which data is required for the validation

Where is the required data stored

$What is the business

impact of a failed validation that is not

recognized due to eventual consistency and how high is the

probability of failure

Your business domain drives the level of consistency

Deeper Insight

D D D

1 Validate from Event Store

2 Validate from Read Store

3 Perform Validation in Event Handler


ValidationIncidentCommandEndpoint


IncidentCommandDAO



IncidentQueryDAO

Read Storage

Events

Select * from

Event Store

1 Consistency

2 Validation

3 Parallel Updates

Example DomainUser

Guid idString emailString password



EmailChangedEvent Guid userIdDate timestampString email

What happens when Alice and Bob share an

account and both update the email address at the same

time

? What would we do in a

„classic old school architecture“

UserRestController

UserBusinessService

UserDAO

User

ID EMAIL PASSWORD… … …

2341 [email protected] lksjdaslkdjas … … …

Update

Pessimistic or optimistic locking

Your business domain drives the locking quality

Deeper Insight

D D D

!Pessimistic locking on a

data-level will hardly work in event sourcing architectures

EventHandler

EventsEvents

Where to „pessimistically“ lock?

Read Storage

Events

Event Store

UserRestController

UserBusinessService

UserDAO

User

Commands

Consider a business lock with a UserLockedEvent

? Do you

REALLY need a full lock

Most „classic architecture“

applications are already running fine with

optimistic locks

Introduce a version field for the domain entity

User

Guid idLong versionString emailString password



EmailChangedEvent Guid userIdDate timestampString emailLong version

Each writing event increases the version

UserRegisteredEvent {guid: 12, version: 0, email: [email protected], password: werwe2343}

EmailChangedEventversion: 0



{guid: 12, version: 1, email: [email protected], password: werwe2343}

{guid: 12, version: 2, email: [email protected], password: werwe2343}

EmailChangeFailedEvent

Also here:you should be as

consistent as your domain

requires

Thanks!Michael Plöd

https://www.innoq.com/de/trainings/microservices-training/

@bitbosshttp://slideshare.net/[email protected]

mailto:[email protected]?subject=

Documents

Event Sourcing Reactive English - Meetupfiles.meetup.com/14341692/Event Sourcing... · Event Sourcing is an architectural pattern in ... application is being determined by a sequence