►
Description
Presented by Utkarsh Sharma at the May 20, 2022 Ortelius Visionaries Summit.
In this lighting talk, we will share famous design patterns that are widely used. We will cover design patterns used during the decomposition of monoliths and those that are used to ensure data consistency across microservices. These design patterns are developed to solve traditional problems faced with microservice architecture. Building your solution on top of these patterns provides resilience, tolerance, and consistency to your application.
A
Hi
everyone
good
morning,
good
afternoon,
good
evening
to
people
from
different
parts
of
the
world,
welcome
everyone
to
artelia's
visionaries
2022.
My
name
is
kirsh
and
for
the
next
10
minutes,
we'll
be
discussing
few
of
the
famous
design
patterns
that
might
help
you
in
designing
your
micro
service
based
applications.
A
So
if
you're
developing
micro
service
applications,
so
rtls
is
your
friend
artelis
is
basically
a
microservice
cataloging
tool
that
that
not
only
cracks
your
different
components,
different
microservices,
but
also
consulted
a
lot
of
useful
information
like
what
version
is
deployed.
What
is
the
stable
version?
A
A
Few
words
about
myself,
I'm
a
software
engineer
at
cisco,
india.
I
like
to
create
a
lot
of
services
using
different
cloud
platforms,
let
it
be
like
azure
or
gcp,
and
I
also
like
to
contribute
to
the
open
source
community.
I
like
collaborating
and
working
with
passionate
developers.
That
is
where
I
join
rtls
and
if
you
are
looking
for
the
same
hotel
is
the
best
release.
A
These
are
the
content
that
we'll
be
looking
at
in
the
next
10
minutes,
we'll
see
how
we
can
migrate
the
monolith
to
your
microsoft,
based
architecture,
we'll
for
that
we'll
look
at
decomposition
patterns
to
manage
data
in
a
distributed
ecosystem.
We'll
look
at
three
of
the
design
patterns
like
sagar
design
patterns,
cqrs
design
pattern,
and
apart
from
that,
we'll
look
at
few
of
the
reliabilities
standpoint.
A
Okay,
starting
with
decomposition,
so
since
we
already
know
there
are
huge
chunk
of
application
already
built
on
monolith
and
a
lot
of
jobs,
are
there
where
there
they
ask
you
to
migrate
or
migrate
their
application
to
a
microservice
based
application
so
like?
If
you're
asked
to
you,
know,
migrate
or
convert
a
monolith
based
application
or
if
not
monolith-based
application.
A
You
are
asked
to
convert
a
soa
architecture
based
application.
So
how
would
you
you
know?
How
would
you
what
will
be
your
thing
process
thought
process?
So
what
we
can
do?
We
can
either
decompose
our
application
based
on
the
business
capability
that
has
or
what
we
can
do.
We
can
decompose
our
application
based
on
the
subdomains,
so
just
to
add
little
more
details,
so
decomposition
by
business
capabilities
means
identifying
the
different
layers
of
your
applications
that
are
responsible
for
different.
A
A
So
we
we
use
domain-driven
design
to
create
a
microservices
so
that
that
has
like.
You
need
a
lot
of
understanding
of
the
product
itself,
because
you
have
to
identify
like
which
components
you
can.
You
know
segregate
into
one
component,
and
so
let
me
show
you
some
figures:
okay,
so,
as
you
can
see
decomposed
by
business
capabilities,
so
it
is
fairly
straightforward.
A
So,
in
most
of
the
cases
I
have
seen
in
the
application
itself,
they
have
a
layered
kind
of
architecture,
so
they
will
have
like
a
work,
management,
user
management,
tenant
management
and
data
management
layers,
but
that
is
developed
as
a
micro
monolith
or
soa.
So
what
we
can
do,
we
can
identify
those
and
we
can
isolate
them
and
create
a
different
service
and
standard
service
and
deploy
them
as
a
microservice,
while
in
decomposed
by
subdomain.
A
We
have
to
identify
like
like
if
this
service,
if
this
api
would
go
into
a
product,
catalog
surveys
or
or
that
you
know,
service
should
reside
in
delivery
service
or
something
so
these
kind
of
challenges
are
there.
So
that
takes
like,
like
a
lot
of
do
and
from
meetings
with
different
folks
to
identify
that.
A
Apart
from
that,
there
are
few
few
of
the
other
design
patterns
that
we
see
nowadays,
so
nowadays,
what
we
see
so
we
identify
like
what
all
services
can
be.
You
know
self-contained
into
one
service,
so
that
is
one
design
pattern
that
you
can
use
the
other
one
is
if
you
are
creating
your
application
from
scratch,
so
I
have
seen
like
a
lot
of
people.
They
create
a
different
team
as
per
services,
so
there
will
be
one
team
that
will
be
only
concerned
with
the
data
call
them.
A
A
So
there
are.
There
is
a
famous
design
button
to
solve
this
distributed
transaction
problem
in
microservice.
That
is
called
saga
design
button,
and
we
can,
you
know,
tweak
the
saga
design
pattern
in,
like
whatever
space
suits
you,
but
the
overall.
The
base
architecture
will
be
very
similar
to
this.
So
first,
there
are
like
two
approaches
to
saga.
One
of
them
is
choreography
based
approach,
so
in
choreography
based
approach,
your
request
will
be
propagated
to
the
to
the
different
services
and
they
will
be
again
propagated
in
the
reverse
order.
A
So
let's
say:
if
you
have
like
three
services,
a
b
and
c-
and
you
call
you-
make
a
call
to
service
a
then
the
service
a
will,
do
a
call
to
b,
and
that
b
will
call
service
of
c
and
then
c
will
return
something,
and
then
we
will
return
something
based
on
the
output
that
he
has
got
from
the
c.
So
this
this
kind
of
approach
is
called
choreography
based
approach.
So
in
that
case,
let's
suppose
at
any
point
of
time
your
service
has
failed,
so
the
ultimate
output
would
be
field
itself.
A
The
second
approach
is
orchestration
based,
so
in
that
case,
what
we,
what
we
do,
we
create
an
orchestration
layer
that
is
responsible
for
org
stating
so
that
will
be,
you
know,
orchestrating
different
threads
and,
let's
suppose,
let's
see
this
diagram.
So
if
you
want
to
create
an
order,
so
what
you
need?
You
need
some
customer
information.
A
You
need
like
payment
information
or
even
you
need
inventory
information
that
the
product
is
available
or
not.
So
there
we
have
like
orchestration,
which
will
post
a
event.
So
here
we
have
used
a
message
broker,
so
it
is
posting
even
to
you
know,
which
will
be
consumed
eventually
by
customer
service
and
customer
service
based
on
that
event
will
return
some
other
event
to
the
other
topic,
which
is
a
reply
channel
on
the
reply
channel
and
this
create
order.
A
Module
will
consume
that
event
and
based
on
the
event
that
he
has
consumed
and
he
will
identify
if
he
has
to
create
order
or
not.
So,
let's
suppose
there
if
he
has
got
a
success
from
a
customer.
Okay.
So
at
the
later
point
of
time
there
will
be
another
module
that
will
be
so.
The
orchestrator
will
again
always
state
a
method
to
the
to
a
different
topic,
which
is,
let's
say,
a
payment
module,
and
let's
say
at
that
time,
the
payment
got
paid.
A
So
if
the
payment
got
failed,
the
eventually
the
output
would
be
the
even
chill.
The
ultimate
response
would
be
a
fail
in
that
case.
So
this
is
how
we
maintain
the
orchestration
layer
and
in
some
cases
we
also
create
a
additional
layer
which
is
called
a
state
machine
so
which,
which
has
like,
which
maintains
the
state
for
every
request.
So
every
so,
let's
say
if
you
want
to
create
a
order,
so
order
can
have
like
that
order.
Can
you
know
generate
a
different
methods,
different?
A
Okay,
so
there
is
another
design
pattern
that
you
can
use,
alternatively,
to
stacker
design
pattern
which
is
called
cqrs.
So
what
problem
we're
solving
here
in
the
cqrs
is:
let's
suppose
you
want
to
you
know
you
want
to
implement
a
query
that
received
data
from
multiple
services,
so
we
know
like
if
there
are
four
services
and
if
you
are
making
a
four
db
calls
that
will
be
very
much
expensive
because
if
you
are
developing
a
large
scale,
applications
that
will
be
converted
to
thousands
of
millions.
A
A
A
Okay,
coming
to
the
reliability
of
perspective,
so,
let's
suppose
you're
writing
a
code.
Okay.
So
what
happens
if,
at
some
point,
the
other
service
is
not
available,
or
let's
say
if
there
is
a
service,
a
which
has
to
publish
an
event
to
service
b
and
service
b
is
not
available.
So
at
that
point
of
time
what
should
be
the
flow
of
the
execution?
A
A
A
Let's
say
error
topic,
so
you
can,
you
know,
push
those
events
into
into
those
cues
or
let's
say,
if
you're
not
able
to
make
connection
so
service
b
is
down
so
you're
not
able
to
consume
services
that
are
written
in
b,
my
back-end
service.
So
in
that
case
you
can
write
a
fallback
scenario
that
will
return
some
generic
response
so
and
you
can
also
maintain
some
kind
of
record
record
for
that
and
you
can
process
that
afterwards.
A
So
in
that
case,
whenever
we
identify
like
there
are
some
services
which
are
not
responding
so
on
this
second
record,
the
implementation
that
we
write
will
be
will
be
set
on
and
in
that
cases,
whatever
request
it
will
receive
in
that
point
of
time
will
be
handled
by
a
fallback
scenario.
The
fallback
method
that
you
that
you
write
and
after
after
you
know
a
certain
point
of
time.
A
Let's
say
if
you
have
behind
some
time
off
for
the
circuit
breakers
after
that
timeout
that
circuit
breaker
will
will
be
off
and
then
again
it
will.
You
know
take
a
few
requests
and
see
if,
if
you
know
your
application
is
able
to
consume
the
services
of
the
other,
if
not,
then
it
will
again
go
to
the
onstate
and
all
the
requests
will
be
handled
by
fallback.