This document provides an overview of event-driven architecture and distributed transactions with microservices. It discusses event-driven programming and what constitutes a distributed transaction when using microservices. It then covers some common solutions for distributed transactions like the 2PC and Saga patterns. The Saga pattern uses a choreography or orchestration approach and events to coordinate transactions across services. Message brokers like Kafka, RabbitMQ and Azure Event Hub are discussed for facilitating event-driven architectures. Vert.x and Spring WebFlux are presented as reactive frameworks that are non-blocking and scale well.

1. EVENT - DRIVEN
ARHITECTURE

2. Agenda
01
02
03
04
Introduction To Event Driven Architecture
What is Saga Pattern?
Choreography-Based Saga
Orchestration-Based Saga
Benefits of Event Driven Architecture
Message Brokers
What is Message Broker?
Vert.x
What is Vert.x?
How Does It Work?
Spring Web Reactive
What is WebFlux?
Spring MVS vs WebFlux

3. Event Driven Programming
Event-driven programming is a programming paradigm in which the
flow of program execution is determined by events - for example a
user action such as a mouse click, key press, or a message from th
e operating system or another program.
An event-driven application is designed to detect events as they
occur, and then deal with them using an appropriate event-handling
procedure.

4. What is a distributed transaction?
When a microservice architecture decomposes a monolithic system into self-encapsulated services,
it can break transactions. This means a local transaction in the monolithic system is now distributed
into multiple services that will be called in a sequence.
Monolithic System Microservices
03

5. What Is The Problem?
In a database system,
atomicity means that in a
transaction either all steps
complete or no steps
complete. The microservice-
based system does not have
a global transaction
coordinator by default. In the
example above, if the
CreateOrder method fails,
how do we roll back the
changes we applied by the
CustomerMicroservice?
How do we
keep the
transaction
atomic?
Do we
isolate user
actions for
concurrent
requests?
If an object is written by a
transaction and at the same
time (before the transaction
ends), it is read by another
request, should the object
return old data or updated
data? In the example above,
once UpdateCustomerFund
succeeds but is still waiting
for a response from
CreateOrder, should
requests for the current
customer’s fund return the
updated amount or not?

6. Possible SolutionsThe problems are important for microservice-based systems. Otherwise, there is no way to tell
if a transaction has completed successfully.
2pc Pattern
2pc is widely used in database
systems. For some situations,
you can use 2pc for
microservices. Just be careful;
not all situations suit 2pc and,
in fact, 2pc is considered
impractical within a
microservice architecture
Saga Pattern
The Saga pattern is another
widely used pattern for
distributed transactions. It is
different from 2pc, which is
synchronous. The Saga pattern
is asynchronous and reactive.

7. So what is a two-phase commit?
As its name hints, 2pc has two phases: A prepare phase and a commit phase. In the prepare phase, all
microservices will be asked to prepare for some data change that could be done atomically. Once all microservices
are prepared, the commit phase will ask all the microservices to make the actual changes.

8. Agenda Style2pcPattern
2pc is a very strong
consistency protocol. First, the
prepare and commit phases
guarantee that the transaction
is atomic. The transaction will
end with either all
microservices returning
successfully or all
microservices have nothing
changed. Secondly, 2pc allows
read-write isolation. This means
the changes on a field are not
visible until the coordinator
commits the changes.
Advantages
While 2pc has solved the
problem, it is not really
recommended for many
microservice-based systems
because 2pc is synchronous
(blocking). The protocol will
need to lock the object that will
be changed before the
transaction completes. This is
not good. In a database
system, transactions tend to
be fast—normally within 50 ms.
However, microservices have
long delays with RPC calls.
Disadvantages

9. The SAGA Pattern
A saga is a sequence of local transactions where each transaction updates data within a single service The first transac
tion is initiated by an external request corresponding to the system operation, and then each subsequent step is triggere
d by the completion of the previous one.
Events/Choreography: When there is no
central coordination, each service produces
and listen to other service’s events and
decides if an action should be taken or not.
Command/Orchestration: when a
coordinator service is responsible for
centralizing the saga’s decision making
and sequencing business logic

10. Events/Choreography
1.Order Service saves a new order, set the state as pe
nding and publish an event called ORDER_CREATED
_EVENT.
2. The Payment Service listens to ORDER_CREATED
_EVENT, charge the client and publish the event
BILLED_ORDER_EVENT.
3. The Stock Service listens to BILLED_ORDER_EVE
NT, update the stock, prepare the products bought in t
he order and publish ORDER_PREPARED_EVENT.
4. Delivery Service listens to ORDER_PREPARED_E
VENT and then pick up and deliver the product. At the
end, it publishes an ORDER_DELIVERED_EVENT
5. Finally, Order Service listens to
ORDER_DELIVERED_EVENT and set the state of th
e order

11. Rolling back in Saga’s Events/Choreography
1.Stock Service produces
PRODUCT_OUT_OF_STOCK_EVE
NT;
2.Both Order Service and Payment S
ervice listen to the previous message:
3.Payment Service refund the client
4.Order Service set the order state
as failed

