►
From YouTube: Firefly Architecture Series Episode 8: FireFly Event Sequencing and Aggregation, Part II
Description
We continue our exploration of FireFly’s event driven programming, with a deeper dive into how FireFly provides its ordering guarantees.
What is FireFly?
FireFly is a Hyperledger Lab that provides a multi-party system for enterprise data flows, powered by blockchain. It solves the layers of complexity that sit between the low-level blockchain and high-level business processes and user interfaces. FireFly enables developers to build blockchain apps for enterprises radically faster by allowing them to focus on business logic instead of infrastructure.
Learn more about FireFly at Hyperledger Labs: https://wiki.hyperledger.org/display/labs/Firefly
----
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 #HyperledgerFireFly #Blockchain
A
Welcome
everybody
to
the
firefly
community
call
I
I
would
say
weekly,
but
we
have
actually
just
moved
to
an
every
other
week,
cadence,
so
welcome
to
the
every
other
week.
Firefly
community
call
just
a
couple
of
quick
announcements
and
status
updates
to
kick
us
off
here.
I
will
go
ahead
and
start,
and
I
wanted
to
highlight
just
a
couple
of
things.
I'll
share
my
screen
to
show
a
couple
things
here:
real
quick.
A
So
new,
in
all
of
the
repos,
now
we
have
an
updated
list
of
maintainers
specific
to
each
repo
so
and
the
the
code
owners
have
been
updated
to
reflect
these
lists
as
well.
So
if
you
open
a
pr
to
any
of
the
repos
this,
if
you
look
in
maintainer
md,
this
is
the
list
of
people
that
will
be.
Somebody
on
this
list
has
to
do
the
review
and
they'll
all
get
notified.
A
A
If
you're
new
to
you
know
if
you're
new
to
hyperledger
or
open
source,
there's
some
helpful
tips
here,
but
the
I
can't
recall
if
I
showed
this
guide
in
a
previous
one,
but
this
is
a
new
guide
and
some
new
features
in
case
you
haven't
seen
it
some
new
features
in
the
cli
that
make
it
a
lot
easier
to
do
local
development
on
firefly
itself
and
coordinate
that
with
all
of
the
docker
dependencies
and
that
sort
of
stuff.
So,
if
you're
interested
in
getting
involved,
those
are
some
great
places
to
get
started.
A
If
there's
stuff
missing
there
or
you
have
questions,
please
reach
out
to
me
and
be
happy
to
clarify
things
or
add,
I'm
sure
there's
additional
documentation
to
add.
But
I
just
wanted
to
provide
a
quick
update
on
that
all
right
in
other.
In
other
updates,
we
are
in
active
development
on
the
cli
and
supporting
multiple
ledgers
right
now,
so
I've
been
working
on
fabric
support
secret,
who
is
actually
yes,
he
joined
us
today
is
looking
at
supporting
hyperledger
basu
as
well.
A
B
So
we
talked
about
tokens
on
one
of
the
very
first
community
calls
back
at
the
end
of
june,
and
we
were
kind
of
presenting
some
of
the
ideas
that
we
had
for
tokens
and
opening
that
up
for
discussion
on
how
that
would
actually
be
fleshed
out.
So
happily,
the
past
couple
weeks,
I've
been
able
to
make
that
kind
of
a
primary
focus
getting
down
to
the
nitty
gritty
of
writing
up
some
of
the
code
for
these,
and
I
just
wanted
to
share
kind
of
where
it's
up
to.
B
So
we
do
have
one
token
bridge
runtime
that
we
picked
an
ethereum-based
erc
1155
as
the
first
token
bridge.
We
anticipate
many
many
more
because
tokens
are
just
hugely
flexible
components
of
a
blockchain
system
and
we
think
there's
going
to
be
a
lot
of
different
plugins
here,
but
then
inside
firefly
we
have
both
an
asset
manager
and
a
token
interface
that
are
both
these
exact
things
are
part
of
pull
request.
Number
154,
that's
open
right
now.
B
So
if
anyone
else
wants
to
look
at
that
code,
you
can
see
how
asset
manager
is
shaping
up
and
how
the
token
interface
is
shaping
up,
and
particularly
the
plugin.
For
this
one
token
bridge,
that's
already
created
just
going
on
to
steal
another
slide
that
came
out
of
one
of
nico's
earlier
presentations
about
the
architectural
layers
of
firefly
and
the
plug-ins.
I
just
wanted
to
highlight
that
we've
slid
in
kind
of
a
new
full
stack
here.
This
kind
of
bluish
lavender
stack.
B
B
It
could
be
any
type
of
underlying
token
as
long
as
it
meets
this
https
api,
and
then
we
actually
have
the
first
sort
of
three
level
deep
set
of
microservices,
where
we
have
a
new
repo
that
implements
the
erc,
1155
and
and
kind
of
exposes
it
as
this
sort
of
well-known
api
that
I've
defined
and
then
underneath
it
is
actually
using
ethconnect,
which
ultimately
is
ethereum
and
an
erc
1155
based
contract.
So
we
have
this
whole
stack
and
we
ended
up
needing
kind
of
an
extra
layer
in
here.
B
This
is
written
in
typescript
because
we
feel
that
there's
kind
of
a
wide
base
of
typescript
skills
out
there
that
may
be
able
to
get
contributors
on
this
or
others.
And
then
it
deploys
a
solidity
contract,
that's
ultimately
deployed
onto
ethereum
and
each
connect
kind
of
similar
to
some
of
our
other
blockchain
work
and
then,
of
course,
the
core
work
for
firefly
is
underway
right
now,
cli
support
was
just
merged
as
of
0.0.29,
and
then
we
have
these
well-defined
rest
apis
at
each
layer.
B
So
a
lot
of
different
pieces
kind
of
in
flight
here
and
it's
a
very
quick
overview,
but
if
you're
interested
in
knowing
more
about
any
of
these
pieces
or
contributing
and
go
and
typescript
and
solidity,
because
I
could
certainly
use
experts
on
all
of
these
to
help
contribute.
Then
please
reach
out
to
me
or
to
nico
or
on
rocketchat,
and
we
can
see
where
you
can
help
out.
A
Awesome,
thank
you,
andrew
and
just
to
to
kind
of,
highlight
and
reinforce
something
that
andrew
said,
so
that
we've
implem,
so
the
decision
to
move
or
to
introduce
a
token
bridge
is
important
because
we
do
not
want
to
provide
an
authoritative
way
to
do
tokens
because
tokens
like
everybody
has
a
different
way
that
they're
going
to
want
their
particular
token
to
work
or
they
want
their
application
to
work
with
tokens.
So
this
firefly
tokens
erc
1155
bridge
that
we
are
building.
A
It
is
not
by
any
means
an
authoritative
implementation
on
how
tokens
shall
be
built
that
is
completely
up
to
the
community
or
anybody
who
wants
to
deploy
firefly
and
run
it
and
customize
it.
They
can
drop
in
their
whatever
implementation
of
bridge.
They
want,
whatever
smart
contract
for
actually
executing
the
token
logic
on
the
other
side
that
they
want.
So.
C
Exactly
we
quickly,
I
just
just
want
to
say
so.
We
we
haven't
started
on
the
bridge
yet,
though,
just
just
the
connector,
so
the
piece
that
does
tokens
fungible
non-fungible
tokens,
a
bridge
which
is
a
piece
that
we're
talking
about
getting
to
down
the
road.
Sorry,
it
would
be
here.
I've
got
tokens
in
my
ecosystem.
I
want
to
bridge
them
to
another
another
ecosystem.
A
C
This
is
really
exciting
stuff.
It's
it's.
I've
been
watching
the
progress
here
and
it's
it's
going
to
be
great.
To
have
to
have
this.
Have
this
in
it's
it's.
We,
we
talked
about,
there's
like
two
really
big
legs
of
the
stool,
which
are
are
needed
before
we're
kind
of
together
and
sort
of
feeling
like
we're,
we're
sort
of
an
mvp
level
of
functionality
for
for
firefly
as
a
whole
and
and
the
the
two
big
legs.
C
There
are
the
token
capabilities,
because
they're
just
so
core
to
the
programming
of
any
blockchain
application
and
then
also
the
fabrics
part
of
this,
but
the
the
sort
of
generic
on-chain
logic
support.
I
did
want
to
share
there's
also
a
lot
of
work
happening
on
that
stat
thread
as
well.
The
fabric
work
is
really
going
great
guns,
it's
at
a
similar
level,
but
jim's
out
this
week.
So
I
think
I
think
there'll
be
an
update
on
that
one
in
the
next.
The
next
one
of
these
sessions.
A
A
C
C
Intended
to
be
myself
the
last
thing
to
talk
about
thanks,
niko,
so
we're
we
did
a
session,
it's
the
date's
still
on
the
slides
7th
of
july,
and
we
talked
about
event
sequencing
in
in
firefly,
because
it's
it's
a
pretty
critical
piece
of
what
firefly,
what
firefly
does
so
we
we
got
through
the
basics
and
then
we
paused
and
we
said
we'll,
come
back
to
the
details.
So
the
idea
today
is
to
to
go
down
into
the
weeds
talk
about
previous
how
privacy
and
sequencing
goes
together.
C
Talk
about
the
internal
event
model,
the
event
bus,
that's
inside,
of
inside
of
firefly,
because
it's
actually
got
quite
a
lot
of
a
messaging
system
inside
of
inside
of
it.
So
we're
going
to
go
into
that
level
of
detail,
but
just
in
case
there's
anybody
who
doesn't
have
a
perfect
memory
that
expands
multiple
months.
C
Those
on
chain
constructs
even
really
really
simple
ones
like
just
ordering
stuff
or
more
complicated
ones
like
tokens,
etc
to
be
coordinated
with
off
chain
real
world
enterprise
systems.
So
you
can
have
your
you
know,
five
parties
in
the
network
of
three,
as
we've
got
on
the
screen
here.
Each
one
of
them
can
have
the
core
systems
that
they
do
have
right,
that
they've
been
building
building
for
the
last
20
40
years,
depending
on
how
how
big
that
that
organization
is
that
they've
they've
got
very
existing
systems
of
record.
C
They
can
join
a
multi-party
system
and
they
aren't.
You
know,
let's
not
be
over
under
any
illusions
over
this
they're,
not
going
to
throw
away
all
of
what
they're
doing
today,
just
because
they've
joined
a
multi-party
system,
but
they
are
going
to
start
doing
something
differently
and
chances
are
they're
going
to
get
involved
in
a
multi-party
business
process,
they're
going
to
start
doing,
they're
going
to
try
and
solve
a
problem
in
a
multi-organization
way,
and
it's
going
to
be
it's
going
to
involve
some
some
new
steps
right.
C
It's
going
to
involve
some
agreed
data
formats
being
exchanged
and
agreed
sequence
agreed
decision
points,
whether
they're,
automated
or
they're
human.
Whether
some
of
those
decisions
are
shared
logic.
Some
of
them
are
customizable
logic,
there's
going
to
be
this
sort
of
set,
and
this
is
not
a
new
problem.
This
is
what
any
messaging
system
has
been
built
for
for
the
whole
of
whole
of
my
career.
But
all
previous
messaging
systems
had
this
problem.
I've
got
my
sequence:
you've
got
your
sequence.
C
C
So
we
used
this
picture
and
we
talked
about
the
fact
that
if
you
think
about
a
body
party
system
like
a
funnel
lots
of
parties
involved,
are
trying
to
do
things,
they
know
the
order
in
which
they're
doing
them
their
system.
Their
firefly
is
knows
that
bob
and
sally
here
bob
submitted
event,
one
two
and
three
sadly
submitted
event,
one
two
and
three
we're
used
to
that.
Being
you
know
very
deterministic,
you
you
make
three,
you
submit
three
messages
into
your
mq
or
kafka
or
whatever,
or
you
make
three
rest
api
calls.
C
It
will
create
one
agreed
sequence:
it
will
receive
the
items
in
order
from
the
multiple
parties
and
it
will
create
one
agreed
sequence,
and
you
can
see
here
that
bob's
sequence
is
in
the
order
that
he
submitted
it.
One
two
three
sally's
sequence
is
in
the
order
that
she
submitted
it
one
two
three
but
they're
intermingled
and
when
you're
thinking
about
building
your
business
logic,
this
is
hugely
powerful
because
it
means
that
you
can
both
process
these
in
the
same
order.
C
C
If
sally
submits
ball
number
one
here
immediately
assumes
that
it's
the
right
next
thing
to
do.
That's
incorrect
because
actually
sally
submitted
ball
number
one,
but
actually
her
application
needs
to
process.
Bob's
ball
number
one
and
bob's
ball
number
two
before
actually
processing
hers,
and
we
use
the
example
before
of
a
bid.
There's
one.
I
think
we
use
the
crate
of
bananas.
C
There's
one
crate
of
bananas
there's
a
whole
bunch
of
parties
in
the
system
bidding
on
that
crate
of
bananas
and
if
one
of
those
parties
says
look,
I'm
the
I
I'm
gonna,
you
know
submit
the
highest
bid
or
I'm
gonna
be
the
first.
If
it's
first
past
the
post,
I'm
gonna
be
the
first
first
one
to
grab
this
thing.
C
You
can
assume
that
you've
grabbed
it
just
because
you
said
grab,
but
actually
you
might
not
win
the
race.
So
if
you
want
to
know,
did
you
grab
it?
You
need
to
check
the
state
after
your
attempt
was
was
was
was
submitted
and
because
we're
decentralized
the
processing
has
to
happen
either
on
the
blockchain.
It's
one
option
shared
state
very
difficult
if
you've
got
privacy
involved
or
everybody
has
to
do
the
same
processing
and
come
up
with
the
same
the
same
answer,
so
you
can
run
the
same
logic
everywhere.
C
So
that's
the
summary
of
the
problem.
We're
trying
to
solve
the
the
core
thing
on
which
you
know
bitcoin
was
built
on
right
and
and
the
evolution
of
the
of
of
all
things.
Since
is
this
concept
that
everybody
can
have
an
agreed
sequence
and
you
layer
the
logic
on
top
and
firefly
lets
you
layer,
the
logic
deterministically
in
the
chain,
but
it
also
lets
you
layer
the
logic,
so
that's
executed
multiple
times
by
different
parties
off
chain.
C
So
we
slightly
more
detailed
picture
of
the
previous,
but
we
went
through
last
time
where
you've
got
bob's.
Bob's
got
his
firefly
node,
which
includes
messaging
for
off
chain,
includes
ipfs
for
storing
sorting
broadcast
data.
It
includes
a
database.
It
includes
a
blob
store
for
for
storing
data.
That
could
be
that's,
you
know
large
documents,
etc.
There's
the
runtime
with
the
api
and
bob
can
submit
a
green
and
then
a
red
message.
C
Now
I
think,
a
couple
of
weeks
ago
we
talked
about
there
was
a
feature
in
flight
in
in
firefly,
but
would
allow
this
api
call
to
block
until
this
event
comes
back
to
your
application,
so
to
pause.
So
until
it's
been
sequenced
and
all
other
events
have
been
omitted
that
are
before
that.
So
there's
a
block
to
stop
your
api
call
make
it
wait.
Let's
say
it
takes
five
seconds.
Your
api
call
will
wait
for
five
seconds
until
this
has
been
sequenced.
C
C
So
that's,
that's!
That's
one!
That's
one
extra
thing
that's
come
in,
but
fundamentally
this
is
the
core
model
of
fireflies
that
you're
you're
submitting,
but
really-
and
we
talked
about
event
driven
programming
a
couple
of
sessions
ago.
You
really
rather
than
sort
of
thinking
about
blocking
the
right
way
to
write
your
application
in
90
percent
of
cases.
The
right
way
is
you:
are
you
just
have
a
listener
in
your
app
that
remember
when
we're
talking
about,
we
were
doing
the
the
sort
of
event-driven
programming
sort
of
101.
Last
time
you
should.
B
C
So
this
is
a
summary
picture
of
the
internals
of
firefly
that
that
are
responsible
for
making
the
last
slide
true
and
it's
basically
a
messaging
engine.
This
piece
of
the
code-
it's
probably
one
of
the
heaviest
lifting
pieces
of
the
code
because,
as
I've
said
before,
it's
the
one
thing
that
can
only
be
done
in
the
firefly
layer,
because
it's
about
coordinating
together
things
that
happen
on
the
blockchain
things
that
arrive
over
messaging
things
that
are
available
in
ipfs.
C
C
So
this
is
one
of
the
reasons
why
this
is
a
big
piece
of
heavily
heavy
lifting
and
firefly
is
because
firefly
is
the
orchestrator
for
this
sort
of
on-chain,
off-chain,
coordinated
sequencing,
and
so
we've
got.
We've
got
sally's
app
here
and
sally
does
a
post
of
a
of
a
of
a
broadcast
in
this
particular
scenario.
C
If
you
don't
specify
the
confirm
true,
so
the
default
mode
of
operation
and
the
mode
of
operation,
I'd
encourage
for
the
majority
of
use
cases
you're
going
to
get
an
acknowledgement
with
a
202
rather
than
201.
Apologies
for
the
the
incorrect
slide
here.
You'll
get
a
202
accepted
back
straight
away
as
soon
as
that
message
has
just
been
written
to
a
local
messages
table,
so
there's
a
database
table,
and
this
is
a
summary
of
it.
This
isn't
meant
to
be
the
full
database
scheme.
C
It's
just
enough
to
give
you
an
idea-
and
it
has
a
local
sequence,
really
critical
to
understand
that
this
sequence
is
only
useful
within
my
local
firefly,
and
the
reason
why
sally's
firefly
needs
to
keep
a
record
of
her
sequence
is
because
this
firefly
needs
to
make
sure
that
it
submits
it
into
the
blockchain
for
global
sequencing.
In
the
same
order
that
sally
submitted
it,
it
will
be
a
crazy,
weird
system
if,
when
sally
submitted
message,
one
two
and
three,
then
sally's
messages
ended
up
getting
ordered
on
the
blockchain
message.
C
Two
one
three
right
that
would
just
be
really
hard
for
any
programmer
to
to
work
against.
So
firefly
needs
to
be
absolutely
certain
locally,
that
it
knows
the
order
in
which
messages
were
submitted
by
the
apps
connected
to
the
local
firefly,
and
it
does
that
by
putting
it
into
a
message
table
and
that's
all
it
is
when
you
do
send.
C
The
next
step
is
that
the
batch
processor
kicks
in,
and
the
reason
why
we
have
a
batch
processor
is
that
from
the
previous
generations
and
production
deployments
there.
We
realized
that
these
technologies,
blockchain
and
even
more
so
technologies
like
ipfs,
are
not
designed
to
create
very
high
throughputs
by
by
submitting
lots
and
lots
of
individual
things.
Sequentially,
particularly
something
like
ipfs.
If
you,
if
you
take
tiny
packages
of
like
a
kilobyte
of
data,
and
you
submit
a
thousand
of
them,
that
will
take
time
x
of
some
number
of
milliseconds.
C
C
C
So
maybe
wait
for
up
to
half
a
second
to
fill
up
a
batch
so
delay
any
individual
message
by
up
to
half
a
second
to
allow
friends
to
join
it
and
allow
maybe
500
to
to
join
to
join
it.
So
so
that
would
be
an
example
of
sort
of
configuration
on
the
batch
processor.
I
can't
remember
what
the
defaults
are,
but
it's
in
the
order
of
what
I
just
just
described
and
and
it
it
it
spins
around
assembling
a
batch
and
the
batches
are
on
the
rest
api.
C
So
you
can
see
the
batches
and
it
updates
the
individual
messages
with
the
id
of
the
batch
that
they've
been
popped.
Inside
of
so
that's
that's
what
happens
when
you're,
globally
sequencing?
None
of
this
happens
if
you're
just
doing
completely
unpinned
private
sends
to
somebody,
but
when
it's
being
pinned
to
the
blockchains,
we
call
it
a
batch
pin
transaction.
C
It
gets
assembled
along
with
a
bunch
of
its
friends
into
a
batch.
Each
of
these
gets
updated
with
a
batch
a
batch
and
then
once
the
batch
is
ready
for
dispatch.
It
gets
what
we
call
sealed
so
all
of
the
all
of
the
hashes
etc
get
generated.
So
it
can't
be
changed
from
that
point
on
and
and
then
it
gets
written.
C
The
full
data
of
the
batch
gets
written
to
to
to
storage
or
sent
across
private
messaging,
and
the
blockchain
gets
a
tiny
transaction,
a
teeny,
tiny
transaction
which
just
got
enough
proof
that
you
can
tie
it
back
to
the
batch
and
that
and
that's
the
key
thing
is
that
the
blockchain
is
the
sequencer,
so
the
blockchain
has
to
put
it
in
the
right
order.
The
blockchain
does
not
need
to
contain
the
data,
so
the
blockchain
has
this.
C
C
That's
the
easy
bit
the
complicated
bit
is
that
now
this
blockchain
transaction
is
being
ordered
with
all
kinds
of
other
transactions
going
to
the
system
from
all
kinds
of
parties,
and
the
data
is
going
to
arrive
at
a
completely
different
time.
If
it's
ipfs,
then
it
should
be
there
and
you
have
to
sort
of
suck
it
down.
If
it's
data
exchange,
it's
going
to
be
in
a
messaging
system
right,
it's
going
to
be
flowing
asynchronously
at
the
right
at
the
right
time
to
get
across
to
you.
C
C
C
C
C
So
these
these
the
fact
that
you
sent
all
of
these
messages
the
events
themselves
that
are
coming
in
they
they
are
all
written
in
perpetuity,
they're,
never
they're,
never
deleted
and
that's
very
different
to
a
traditional
kafka,
mq
meshing
system,
which
is
like
maintaining
a
little
really
super
fast
buffer
to
just
transport
things
in
flight.
This
is
about
a
complete
history
of
time.
So
that's
why
we
use.
C
We
use
a
a
database
here
and
we
try
to
be
as
efficient
as
we
can
and
I'm
sure
there'll
be
more
optimization
in
the
coming
months
on
that
usage
of
the
database.
So
you've
then
got
the
events
table
and
the
events
there's
only
one
event,
even
if
you've
got
multiple
applications.
Listening
to
those
to
those,
you
know
those
yellow
balls
that
were
coming
in
from
sally
and
the
blue
ones
coming
in
from
from
bob,
you
might
have
five
applications
all
connected
to
the
same
firefly
that
want
to
listen.
C
That's
the
events
table
so
the
last
piece
of
the
puzzle
here
and
we
may.
We
may
pause
at
the
end
of
this
and
see
if
for
questions
and
see
if
we
want
to
come
on
to
the
privacy
perverting
preserving
piece,
because
it's
even
more
it's
a
little
bit
more
complicated
than
this.
The
subscription
manager
is
the
last
piece
and
the
subscription
manager
is
responsible
for
starting
and
stopping
what
are
called
event
dispatchers
and-
and
this
is
because
you
might
have
multiple
applications
interested
in
the
same
message
same
event.
C
A
very
obvious
example
of
this
is
if
I've
got
a
copy
of
the
firefly
explorer
running
and
you've
got
a
copy
of
the
firefly
explorer
running
on
your
laptop
we're,
both
developing
against
the
same
firefly
server.
Obviously,
we
both
need
a
copy
of
the
message.
It's
not
going
to
be
very
useful
if,
if,
like
my
ui
updates
one
time
and
then
randomly
yours,
you,
I
updates
another
time
and
we're
seeing
different
updates.
That
seems
really
really
weird,
which
is
exactly
the
same
for
applications.
C
If
you've
got
if
you've
got
multiple
instances
of
the
same
application,
you
might
want
messages
to
be
workload
balanced
between
them
or
you
might
want
each
one
of
those
applications
to
get
a
copy
of
the
of
the
of
the
message,
and
we
talked
about
durable
versus
non-drawable
or
named
versus
ephemeral
applications
in
in
the
previous
talk.
So
so
what
the
subscription
manager
does
is
it
maintains
these
event
dispatchers
and
the
event
dispatchers
are
started
when
the
application's
listening.
C
So
if
you've
got
an
application
when
it
connects
across
a
web
hook
that
connection
goes
into
firefly,
the
subscription
manager
kicks
off
an
event
dispatcher.
For
your
particular
connection
on
the
web
hook,
if
you've
got
an
application
that
wants
just
one
copy
of
the
message
that
might
open
multiple
web
sockets
into
into
firefly,
then
there's
a
leader
election
that
happens
so
that
only
one
event
dispatch
will
get,
will
gets,
get
started
and,
and
that
becomes
the
the
leader
and
all
messages
will
go
to
that.
One.
C
Application
instance
that
app
that
connection
disconnects-
and
it
goes
to
the
other
for
web
hooks,
which
is
a
push
model,
there's
one
event
dispatcher
for
all
web
hooks
and
it's
just
receiving
them
and
then
pushing
them
to
as
many
webpages
as
as
needed.
So
that's
the
event
dispatchers
in
terms
of
how
it
works.
Inside
of
the
databases,
we
don't
have
lots
of
copies
of
the
events.
The
events
exist
exactly
once,
but
the
events
just
like
the
messages
have
a
local
sequence
that
we
know
will
order
them
inside
of
the
database.
C
So
all
we
need
to
maintain
in
each
subscription
is
a
pointer.
An
offset
really
really
well
established
pattern
in
messaging.
We
just
maintain
an
offset
where
a
particular
subscription
knows
where
it's
up
to
in
the
sequence
of
events.
Subscriptions
can
also
have
filters
applied
and
that's
fine
all
it
does.
Is
it
just
goes
through
these
messages,
one
by
one
by
one
saying,
does
it
match?
Does
it
match
if
it
does
match
it
needs
there
needs
to
be
an
event,
dispatcher
ready
to
process
it.