Techorama Event Based Architecture Chris van Zadel.pdf

Events
HOW THE RIGHT DESIGN PATTERN CAN GET YOU OUT OF TROUBLE

Solution design gone wrong
(handling of it made it worse)

Let’s get acquainted …
in/chrisvanzadel/
chrisvz@delta-n.nl
Chris van Zadel
Solution / Cloud Architect
“Helping to build
meaningful and lasting
solutions”

Founded in
1999
75
Employees
Based in
The Hague
Microsoft
Solutions Partner
ISO
Certified
C O N N E C T I N G T H E C L O U D
Delta-N

Confession : change of focus from “with
what” to the “why”
Tuesday 08 Oct 2024
Microservices Orchestration with Azure
Container Apps
09:45 - 10:45 | Room 14
Eduard Keilholz
Tuesday 08 Oct 2024
What is a Message Queue and when and why
would I use it?
11:15 - 12:15 | Room 10
Clemens Vasters
Wednesday 09 Oct 2024
Event Driven Apps @ Extreme Scale using Azure
Functions
11:15 - 12:15 | Room 10
Thiago Almeida
DDD's Application Building Blocks
09:45 - 10:45 | Room 12
Steve Smith
Orchestration vs. Choreography: The good, the bad,
and the trade-offs
14:30 - 15:30 | Room 8
Laila Bougria
Type-safe, polyglot messaging and eventing:
Stream/Queue/Topic "of T"
16:00 - 17:00 | Room 8
Clemens Vasters

Difficult questions (abstract):
• (How) Are we in control?
• How can we show this to ‘the business’?
• How can the design of the solution prevent this ever becoming
Mission Critical?

Examples of those difficult questions?
• “We are asked to provide behavioral data
six years ago for legal reasons. Let’s create
a lab and replay the environment as it was
six years ago.”
• “Someone compromised our datastores
and backups we need to recreate the
data.”
• “Someone from the business wants to tap
into key business events and act upon it.
And this is crucial and needs to happen
quick.”

System design: why events?
• Things do not always
work as designed.
• Unpredicted
circumstances
matter.
• Usage intend?
• One bucket or more?
• Reality can be very
frustrating

System design:
The solution
FE
BE

System design:
Transactional systems : CRUD
•CRUD systems (BE) perform update operations
directly against a data store. These operations
can slow down performance and
responsiveness and can limit scalability, due to
the processing overhead it requires.
•In a collaborative domain with many
concurrent users, data update conflicts are
more likely because the update operations take
place on a single item of data.
•Unless there's another auditing mechanism
that records the details of each operation in a
separate log, history is lost.
FE
BE
DB
Source: Event Sourcing pattern - Azure Architecture Center | Microsoft Learn

System design:
Transactional systems : Event sourcing pattern
•Backend contains (service bus) queues
•Backend contains event store(s)
•Backend contains event-consumers
taking care of persistence
FE
BE
MV
ES
Source: Event Sourcing pattern - Azure Architecture Center | Microsoft Learn

Which problems are being solved with
events?
• Operational control (yeah. Cool!)
• Scalability (yeah. Cool!)
• Communication tool (yawn. Boring!) with
business users/systems to talk usage scenarios
• De-coupling (yeah. Cool!)
• Rollback and replay/ audit trails (yeah. Cool!)
• Extensibility :
• Future features (yeah. Cool!)
• End user empowerment (yawn. Boring!)

Benefits details : Operational control
• Formal link to the business : used to scope
the solution and clarify requirements
during discovery phase (event storming)
• Data disaster & recovery : replay events
for data restoration
• Resource monitoring and planning :
queue-length is a great metric to share
with business!

Benefits details : Open up your systems for
other systems
• Selective event exposure enables system
integration to third party systems

Benefits details : Open up your systems for
end-users
• Selective event exposure opens up the
solution to end users by subscribing them
to (critical) events

Benefits details : Controlled scaling
• Every domain can have its own optimised
compute resources assigned to it (cost!)
and are dedicated to handling domain
specific operations
• Serverless implementation possible due to
event based (stateless) nature of events

