Reactive - Is it really a Magic Pill?

Nov 2019
Reactive Architecture
Is it a Magic Pill ?

Agenda
03
04
05
01 Introduction to Reactive
Systems
01
02 Reactive Principles ?
03 Reactive Microservices
04 CQRS and Event Sourcing
0405 Key Considerations

Base Concept
Lorem Ipsum comes from section Contrary to
popular belief, Lorem Ipsum is not simply random
text.
If you cannot solve a problem without
programming, you cannot solve a problem with
programming.
Victor Klang

text.

Overview
text.
In this talk we will explore the domain of the Reactive
Applications.
● Domain Driven Design (DDD) to model the domain.
● How our domain can be partitioned into Reactive Microservices.
● Discuss concerns around scalability, consistency, and availability
● Analyze different messaging patterns.
● Command Query Responsibility Segregation and how it can be
combined with Event Sourcing.

Introduction to
Reactive Systems

The problem
text.
The software landscape has undergone remarkable change
● Earlier
○ Tens of nodes
○ GB’s of data (often at rest)
○ Long maintenance windows
● Now
○ Hundreds and thousands of nodes
○ PB’s of data (often streaming)
○ Almost 100% uptime

User Expectations
text.
User expectations are huge from software today
● Modern users rely on software to do critical jobs - cannot
expect downtime.
● Software is expected to respond immediately
● Unresponsive software leads to dissatisfaction - users would
find a better software

Discussion
Unresponsive Software
text.
Have you encountered an unresponsive software?
● What was your reaction?
● Did you reconsider the use of software?
● Did it change your impression about the company that built it?
● What did you do to overcome the challenge?

Goal
of Reactive Architecture
text.
To build software
● Which scales from 10 to 10M users
● Consumes resources relevant for the current load only
● Gracefully handles failures
● Can we easily distributed across nodes, geographies
● Can give consistent level of quality irrespective of the load and
stress on the system

Responsive
Most Important Reactive Principle
text.
A responsive system is quick to react to all users —
under blue skies and grey skies — in order to ensure a
consistently positive user experience.

Resilience
Reactive Principle
text.
A resilient system applies proper design and
architecture principles in order to ensure
responsiveness under grey skies as well as blue.

Elastic
Reactive Principle
text.
A scalable system is easily upgraded on demand in
order to ensure responsiveness under various load
conditions.

Message Driven
Reactive Principle
text.
A message-driven architecture is the foundation of
Reactive applications. A message-driven application
may be event-driven, actor-based, or a combination of
the two.

Discussion
Responsive Software
text.
Have you encountered a Responsive software?
● What was your reaction and impression?
● Do you think it was using reactive principles?
● Did it change your impression about the company that
built it?
● Have you built a reactive software?
○ What benefits did you achieve?

Reactive Programming and Systems
● Reactive systems apply reactive
principals to the architecture
● Reactive programming are
languages which support
building reactive systems like
Futures, Promises, Async
communication, streams etc

Summary
● Responsive and Unresponsive software
● Reactive Manifesto and Principles
○ Responsive
○ Resilient
○ Elastic
○ Message Driven
● Reactive programming and systems

Monoliths
● The ball of mud represents the worst case
scenario for a Monolith.
● No clear isolation in the application.
● Complex dependencies.
● Hard to understand and harder to modify.

● Deployed as a single unit.
● Single shared database.
● Communicate with synchronous method calls.
● Deep coupling between libraries and components (often
through the DB).
● "Big Bang" style releases.
● Long cycle times (weeks to months).
● Teams carefully synchronize features and releases.
Characteristics of a monolith

Scaling a Monolith
● Multiple copies of the monolith are deployed.
● Each copy is independent. They don't
communicate with each other.
● The database provides consistency between
deployed instances.

● Easy Cross Module Refactoring.
● Easier to maintain consistency.
● Single deployment process.
● Single thing to monitor.
● Simple scalability model.
Advantages

● Limited by the maximum size of a single physical machine.
● Only scales as far as the database will allow.
● Components must be scaled as a group.
● Deep coupling leads to inflexibility.
● Development is typically slow (change is difficult, build times long).
● Serious failures in one component often bring down the whole
● monolith.
● Redistribution of load can cause cascading failures.
Disadvantages

Next step - SOA
● We can isolate our Monolith using Service
Oriented Architecture.
● Services don't share a database.
● All access must go through the API exposed by
the service.
● Services may live in the same process (monolith)
or separate (microservices).

Microservices
● Microservices are a subset of SOA.
● Logical components are separated into isolated
microservices.
● Microservices can be physically separated and
independently deployed.
● Each component/microservice has its own
independent data store.
● Microservices are independent and self
governing.

Event Sourcing in Real Life
How we used to do it

Once Upon a Time

Scaling Up..

Let's Improve - Go Asynchronous .

Command Vs Event
Command Results in an Event
Results

Command to Event
Journey of Command to Event

Event Sourcing
Journey of Command to Event

Old Wine in New Improved Bottle
What About Reads

Backward Compatibility in Events

A class should have only one reason to change.
Robert C. Martin
● The Single Responsibility Principle applies to object oriented classes,
but works for Microservices as well.
● A microservice should have a single responsibility (eg. managing
accounts).
● A change to the internals of one microservice should not necessitate
a change to another microservice.
SRP

● Bounded Contexts are a good place to start building microservices.
● They define a context in which a specific model applies.
● Further subdivision of the Bounded Context is possible.
Bounded Context

● Scalability: A system is scalable if it can meet increases in demand
while remaining responsive.
● Consistency: A system is consistent if all members of a system have
the same view or state.
● Availability: A system is available if it remains responsive despite
failures.
Deﬁnitions

