►
From YouTube: Compatibility and Pitfalls of Architectural Patterns with Blockchain Use-Cases - Arnab Chatterjee
Description
Compatibility and Pitfalls of Architectural Patterns with Blockchain Use-Cases - Arnab Chatterjee, BOSCH
As blockchain implementations progress towards production-grade implementations, we reflect upon the most common Architectural design patterns that do and does not fit well with Blockchain use-cases. The design of popular Blockchain platforms like Hyperledger Fabric and Hyperledger Besu prompts the choice of some natural Architectural Design patterns to be incorporated into the application's architecture. An example is the Event Sourcing with CQRS because of the limited querying capability of Blockchains. On the other hand, one has to be aware of some Patterns' pitfalls with Blockchain use-cases. Using SOA or Microservice architecture require synchronization between services to send transactions to the ledger - due to race conditions in Fabric. This talk focuses on Architectural Patterns, pitfalls, trade-offs, compatibility in the context of Blockchain dApps.
Sessions Details & Slides (if available)- https://sched.co/jcq1
Access All Sessions: https://events.linuxfoundation.org/hyperledger-global-forum/program/schedule/
----
Hyperledger – Open Source Blockchain Technologies
Hyperledger is an open source community focused on developing a suite of stable frameworks, tools and libraries for enterprise-grade blockchain deployments.
It serves as a neutral home for various distributed ledger frameworks including Hyperledger Besu, Fabric, Sawtooth, Indy, as well as tools like Hyperledger Avalon, Cactus and libraries like Hyperledger Aries, Ursa. Learn more about Hyperledger projects: https://www.hyperledger.org/use
Case Studies: https://www.hyperledger.org/learn/case-studies
Training & Certification: https://www.hyperledger.org/learn/training
Tutorials: https://www.hyperledger.org/use/tutorials
Webinars: https://www.hyperledger.org/learn/webinars
Events: https://www.hyperledger.org/events
Vendor Directory: https://www.hyperledger.org/use/vendor-directory
Subscribe to the Hyperledger Newsletter: https://www.hyperledger.org/newsletter
Follow-us on Twitter @Hyperledger
Learn about Hyperledger Membership: https://www.hyperledger.org/about/join
#Hyperledger #HyperledgerGlobalForum2021 #Blockchain
A
Good
day,
everyone
hope
you
are
enjoying
the
hyperledger
global
forum
event.
So
far.
My
name
is
arnab
chatterjee
and
I'm
going
to
present
compatibility
and
pitfalls
of
architectural
patents
with
blockchain
use
cases.
So
there's
a
poll
for
your
information
in
the
beside
the
chat
window,
please
feel
free
to
share
your
responses
over
there.
A
So
let
me
introduce
myself.
I
am
a
technical
lead
currently
associated
with
r3,
and
I
was
previously
associated
with
organizations
like
bosch
and
nec
corporation,
where
I
gathered
experience
for
the
last
eight
years
in
building
enterprise
applications
out
of
that
the
last
five
years
in
designing
and
architecting
blockchain
applications.
A
I
am
the
co-author
of
multiple
research
papers
on
architecting
blockchain
systems
in
production,
and
I
also
represent
india
on
behalf
of
the
national
body
of
standards,
the
bureau
of
indian
standards
at
iso
t3307,
the
global
blockchain
and
dlt
standards.
I'm
a
committee
member
there
and
I
contribute
towards
identity
and
privacy
standards
of
late.
I
have
been
also
contributing
to
the
hyperledger
tooling
project,
which
is
a
new
edition,
and
this
project
aims
to
help
the
newcomers
start
their
open
source
contribution
towards
hyperledger
projects.
So
you
can
visit
this
url
and
check
it
out.
A
A
A
Let
me
emphasize
that
we
will
be
focusing
our
discussion
mostly
on
these
blockchain
platforms,
that
is
hyperledger
fabric
and
enterprise
ethereum
and
enterprise
ethereum,
encompassing
the
hyperledger,
baso
and
korum
kind
of
projects.
So
throughout
the
presentation
I
will
be
using
it
or
ethereum
for
brevity
and
please
feel
free
to
ask
any
questions
and
and
put
the
put
the
questions
in
the
q
a
box
right
I'll,
try
to
answer
them
towards
the
end
of
the
presentation.
A
So,
let's
get
started
so
why
this
presentation,
so
blockchain
platforms
has
been
in
constant
flux,
bug
features,
feats
bug,
fixes
features,
are
these
are
constantly
making
their
way
into
new
blockchain
platform
releases
and
our
experience
in
building
production
grade
enterprise
blockchain
applications
is
pretty
vast,
but
when
we,
when
we
compare
it
with
you
know,
building
blockchain
production
grade
applications
it.
It
has
been
quite
limited.
A
I
mean
like
comparing
it
to
the
to
the
performer,
so
the
developer,
fraternity
is
still,
you
know,
figuring
things
out
like
how
how
they
are
going
to
go
about
things
and
these
things
as
I'm
calling
it.
They
manifest
themselves,
as,
as
you
know,
technical
constraints
right.
So
there
are
a
lot
of
these
technical
constraints
that
make
our
way
into
it
into
into
our
design
and-
and
we
have
to
you-
have
to
be
aware
of
that.
So
so
what
is
our
way
out
like?
A
How
can
we,
you
know,
navigate
our
way
through
with
the
constant
flux
of
blockchain
platforms?
Platforms,
evolving,
and
you
know
we
have
to
design
our
application.
So,
first,
as
I
see
it
is
awareness
of
these,
you
know
architectural
patterns
or
patterns,
as
I
call
it,
knowing
the
constraints
more
in
detail
and
specific,
specifically
what
architectural
patterns
work
and
what
architectural
patterns
don't
work
with
blockchain
platforms,
so
this
will
be
basically
the
first
part
of
the
presentation.
A
So
so
we
can
basically
protect
our
application
by
adopting
the
evolutionary
style
of
building
architectures
with
blockchain.
So,
let's
get
you
know
started
with
some
of
the
patterns.
So
the
first
pattern
that
we
are
going
to
look
at
is
the
good
old,
layered
monolith
architecture,
so
in
its
very
basic
form,
it
has
these
three
layers,
so
it
has
the
presentation,
business
and
the
persistence
layer
and
the
persistence
layer
is
basically
talking
to
your
blockchain
through
these
sdks
or
libraries,
as
we
call
it
right
and
the
the
it
is.
A
It
is
worth
noting
that
this
this
communication
pattern
between
this,
this
persistence
and
the
blockchain
that
is
typically
synchronous
in
nature.
That
means
it's,
it
waits
until
the
processing
is
not
complete,
so
it
is.
It
is
easy
on
time
and
budget,
and
it's
it's
a
great
fit
for
proof
of
concept,
implementations
and,
and
it's
good
for
people
looking
out
to
not
test
out
blockchain.
However,
it
is,
it
is
not
scalable
immediately
and
it's
almost
throw
away
most
of
the
times
if
we
do
not
design
our
business
logic
properly.
A
If
you
do
not
decouple
the
business
logic
properly,
so
you
need
to
develop
some
sort
of
abstractions
on
the
business
logic
so
that
you
want
to
use
the
business
logic
later.
So
this
is
the
first
pattern.
The
second
is
the
event
driven
architecture
or
eda
for
short
right
here,
the
the
unlike
the
synchronous
messaging
pattern.
A
So
it
can
be
either
ways
right,
so
eda
basically
comprises
of
an
initiating
event
that
we
just
saw,
which
is
get
which
gets
registered
in
a
message
broker
one
or
more
consumers,
or
you
know,
message,
processors,
processes,
these
events
and
finally,
the
the
processing
event.
The
response
event
is
sent
back
to
the
user.
So
if
we
just
relate
this
to
to
the
blockchain
kind
of
the
architecture,
the
user
request
is
basically
the
initiating
event
and
the
contract
event
is
the
processing
event,
which
is
the
response
event.
A
A
Consistency
concern
that
you
know
how
can
you
ensure
that
the
option
is
always
consistent
with
the
on-chain
state
right,
so
we
can
ensure
that
the
state
of
the
option
is
only
updated
as
per
the
sequence
of
the
contract
events
that
we
are
emitting
so
contract
events
in
some
way
represent
the
right
ahead
log
that
we
had
for
databases
right
now
talking
about
concurrency.
There
is
a
very
high
degree
of
concurrency
as
well
in
eda
kind
of
an
architecture,
so
ledger
image.
Specific
events
like
you
know
my
transaction
is
send.
My
transaction
is
mine.
A
The
contract
event
is
emitted.
So
with
these
granular
events,
it's
very
easy
to
concur.
It's
easy
to
model.
You
know,
concurrent
application
so
which
also
in
turn
becomes
very
performant
in
nature,
right
and
and
finally,
the
events
also
acts
as
natural
extensibility
points.
Additional
logic
can
be
hooked
up
to
the
events
in
the
future
that
enable
high
degree
of
coupling
a
high
degree
of
extensibility
to
the
system
right.
A
Moving
on
to
the
pitfalls
for
eda,
the
first
is
basically
to
decide
the
purpose
of
the
contract
events.
So
this
is
very
important
which
I'm
going
to
discuss
in
the
subsequent
slides,
but
the
purpose
can
be
you
know
either
of
the
two
either
it
is
acting
as
a
state
change
carrier
or
it
is
acting
as
a
state
change,
notification,
carrier
right
and
so
we'll
we'll
move
on
temporarily
so
to
to
capture
these.
You
know
events
eda
kind
of
requires
some
sort
of
event
streaming
logic.
A
A
Now
moving
on
to
a
very
interesting
pattern,
which
is
not
an
architectural
pattern,
that
is
the
even
sourcing
pattern,
which
is
a
storage
pattern
right.
So
even
sourcing
pattern
advocates
the
storage
of
storing
the
intermediate
history
of
events
like
facts,
along
with
the
current
state
of
the
system.
So
this
way
one
can
go
back
to
the
past
state
by
replaying
the
events
right.
A
So
this
sounds
familiar
right
because
blockchain
is
a
natural
implementations
of
this
right,
so
transaction
act
as
state
change,
careers
to
the
blockchain
and
once
the
transactions
are
executed
on
the
smart
contract,
the
smart
contract
emit
this
contract
events,
which
then
act
as
state
change
carriers
for
updating
the
off
chain
storage
right.
So
this
creates
a
natural
event,
sourcing
kind
of
a
pattern.
A
So,
in
this
diagram,
every
actor
is
holding
a
database
on
their
own
which
which
they
use
for
reading,
and
they
they
send
transactions
to
the
to
the
ledger
and
the
ledger
emits
event
after
processing
the
transaction
and
each
actor
is
notif
events
and
they
update
their
database
accordingly
right
without
making
any
any
additional
calls
to
the
to
the
to
the
ledger.
So
this
enables
off
chain
segregation,
an
offshoring
state
representation
and-
and
this
basically
creates
something
like
a
cqrs
or
command
query
responsibility.
Segregation
as
we
call
it
right.
A
So,
let's
so
so,
why
should
we
be
concerned
about
the
purpose
of
the
event
that
I
was
mentioning
right?
So
in
the
first
case,
we
can
see
that
the
usage
is
basically
basically
of
maintaining
a
simple
user
balance,
so
you
have
an
address
and
you
have
a
balance
of
the
user
on
the
ledger
right.
So
the
complete
information
about
the
state
change-
that
is
the
balance
update
through
the
deposit
or
withdraw
kind
of
events,
is
handled
by
the
by
the
events
themselves.
A
So
you
do
not
need
to
go
to
the
ledger
to
explicitly
query.
So
these
are
basically
your
fat
events
as
we
call
it.
The
second
use
case
is
basically
of
registering
users
on
the
system
right.
Naturally,
there
might
be
more
data
about
the
users
on
the
ledger
and
piggybacking
all
of
these
data
as
parameters
on
the
contract.
Even
data
is
not
basically
practical.
So
it's
it's
practical,
however,
to
use
these
events
as
notifications
to
services
off
chain,
but
you
know
in
this
case
the
slim.
A
The
slim
events
basically
act
as
state
change
notifiers
using
the
fat
events
it.
It
is
actually
easy
to
construct
the
off
chain
state,
because
you
know
you
don't
need
to
go
to
the
ledger
again
to
query,
but
I
must
also
say
that
it
is
also
possible
to
to
update
the
off
chain
state
just
by
looking
at
these.
You
know,
slim
events,
but
there
are
certain
caveats
to
it.
Right,
like
you
have
to
be
very
careful
that
you
know,
no
other
party
is
actually
updating
the
state
of
the
ledger.
A
You
know,
while
you
are
going
to
make
an
explicit
call,
and
even
if
it
is
updated
right,
some
ledgers
like
fabric
allows
us
to
read
the
history
state,
but
we
have
to
be
careful
that
you
know
not
all
ledgers.
Allow
you
to
do
this
like
for
specifically
for
each
type
of
ledgers.
It's
it's
not
possible
here.
A
So
this,
basically,
you
know,
doubles
up
the
the
ledger
is
basically
doubling
up,
as
your
state
change
event
store
right,
you're,
you're,
storing
the
all
the
state
changes
through
through
these
events
through
these
contract
events-
and
it's
it's
there
for
all
the
actors
right
coupled
along
with
their
respective
databases,
which
allows
them
to
read
data
conveniently
from
the
off-chain
storage
right.
They
do
not
have
to
go
to
the
on-chain
storage.
This
pattern
is
very
powerful
because
it
allows
seamless
querying
for
each
of
these
actors
on
their
respective
databases
and
they
can
use
that
existing.
A
You
know
known
languages
like
sql
or
any
any.
You
know
nosql
kind
of
languages
to
query
data
and
they
do
not
have
to
go
through
multiple
data
sources
like
the
ledger,
the
private
data
collection,
which
basically
adds
to
your
performance
lag
when
you're
querying
the
system
right.
So
this
is
also
powerful
pattern.
Some
things
to
watch
out
for
here
is
that
a
lot
of
people,
including
me
at
some
point
of
time.
In
the
past,
we
confused
even
sourcing
with
the
event-driven
architecture.
A
So
even
sourcing
is
basically
a
storage
pattern,
but
even
driven
architecture
is
an
architectural
pattern
right,
defining
the
structure
of
the
system
and
its
components,
and
and
finally,
we
have
to
be
aware
that
these
history
querying
capabilities
that
I
was
mentioning
about-
it's
not
there
for
all
ledgers.
It's
only
there
for
certain
ledgers
like
fabric
right,
okay,
the
next
is
one
of
my
favorites,
which
is
basically
the
microkernel
architecture.
A
The
motivation
of
using
micro
kernel
architecture
comes
from
you
know
the
immutable
and
sensitive
nature
of
smart
contracts
that
once
smart
contracts
are
deployed,
it's
challenging
to
make
changes
and
also
the
fact
that
contracts
are
very
expensive
to
build
and
require
very
hard
too
much
of
hard
work
to
audit,
and
you
know,
get
things
in
place
before
they're
finally
deployed
on
the
ledger.
So
we
can
apply
micro
control
architecture
to
this
to
the
core
contract.
A
A
Some
of
the
areas
to
watch
out
for
in
general
is
that
how
how
these
vanilla
contracts
are
designed
and
deployed.
The
ap
design
of
these
vanilla
contracts
are
quite
challenging
and
can
be
difficult
to
get
right
at
at
first,
and
also
you
know,
we
have
to
be
aware
of
these
special
ledger.
Considerations
like
how
fabric
allows
cross
chain
code
calls
like
one
can
only
do
cross
chain
code,
calls
in
the
same
channel
and
and
then
you
can.
A
You
know
you
can
write
using
doing
cross
chain
code
channels
in
the
same
channel,
but
when,
when
it
goes
to
different
channels,
you
can
just
read
when
you
do
cross
chain
code
calls.
So
this
is
another
thing
to
watch
out
for
next
up
is
service
based
architecture
or
sba
or
soa,
as
we
also
known
call
it
a
service,
oriented
architecture,
so
service
oriented
architecture
divides
the
entire
application
into
services
based
on
the
domain
right
and
and
service
oriented
architectures
typically
have
around.
A
You
know:
seven
to
12
services
that
share
a
common
persistence
mechanism
like
a
database
or
blockchain
in
this
case
right,
so
the
the
based
based
on
this
scalability
and
the
performance
needs
of
service
oriented
architecture.
We
can
basically
scale
up
of
these
services.
You
know
for
for
better
performance,
load,
balancing
and
fault
tolerance
right.
A
So
when
we
use
service
oriented
architecture
in
blockchain,
then
in
an
architecture
like
this
specifically
concurrency
issues
are
so,
for
example,
fabric
which
does
not
allow
modifying
the
same
key
in
the
read
write
set
in
two
or
more
transactions
in
the
same
block
right,
then
you
need
to
coordinate
right.
It's
it's
basically
called
the
mvcc
multiversion,
concurrency
control,
check
and
and
again
in
ethereum.
You
have
these
problems
of
nonsense.
Not
right.
A
As
I
was
telling
about
right
like
avoiding
the
mvcc
conflicts
or
the
nonce
requirements,
it
also
removes
the
need
for
e-service
to
know
about.
You
know:
blockchain
network
specifics,
like
you
know
the
node
information
which
peers
should
I
send
a
transaction,
the
signing
mechanism,
the
contract
information
and
all
of
that
stuff.
A
On
the
other
hand,
the
orchestrator
also
does
some
good
job
in
you
know
planning
the
concurrency
of
the
system
like
it
can
group
and
segregate
transactions.
You
know
that
are
independent
of
each
other,
and
then
they
it
can.
You
know
plan
this
transaction
executions
in
a
very
nice
way,
so
you
can
get
nice
nice
guarantees
over
here.
So
one
of
the
worthy
mentions
over
here
is
that
there's
a
there's,
a
project
called
firefly
that
was
supposed
to
be
submitted
to
the
hyperledger
labs
project,
which
which
does
something
similar
to
this
okay.
A
I've
seen
this
biggie
for
the
last
micro
services.
Microservices
are
typically
one
of
the
most
hyped
architectural
patterns
right
and
it
is
a
very
close
relative
of
the
service
oriented
architecture,
but
one
of
the
biggest
differences
of
of
of
micro
services
from
service
oriented
architecture
is
basically
the
number
of
services
that
are
there
right
and
in
soas
we
have
around
7
to
12,
but
in
micro
services
it's
an
order
of
you
know,
hundreds
or
maybe
more
right,
which
are
completely
independent
of
each
other.
A
A
Now
the
moment
we
add
the
central
orchestrator
over
here,
the
whole
point
of
microservice
fails
right,
because
every
service
is
now
going
to
talk
to
this
central
orchestrator.
So,
in
my
opinion,
right
using
microservices
with
blockchain
is
mostly
an
anti-pattern.
I
would
say,
unless
your
microservice
is
completely
independent
and
can
connect
to
the
ledger
independently
and
and
have
all
these
logic
inside
their
respective
services.
A
Otherwise
I
will
not
kind
of
much
advocate
with
going
with
microservice
architecture.
Okay,
we
saw
a
lot
of
architectural
patterns
now.
What
next
so?
The
next
thing
is
that
we
have
understood
a
lot
about
these
architectural
patterns
and
we
have
seen
that
you
know
what
are
the
pitfalls.
What
are
the
advantages?
What
are
the
compatibility
kind
of
things
that
we
we
can
have
by
looking
at
these
patterns?
And
it's
it's
an
evolutionary
thing
right.
A
So,
as
I
was
saying,
blockchain
platforms
evolve
and
we
have
to
continuously
experiment
with
different
architectural
styles,
and
you
know
ensure
that
we
are
not
doing
harm
to
our
system.
At
the
same
time,
right,
we
cannot
continuously
do
too
many
changes
up
to
our
system,
just
to
figure
out.
You
know
what
fits
and
what
does
not.
So
how
does
a
newcomer
or
anyone
who
is
willing
to
start
up
with
the
project?
How
do
they
go
about
it
right?
So
so
it
at
least
in
my
experience,
and
in
my
you
know,
organizational
experience.
A
Now,
once
we
have
these
attributes
right,
we
can
then
plug
them
in
into
a
system-wide
architectural
fitness
function
right.
So
this
f,
big
f,
is
a
function
of
like
a
1,
a
2
up
till
a
n.
Where
you
know
each
of
a.
I
is
basically
your
quality
attribute
right.
So,
for
example,
let's
say
let's
say
that
we
chose
performance,
availability,
security
and
modularity
right.
We
can
then
key
in
each
of
these
attributes
into
f
right,
where
these
ai
are
basically
your
performance,
availability,
security
and
modularity,
and
once
we
have
this
entire,
you
know
function.
A
We
can
make
guidant
experiments
right
and
and
then
learn
about
the
trade-offs
that
we
have
to
make
while
we
design
the
architecture.
So
the
process
goes
something
like
this
right,
so
we
implement
a
a
baseline
architecture.
That
is,
let's
say
we
start
with
a
layered
monolith,
and
then
we,
you
know
evaluate
this
f
for
our
system.
Right,
let's
say
it's
some
number
at
the
very
bare
minimum
you
can
have.
A
You
know
a
summation
of
all
these
attributes
right,
so
once
we
have
it
right,
then
you
discovered
that
what
all
so
so,
once
you
once
you
implement
it,
then
you
measure
right.
What's
what's
the
overall
value
of
f
and
once
you
have
measured,
then
the
next
stage
is
to
you
know,
discover
what
are
the
improvements.
A
A
Right
and-
and
this
incremental
version
is
basically
what
we
will
call
with
a
new
version
release,
and
once
we
have
done
it,
we
will
circle
back
to
measuring
that
f
value
again
right
over
number
at
over
here
number
two
right
and
if
we
find
that
the
the
num,
the
the
measurement
that
we
have
got
after
doing,
this
incremental
change
is
better
than
the
previous
one.
Then
we
can
proceed
with
that
direction
that
it
that
that
means
that
it
will
give
us.
A
You
know
some
sort
of
hint
that
we
are
going
in
the
right
direction,
because
what
happens
typically,
is
that
once
you
make
any
changes
to
any
architecture,
you're,
essentially
doing
a
trade-off
and
the
moment
you
do
a
trade-off.
You
cannot
exactly
quantify
the
the
positive
or
the
negative
impact
you
had
on
the
system
so
to
to
quantify
it
at
the
overall
level.
That's
where
this
system-wide
architectural
fitness
function
comes
in.
A
So
this
is
a
very
interesting
concept
that
at
least
I
learned
you
know
in
in
in
my
in
my
tenure
and
I'm
still
learning
over
here,
and
if
you
want
to
know
more
basically
about
how
these
evolutionary
architectures
work,
I
recommend
reading.
I
recommend
you
to
read
this
book
by
neil
ford
and
rebecca
parsons
on
building
evolutionary
architectures.
That's
a
pretty
interesting
read.
A
A
A
We
typically
pick
some
of
these.
You
know
candidate,
architectural
characteristics
right
and
once
once
we
pick
them
up,
we
you
know
derive
these
top
characteristics,
this
top
three
or
five.
You
know
driving
characteristics
for
our
system
and
then
once
you've
got
this
you
can,
then
you
know,
you
know,
find
out
the
pros
and
cons
of
each
of
these
architectural
patterns
by
looking
at
a
metric,
something
like
this
right.
A
Of
course,
this
is
not
contextualized
to
blockchain.
But
of
course,
when
you
look
at
you
know
these
patterns
in
general,
it
gives
you
a
fair
amount
of
idea
that
what
patterns
have
what
characteristics
that
they
exhibit
and
then
you
can
go
back
to
some
of
these
lessons
that
we
learned
today.
Some
of
these
things
that
we
discussed
today-
and
you
can
you
know
then
kind
of
incrementally-
build
your
system
starting
small,
and
then
you
know
moving
on
to
advanced
techniques
as
we
move.
A
Any
questions,
okay,
I
got
a
question
from
shaunok.
The
previous
slide,
it's
same
for
any
architecture,
how
it
is
different
for
blockchain.
Yes,
that's
an
excellent
question,
so
this
slide
is
is
same
for
all
the
architectural
patterns.
However,
as
I
the
the
at
the
beginning
of
the
presentation,
as
I
was
seeing,
that
some
architectural
patterns
have
certain
compatibility
with
with
with
blockchain
and
some
architectural
patterns
have
some
pitfalls,
so
it's
not
enough
in
my
opinion
to
just
know
you
know
what
works
and
what
doesn't?
A
We
also
have
to
know
the
you
know
the
these.
These
you
know
compatibility
points
or
pitfalls
before
we
proceed
with
some
of
these
architectures.
So,
for
example,
as
I
was
telling
about,
you
know,
microservices
architecture,
a
lot
of
a
lot
of
the
people
in
my
organization.
Ask
that
you
know
why,
don't
you
do
microservice
architecture
as
an
architect
when
we
start
with
the
with
the
project.
A
You
know
we
are
not
aware
of
these
pitfalls
like
we
are
not
aware
that
you
know
we
need
the
central
kind
of
an
orchestrator
to
to
send
all
those
transactions
through
that
will
coordinate
all
those
transactions
have
all
those
concurrency
issues
fixed.
You
know,
taken
care
of
and
and
then
you
know
build
it
right.
So
this
previous
knowledge
about
these
compatibility
and
pitfalls
helps
a
lot.
So
that's
why
you
need
to
kind
of
couple
this
particular
this.
A
A
Does
it
make
sense
to
utilize
multiple
at
the
same
time?
Yes,
absolutely
yes,
that
makes
perfect
sense
and
that's
an
excellent
question.
So
often
what
we
do
is
that
so,
for
example,
when
we
design
smart
contracts,
so
one
of
the
things
that
we
you
know
had
a
look
in
smart
contracts
is
how
micro
kernel
architectures
help
there,
no
matter
what
kind
of
architecture
you
have
for
your
off
chain
or
for
your
d
app.
It
always
makes
sense
to
have
your.
A
You
know:
smart
contracts,
modular
and
you
know
reusable,
so
you
don't
have
to
you,
know,
decouple
those
smart
contracts
later
and,
and
you
know,
deploy
new
word
newer
versions
of
them.
So
upfront,
if
you
have
the
knowledge
that
you
know,
I'm
going
to
use
always
kind
of
micro,
kernel,
kind
of
an
architecture
for
smart
contracts
or
then
you
know,
use
the
central
event
orchestrator
for
for
having
all
the
transactions
go
through
it
right
and
and
manage
the
concurrency
aspects
to
it.
So
there
you
have
it
like.
A
I
have
just
coupled
service
oriented
architecture
and
micro,
micro,
kernel
architecture,
so
yeah
you
can
obviously
cop
you
know,
compile
these
patterns.
Are
there
architectural
pitfalls
when
designing
with
multiple
blockchains,
hyperledger,
ebsi,
ethereum
or
cardano?
That's
another
excellent
question.
So
yes,
so
in
my
opinion,
you
have
to
be
very
much
aware
of
these.
You
know
pitfalls
of
or
compatibilities
of
of
the
pattern
with
the
ledger
platform,
so
certain
certain
platforms
require
you
to
design
your
architecture
in
certain
way.
A
So
so,
if
you
have
that
knowledge,
it
will
help
you
to
you
know,
design
your
components.
Your
modules,
you
know
with
with
ease,
I
would
say
so
so
so
so,
basically,
when
you
combine
these
right,
probably
if
you
have,
if
you
have
a-
I
don't
know,
if
that's
a
question,
if,
if
you
have
a
system
where
you
have
multiple
ledger
platforms
or
you
have
to
support
multiple
agent
platforms,
then
of
course
you
have
to
make.
A
Okay,
there's
one
more
question:
what
are
the
risks
of
event
driven
systems?
I
am
often
somewhat
uncomfortable
in
case
an
event
disappears.
Oh
that's
another
excellent
question.
So
yes,
I
have
faced
this
as
well.
So
what
what
I
would
suggest
is
that
you
know
events
typically
in
in
blockchain
are
kind
of
ephemeral
in
nature,
unless
you
persist
it
in
some
sort
of
an
event
store
like
a
kafka
or
a
rabbit
mq
or
maybe
some
some
managed
cloud
offering
like
azure
service
bus.
A
So
you
can
use
something
like
you
know,
producer
producing
the
event
or
in
the
blockchain
producing
the
event
and
the
consumer
who
is
interested
in
the
event?
Consumes
that
event,
processes
that
event
successfully
and
then
only
acknowledge
the
acknowledges
that
event
on
the
even
broker.
So
you
can
have
this.
You
know
explicit
acknowledgement
cycle
that
way
you
you
will
ensure
that
your
events
are
never
lost.
At
least
you
know,
once
the
events
are
there
in
the
message
broker,
they
are
never
lost.
A
On
the
other
hand,
you
can
also
ensure
that
you
know,
while
producing
the
event
in
the
first
place.
There
are
certain
you
know,
message,
delivery,
semantics
like
just
once
delivery,
or
you
know
at
least
once
delivery
like
they
are
there
in
kafka
or
rabbit
mq.
So
you
can
ensure
those
kind
of
semantics
are
enabled
for
your
system
so
that
on
the
producer
side,
the
producer
never
misses
the
event
to
register
them
on
the
message
broker
and
also
on
the
consumer
side,
the
consumer
consumes
it
and
successfully
processes
it.