Which problems are being introduced (and
need to be addressed)?
• Complexity for simple domains (i.e.
Systems solely adding data fast)
• Consistency / Transactional events
• Schema repository sharing
• Your success

A personal
encounter
where
complexity
for a simple
domain was
introduced.
Process cannot continue at the
moment. The transport conveyor
behind the self-service drop off unit is
not running. Please wait....

Complexity
API API
Cache
Audit
Events
(Kafka)
FE
BE
DATA
SOLUTION A SOLUTION B
Event
store
Mat
views
Event
Store alternative

Consistency / Transactional events
• Manage cross domain transactions
• Do not underestimate this!
• Effort depending on domain complexity
• Do not try to “Invent the wheel”: There
are best practices and patterns available
• Tip! Follow Allard Buijze CTO & founder at
AxonIQ (on LinkedIn)
https://www.linkedin.com/in/abuijze/

• Schema repository sharing
Source: Client-side schema enforcement - Schema Registry - Azure Event Hubs | Microsoft Learn
• Azure schema registry might help

There is help! (1/2) Discovery
• Event storming (event
discovery, event refining, track
causes, build bounded
context)
• Use domain driven (DDD) and
behavioral-driven design
(BDD)
• Event sourcing (design
pattern)

There is help! (2/2) Technology
Messaging Event consumption Observability
Event store

Implementation considerations (technical)
• Choose the right resource and SKU for the job
(security (private public), scaling, pricing)
• Use the power of Infrastructure As Code to stay
in control of deployments
• Do not ignore observability (track and trace
functional) and monitoring (OPS)

Back to those difficult questions
1. “We are asked to provide behavioral data six
years ago for legal reasons. Let’s create a
lab and replay the environment as it was six
years ago.”
2. “Someone compromised our datastores and
backups we need to recreate the data.”
3. “Someone from the business wants to tap
into key business events and act upon it.
And this is crucial and needs to happen
quick.”
The answers
1. Re-process the
events from the
event store and re-
create the
materialised views.
Stop processing at
the right moment in
time.
2. See 1
3. Provide access to
events or attach
specific events to
notification hub.
(codeless)

Summary
• Need full control : use events!
• Need a lot of control : shortlist events!
• Need a bit of control : consider events!
• I do not care : ........

We want more!
Tuesday 08 Oct 2024
Microservices Orchestration with Azure
Container Apps
09:45 - 10:45 | Room 14
Eduard Keilholz
Tuesday 08 Oct 2024
What is a Message Queue and when and why
would I use it?
11:15 - 12:15 | Room 10
Clemens Vasters
Event Driven Apps @ Extreme Scale using Azure
Functions
11:15 - 12:15 | Room 10
Thiago Almeida
DDD's Application Building Blocks
09:45 - 10:45 | Room 12
Steve Smith
Orchestration vs. Choreography: The good, the bad,
and the trade-offs
14:30 - 15:30 | Room 8
Laila Bougria
Type-safe, polyglot messaging and eventing:
Stream/Queue/Topic "of T"
16:00 - 17:00 | Room 8
Clemens Vasters

Thank you!
in/chrisvanzadel/
chrisvz@delta-n.nl
Chris van Zadel
Solution / Cloud Architect

Need more information?
Do you have any questions regarding Azure, Software Development or
architecture? Or need assistance with the design or implementation of a
software solution? Don’t hesitate to contact Pascal Kruijmel by phone or
email. Or book a meeting via the QR-code.
Pascal Kruijmel
+31 (0)85 487 52 22
pascalk@delta-n.nl

We empower you to
achieve more by responsibly
making the move to the
Microsoft Cloud.
Laan van Waalhaven 450, 2497 GR Den Haag
085 – 487 52 00 | info@delta-n.nl | www.delta-n.nl

Techorama Event Based Architecture Chris van Zadel.pdf

More Related Content

Similar to Techorama Event Based Architecture Chris van Zadel.pdf

More from Delta-N

Recently uploaded

Techorama Event Based Architecture Chris van Zadel.pdf