● Isolation provides reduced coupling and increased scalability.
● Reactive Microservices are isolated in:
○ State
○ Space
○ Time
○ Failure
Principles of Isolation

Isolation of State
● All access to a Microservice state
must go through its API.
● No backdoor access via the
database.
● Allows the microservice to evolve
internally without affecting the
outside.

Isolation of Space
● Microservices should not care
where other microservices are
deployed.
● It should be possible to move a
microservice to another machine,
possibly in a different data center
without issue.
● Allows the microservice to be scaled
up/down to meet demand.

Isolation in Time
● Microservices should not wait for each other.
Requests are asynchronous and non-blocking.
○ More efficient use of resources.
Resources can be freed immediately,
rather than waiting for a request to finish.
● Between microservices we expect eventual
consistency.
○ Provides increased scalability. Total
consistency requires central coordination
which limits scalability (more on this
later).

Isolation of Failure
● Reactive Microservices also isolate
failure.
● A failure in one Microservice should
not cause another to fail.
● Allows the system to remain
operational in spite of failure.

Discussion
General rules
Two trees fall in the forest. Two people hear the sound. Both trees fall at the
same time.
Each person is closer to a different tree. Sound travels at 340 m/s.
● If we were to ask Martin and Grace what time each tree fell at, would they give
us the same answer?
● If we were to ask Martin and Grace which tree fell first, would they give us the
same answer?

● Distributed Systems are systems that are separated by space.
● Physics puts an upper limit on information speed (The Speed of Light)
● When two systems are separated by space, there is always time
required to reach consensus.
● In the time it takes to transfer the information, the state of the
original sender may have changed.
Problem with distributed systems

● Because it takes time to transfer information, the information being
received is always stale.
● This applies whether we are talking about Computer systems,
people, or even just the physical world.
● Reality is therefore Eventually Consistent
Reality is eventual

Eventual Consistency
Eventual consistency guarantees that, in the
absence of new updates, all accesses to a specific
piece of data will eventually return the most recent
value.

Strong Consistency
An update to a piece of data needs agreement
from all nodes before it becomes visible.

Strong Consistency
● Traditional architectures were built for
Strong Consistency.
● Physics prevents Strong Consistency, so
instead we simulate it.
● Locks and Transactions allow us to simulate
Strong Consistency.
● The distributed problem is isolated it to a
non-distributed resource.
● These techniques introduce overhead in the
form of contention.

● Any two things that contend for a single limited resource are in
competition.
● This competition can only have one winner.
● Others are forced to wait for the winner to complete.
● As the number of things competing increases, the time to free up the
● resource increases.
● As load increases we will eventually exceed acceptable time limits.
Contention

Discussion
General rules
Two people are collaborating on code. Strong Consistency will require that Martin
and Grace both have the exact same view of the code at all times.
A model based on locks will require Martin to lock the code when he wants to edit
it.
● How will the need for Strong Consistency affect Grace's workflow if she also
wants to edit the code?
● How do source control tools actually achieve consistency?

● Reactive Systems put an emphasis on asynchronous, non-blocking
messages.
● Messages are sent without waiting for a response.
● The sender may be interested in a response, but it comes
asynchronously.
● Is there a place in a Reactive System for Synchronous Messaging?
Messaging in Reactive Systems

● Async messages form the backbone of Reactive Systems, but
sometimes synchronous make more sense.
● Synchronous requirements can often be relaxed. In most scenarios
asynchronous messaging just works fine
● Can you acknowledge the receipt of a message synchronously, but
process it asynchronously?
Synchronous Messaging

● The need for synchronous messages should be driven by domain
requirements rather than technical ones.
● Best Practice: Use asynchronous by default, fallback to synchronous
only when forced.
● Understand the consequences of the choice.
Synchronous Messaging

● In a monolithic architecture, coordination and consensus building is
often done using transactions.
● Microservices, Distributed Systems, and Async Messages all make
transactions more difficult.
● Holding transactions open for long periods results in slow, brittle
systems.
● How can we manage long running transactions that span multiple
microservices?
Cost of Async Messaging

Sagas
● The Saga Pattern is a way of representing a long running
transaction.
● Multiple requests are managed by a Saga.
● Individual requests are run in sequence or in parallel.
● When all requests complete, the Saga is complete.
● What happens when a request fails?

Failure In Sagas
● Each request is paired with a compensating action.
● If any request fails, compensating actions are executed for all
completed steps.
● The Saga is then completed with a failure.
● If a compensating action fails, then it is retried. This requires
idempotence.

Timeout in Distributed System

Timeout in Distributed System
● In a Distributed System, timeouts present a difficult problem.
● A request timeout presents us with at least 3 possible scenarios.
○ The request failed.
○ The request succeeded, but the reply failed.
○ The request is still queued and may succeed (or fail)
eventually.
● Because the request may have succeeded, we need to run the
compensating action.
● The request may still be queued, therefore the compensating
action may complete first..

● Compensating actions are different from rollbacks.
● Rollback:
○ Implies the transaction has not completed.
○ Removes evidence of the transaction.
● Compensation:
○ Applied on top of a previously completed action.
○ Evidence of the original action remains.
Compensating and Rollback are
different

Reactive - Is it really a Magic Pill?

Recommended

Recommended

More Related Content

Similar to Reactive - Is it really a Magic Pill?

Similar to Reactive - Is it really a Magic Pill? (20)

More from Tech Triveni

More from Tech Triveni (20)

Recently uploaded

Recently uploaded (20)

Reactive - Is it really a Magic Pill?