12. Command/Orchestration
1.Order Service saves a pending order
and asks Order Saga Orchestrator (OS
O) to start a create order transaction.
2.OSO sends an Execute Payment co
mmand to Payment Service, and it repli
es with a Payment Executed message
3.OSO sends a Prepare Order comman
d to Stock Service, and it replies with a
n Order Prepared message
4.OSO sends a Deliver Order comman
d to Delivery Service, and it replies with
an Order Delivered message

13. Rolling back in Saga’s Command/Orchestration
1.Stock Service replies to OSO with an
Out-Of-Stock message;
2. OSO recognizes that the transaction
has failed and starts the rollback
In this case, only a single operation wa
s executed successfully before the failu
re, so OSO sends a Refund Client com
mand to Payment Service and set the o
rder state as failed

14. Agenda StyleSagaPattern
One big advantage of the Saga
pattern is its support for long-
lived transactions. Because
each microservice focuses only
on its own local atomic
transaction, other
microservices are not blocked if
a microservice is running for a
long time. This also allows
transactions to continue waiting
for user input. Also, because all
local transactions are
happening in parallel, there is
no lock on any object.
Advantages
The Saga pattern is difficult to
debug, especially when many
microservices are involved.
Also, the event messages
could become difficult to
maintain if the system gets
complex. Another
disadvantage of the Saga
pattern is it does not have read
isolation. For example, the
customer could see the order
being created, but in the next
second, the order is removed
due to a compensation
transaction.
Disadvantages

15. Message Broker
In its core, a message broker is “a program that
translates a message to a formal messaging
protocol of the sender, to the formal messaging
protocol of the receiver”

16. Which Message Brokers are out there to process my events?
There are tons of message brokers out there (ActiveMQ, Kafka, RabbitMQ, OMS, JMS, Redis
, Service Bus, …) three popular ones
Apache
Kafka
Azure
Event Hub RabbitMQ
RabbitMQ was one of the first open source message
brokers, developed to implement AMQP to work across
different platforms and languages.
Apache Kafka is a Message Broker originally developed by
LinkedIn and open sourced early 2011. It is just like Azure Event
Hub a platform capable of handling millions of events.
Azure Event Hub allows you to set up a scalable Event Hub that suits your
needs in a couple of seconds. It is a PaaS offering by Microsoft Azure, so that
you do not need to manage it, but rather just consume it.

17. Blocking vs. Non-Bloking
Blocking
In traditional MVC applications,
when a request come to server, a
servlet thread is created. It
delegates the request to worker
threads for I/O operations such as
database access etc. During the
time worker threads are busy,
servlet thread (request thread)
remain in waiting status and thus it
is blocked. It is also called
synchronous request processing.
Non-Bloking
All incoming requests come with a event
handler and call back information.
Request thread delegates the incoming
requests to a thread pool (generally
small number of threads) which
delegate the request to it’s handler
function and immediately start
processing other incoming requests
from request thread.
When the handler function is complete,
one of thread from pool collect the
response and pass it to the call back
function.

18. Eclipse Vert.x is event driven and
non blocking. This means your app
can handle a lot of concurrency
using a small number of kernel
threads. Vert.x lets your app scale
with minimal hardware.
Vert.x is incredibly flexible -
whether it's simple network utilities,
sophisticated modern web
applications, HTTP/REST
microservices, high volume event
processing or a full blown back-
end message-bus application,
Vert.x is a great fit.
You can use Vert.x with multiple
languages including Java,
JavaScript, Groovy, Ruby, Ceylon,
Scala and Kotlin.
01
02
03
04
Vert.x
Eclipse Vert.x is a tool-kit for building reactive applications on the JVM.
Polyglot
Scale
Flexible
Vert.x is an ideal choice for
creating light-weight, fast, high-
performance, microservices.
Fast

19. How does it look like?
Vert.x
Spring MVC
As you can see, you add a request handler to
your verticle. Then this handler will be invoked
by the event loop for every request.
After that you filter the requests (e.g. by HttpM
ethod and path) and respond. You also have to
start your HTTP server.
The difference is here that Spring Boot
provides defaults which allow you an easy
start and get fast results. Spring MVC
combined with Spring Boot has a higher
usability and an easier readability in general.
Also, you do not have to understand all that is
going on in the background to create your
Hello World application.

20. Spring WebFlux
Spring WebFlux framework is part of Spring 5 and provides reactive programming support for web applications.
Web
Flux
A non-blocking approach which makes it possible to handle
concurrency with a small number of threads and to scale effectively
Functional programming
Less memory
Availibility to serve traffic
Spring WebFlux is a reactive web framework based on a reactive HTTP
layer; such apps can be deployed on Netty or Undertow (with native
adapters) or Jetty/Tomcat/any Servlet 3.1 container (thanks to a Servlet
3.1 adapter).

21. Agenda Style
Servletvs.Reactive
5000Users
Spring-boot
web 2.0
Spring-boot
reactive web 2.0

22. Agenda Style
Servletvs.Reactive
10000Users
Spring-boot
web 2.0
Spring-boot
reactive web 2.0

23. Thank you
Betül Çetinkaya