►
From YouTube: GitLab Events Architecture
Description
Discussion about how we can build common abstractions for emitting / dispatching events, about things that are happening inside GitLab, to unlock additional productivity and value.
A
Hello,
everyone
to
the
meeting
with
the
purpose
to
discuss
even
stream
architecture
whatever.
However,
we
call
it
things
about
events
basically
and
I
scheduled
this
meeting
to
discuss
how
we
want
to
move
forward
with
possible
improvements
in
gitlab
and
I
would
like
to
start
by
saying
that
I
have
not
scheduled
this
meeting
to
criticize
the
current
state
of
things.
A
There
are
a
couple
of
them
that
I
listed
in
in
the
agenda.
For
example,
we
could
have
almost
zero
cost
amid
keyword
in
the
code
base.
That
would
make
it
possible
for
every
engineer
to
emit
events
from
their
code,
Without
Really,
impacting
performance
in
any
way
we
could
Implement.
Even
the
gateways
think
about
the
system
hooks
that
we
are
having
today
and
how
web
hooks
are
implemented.
On
top
of
them.
A
A
Don't
want
to
go
into
details
right
now,
but
I
wanted
to
say
that
I
believe
architectural
changes
like
that
won't
happen
overnight,
and
if
we
want
to
actually
think
about
building
a
better
architecture
to
unlock
some
value,
it
would
be
great
to
start
those
conversation
right
now
and
perhaps
think
about
how
we
can
move
forward.
I
know
that
there
is
even
stream
working
group
I'm,
not
part
of
this
working
group,
but
I
I
haven't
seen
much
activity
in
it
recently.
B
B
I
can
jump
in
real,
quick
I
I
was
one
of
the
members
of
the
original
working
group
and
it
it
just
kind
of
lost
momentum
with
not
a
lot
of
Direction
and
so
I
I
appreciate
you
bringing
this
back
up
because
I,
it's
been
a
goal
of
mine
in
my
my
groups
to
get
something
kind
of
going
and
it
was
very
frustrating
to
lose
lose.
The
momentum
that
we
did
so
any
more
Direction
and
motivation
is,
is
appreciated.
C
Yeah
I
actually
have
some
thoughts
on
this
because
I
mean
I've
only
joined
this
discussion
pretty
late,
but
just
based
on
what
I
saw
in
the
in
the
discussions
and
the
kind
of
like
changes,
people
had
on
slack
and
I
might
be
missing
context
here,
I,
don't
know
how
much
discussion
had
happened
in
the
working
group
itself
or
and
get
lab
issues
before,
but
it
feels
to
me
like,
or
what
I
don't
understand
at
this
point
is.
Oh
I
would
like
to
understand
better
what
the
individual
problems
are.
C
I
wouldn't
do
this
bottom
up.
I
would
try
to
understand
first
what
the
problem
is
we're
trying
to
solve
and
then
see
if
it
even
makes
sense
to
have
some
kind
of
uniform
abstractional
platform
around
this,
because
just
to
give
it
like
one
specific
example,
I
think
the
problem
of
like
propagating
an
event
or
a
notification
in
the
rail
step
itself
might
be
very
different
from
something
like
screen.
C
Processing
right,
if
I,
do
some
kind
of
like
ETL
and
stream
data
to
a
data
warehouse
that
might
also
use
some
sort
of
Eventing
I.
Don't
think
that
would
be
whatever
tools
we
would.
You
know
use
for
something
like
that
would
probably
not
be
appropriate
to
solve
the
problem
of
notifications
propagating
through
rails.
So
so
I'm
just
wondering
like
what
the
problems
are
and
we're
looking
to
solve
here
and
then
maybe
go
from
there.
A
D
So
sorry,
I'll
just
give
one
example
which
comes
up
like
it
time
and
time
again
with
the
with
the
abuse
team
and
I
kind
of
mentioned
it
below
and
I
know.
It's
just
one
example:
there's
lots
of
different
things,
but
we
have
this
idea.
I
can't
remember
the
exact
name.
Now,
I
was
kind
of
scrambling
to
find
it.
D
Bunch
of
use
cases
that
I
think
would
be
useful
is
connect
that
up
to
something
like
Google
Pub
sub,
so
that
it's
just
emitting
and
we
have
like
a
something
nearby-
that's
just
receiving
those
web
Hooks
and
then
immediately
publishing
it
on
on
Google
Pub
sub.
And
then
we
start
setting
up
a
way
that
we
can
kind
of
allow
different
subscribers
in
and
Google
Pub
sub
is
is,
is
incredible
how
much
we
can
handle
with
that.
D
You
know
all
of
our
logs
for
gitlab.com
go
through
that
and
in
2019,
when
I
went
to
Google
Cloud
next,
one
of
the
Google
Engineers
actually
asked
me
what
we're
using
it
for
because
he
said
at
the
time
we
were
the
biggest
installation
or
the
biggest
throughput
on
Google
Pub
sub
I.
Don't
know
if
that's
still
true,
but
that's
what
they
claimed
at
the
time
and
we've
it's
probably
the
service
that,
from
an
infrastructure
point
of
view,
we've
we've
had
to
deal
with
the
least
like
it
just
works.
D
A
I
agree
with
what
you
are
saying:
Andrew
also
agree:
what
Matthias
mentioned
that
the
architectural
choices
may
look
very
differently
for
events
going
outside
of
GitHub
and
events
being
created
inside
of
the
gitlab,
but
I
think
that
it's
actually
the
same
abstraction,
actually
two
abstractions
on
two
different
levels.
One
level
is
something
happens
in
gitlab
inside
gitlab
and
we
emit
this
event
in
a
very
low
cost
way
like
using,
for
example,
emit
keyword
or
emit
method.
A
The
second
abstraction
that
is
missing
is
being
able
to
Define
what
groups
of
events
go
to
what
getaways,
and
then
we
can
decide
that
for
this
group,
events
will
be
rooted
back
inside
the
rails,
monolithic
application
without
really
going
outside,
but
we
can.
But
if
this
is
an
abstraction,
we
can
easily
Implement
an
abstraction
that
will
determine
that.
For
this
group
we
want
to
actually
push
that
outside
to
a
Google
pop
sub
or
different
yeah,
and
those
are
the
abstractions
that
are
not
here
today.
We
are
having
system
hooks
that
are
completely.
A
You
know
non-abstract
implementation.
Different
teams
are
building
different
solutions
right
now
we
have
web
hooks
that
subscriptions
are
being
defined
in
database
right,
but
right
now
the
verified
team
is
building
gitlabsia
events
that
are
going
to
trigger
pipelines
and
the
team
is
building
their
own
subscription
mechanism
and
because
of
not
having
common
abstractions
for
emitting
event
and
defining
gut
ways
like
there's.
No
really
any
opportunity
to
can.
D
I
can
I
suggest
the
three
there's
three
different
types
of
events
that
we're
talking
about
here-
that
there's
there's
the
kind
of
external
ones
that
go
to
external
data
well
at
least
external
to
the
rails.
Application
right
then
there's
what
you
were
talking
about,
which
is
more
like
an
internal
event.
Sync,
if
you
want
and
then
I
I
think
that
the
the
web
hooks
sorry,
the
the
websockets
slash
connection
to
the
front
end
slash
Real,
Time
stuff,
it's
it's
also
a
different
domain
and
I.
A
I
can
even
imagine
building
a
getaway
that
actually
intercepts
the
external
events
from
satellite
services,
for
example,
and
translate
them
into
internal
emit
keyword
events
that
then
can
again
be
intercepted
by
another
getaway
that
can
transform
their
into
something
else.
It
may
seem
complex,
but
this
is
actually
something
very
simple.
In
my
opinion,
yeah.
C
D
D
C
I
feel
I
feel
to
me.
This
is
exactly
the
point.
I
was
trying
to
make
earlier
that
that's
like
starting
with
Solutions
before
defining
what
the
problem
is,
because
I
I'll
give
you
I'll
try
to
give
you
a
very
quick
summary
of
like
why
I'm
here,
our
team-
and
this
is
not
final-
so
maybe
it
shouldn't
be
shared,
it's
not
like
secret
or
anything,
but
it's
just
not
decided
yet.
C
User-Facing
features
in
a
real-time
first
manner,
the
idea
being
that
we
want
to
kind
of
get
away
from
all
this
polling
that
we
do
all
of
these
non-synchronized
interactions.
We
have
between
widgets
on
a
website
where
it
is
a
big
statements
and
updates
don't
propagate
quickly
enough
and
it's
it
doesn't
work
well
enough
for
collaborated
sessions
as
well,
where
you
might
want
to
collaborate
on
an
issue,
for
instance
right,
and
we
have
like
some.
C
We
have
built
some
things
in
different
stage
groups
to
like
work
in
that
direction,
but
we're
not
sure
whether
that
is
happening
in
kind
of
like
a
building
like
basic
building
blocks.
First
approach:
we
also
had
a
single
Engineering
Group,
exploring
real-time
issue,
editing
for
instance,
which
is
way
more
complex.
C
So
the
question
came
up:
how?
How
can
we
provide
a
solution
that
kind
of
frees
product
developers
from
having
to
think
about
all
these
implementation?
Specific
choices
like
where
do
I
use
a
graphql
subscription
or
a
graphql
trigger
right
or
where
do
I
need
to
integrate
with
redis
pupsa?
You
know,
because
maybe
this
needs
to
persist.
Crdt
State
stuff,
like
that.
So
this
is
not
a
like.
You
know
basic
building
blocks
approach
that
we're
currently
taking.
We
have
all
of
these
kind
of
proliferation
with
like
different
solutions,
sprawling
up.
C
So
one
of
the
questions
that
tied
into
this
was
well.
How
can
we
because,
like
I'll,
give
you
a
very
specific
example?
So
if
I,
if
I,
attach
a
label
to
an
issue
and
I
want
this
change
to
propagate
immediately
to
another
person?
Looking
at
the
same
issue
to
me,
this
is
not
a
graphql
trigger
conceptually
it's
a
domain
event
right.
The
domain
event
is
label
X
added
to
issue
y
right.
C
C
So
so
one
solution
to
this
could
be
that
and
I
think
this
could
even
happen
with
the
things
we
have
now
like
event
store
is
that
graphql
subscriptions
are
just
one
other
subscriber
of
a
domain
event
and
we
can
decouple
them
with
something
like
event
store
where
yeah
pops
up
basically
happens
through
something
like
redis.
You
know,
because
we
already
have
it.
C
That
could
be
one
one
option
and
all
you
do
is
subscribe
to
a
domain
event
and
how
this
then
propagates
or
is
consumed
is
irrelevant,
and
this
would
also
allow
us
to
get
rid
of
all
of
these
hard
dependencies
or
things
that
just
don't
belong
into
a
psychic
node.
And
this
has
all
kinds
of
benefits,
because
it
allows
you
to
modularize
code
base
better.
D
I
think
there's
very
these
domains
are
very
different
and
I
I
still
feel
like
you
can't
mix
them
they're
like
very
different
requirements
and
and
I
I
think
that
what
you're
talking
about
is
more
sort
of
from
rails
forward,
which
is
a
super
important
topic,
but
then
there's
also
kind
of
from
rails,
back
and
and
out
and
I
think
that
they
they're
two
separate
domains
and
we
should
treat
them
as
a
just
a
tiny
bit
of
History,
like
what
you
were
talking
about
reminded
me,
a
huge
amount.
With
my
with
my
last
company.
D
D
So
you
know
any
collection
news
that
if
it
lost
this
connection
needed
to
refresh
its
state,
it
would
effectively
go
fetch
that
from
the
same
sort
of
path,
but
on
on
a
restful,
API
and
get
a
list
of
items,
and
you
need
to
be
able
to
do
stuff
like
application,
Level
security
like
who
can
who
can
subscribe
to
this
and
who
can't
where
those
questions
are
very
different
on
what
I
was
talking
about
earlier
right.
So
that
I
think
they're,
two
separate
things,
but.
C
A
Because
I
think
it's
relevant
and
I
I
do
agree
that
these
are
the
separate
domains,
but
I
don't
agree
that
those
are
separate
things
because
I
believe
that
we
can
easily
build
them
on
top
of
common
abstractions.
I
can
imagine
that
all
the
real-time
stuff
is
going
to
be
built
on
top
of
first
class
events
in
a
rails
multi-code
base.
A
Whenever
you
add
a
label,
you
can
emit
an
event
in
a
group
real
time,
and
then
we
will
have
a
getaway
that
will
push
them
to
workers
that
can
distribute
them
into
proper
webhoop
channels,
for
example.
So
there
are
common,
abstractions
and
I
think
that
the
main
purpose
of
of
this
meeting
or
like
or
the
idea
of
mine
is
to
actually
Define
those
common
abstractions
to
make
sure
that
groups
like
real
time
or
gitlab
or
verify
building
gitlab
CI
events
or
things
that
observability
team
is
building
won't
need
to.
C
I
think
what
you
touch
on
is
basically
the
event
schema
right
or
how
an
event
should
be
shaped,
and
what
kind
of
events
exist,
because
that's
a
domain
problem
that
has
nothing
to
do
with
pops
up
or
or
a
red
is
Pub
sub
or
whatever
I
think
this
is
maybe
where
they
could
be
overlap,
but
then
how
these
events
propagate
and
what
technology
to
use
to
deliver
them.
This
is
maybe
where
then,
there
might
be
a
pretty
large
divide
between
the
kind
of
problems
so.
A
Those
problems
are
on
different
levels
of
abstraction.
The
common
level
of
abstraction
might
be
emitting
events.
The
next
common
level
of
abstraction
may
be
routing
events
to
proper
back
ends,
perhaps,
and
then
only
then
on
on
the
third
layer
of
abstraction.
You
may
really
actually
have
custom
implementations
for
different
use
cases.
E
And
I'll
briefly
about
things
that
we
were
starting
to
discuss
in
the
observability
group
as
well
and
I
think
Matthias
what
you
mentioned
was
like
if
we
could
eventually
enlist
what
the
problem
areas
are
and
the
domains
that
they
are
in.
That
would
be
great.
That's
that's
the
start
that
we
want
to
be
at,
but
then
being
able
to
also
establish
what
the
common
denominator
is
across
them.
I
think
that
is
something
also
that
we
need
to
like
come
down
to
as
a
part
of
this
effort.
Right.
E
I
think
it
kind
of
like
Narrows
down
the
scope
of
the
problem,
but
it's
much
much
larger
right,
because
there's
there's
things
that
could
leverage
an
event-based
architecture
outside
of
that
group
as
well
and
I,
think
the
work
that's
gone
into
event
store
is
like
amazing,
and
if
that
could
start
to
become
a
front-end
to
this
abstraction
that
you're
talking
about.
Then
that
is
a
good,
logical
conclusion
going
outside
of
this
right,
especially
from
the
observability
standpoint.
E
If
we
start
to
think
that,
like
Eventing
or
structure,
events
becomes
a
genetic
capability
that
all
of
us
can
use,
and
that
is
where
we
are
starting
to
think
about,
and
that
is
also
how
I
get
pulled
into
this
discussion,
because
there
were
mentions
of
some
of
this
work
already
exists.
Can
we
leverage
the
prior
art
that
exists
already
and
not
like
reinvent
it
from
scratch?
A
Yeah
and
I
believe
that
actually,
the
even
store
is
on
in
that
third
layer
of
abstraction
that
even
store
can
be
built
on
top
of
this,
those
common
abstractions
that
do
not
exist
already
and
because,
because
what
doesn't
exist
already
yet
can
actually
we
we
can
build
those
abstractions
in
a
way
that
almost
everything
can
build
on
top
of
them.
I'm,
not
sure
if
I'll
explain
this
well,
but
yeah.
F
So
the
the
purpose
that
the
event
store
was
created.
It
was
to
find
this
common
use
cases
among
all
the
different
Technologies
we
had
and
like
we
mentioned
the
web
books,
the
system
hooks
the
on
the
implicit
events
that
we
have.
You
know
service
object,
X,
just
fires
like
a
sidekick
from
a
domain
that
is
from
from
a
different
domain.
This
is
kind
of
implicit
event,
try
to
find
this
all
this
problem
and
make
them
explicit
and
find
this
common
abstraction
like
Ci
events,
is
another
example
where
you
know
the
all.
F
These
are
the
main
events
as
Matthias
was
saying:
okay,
some
model
changes.
You
know,
if
I
add
the
label
to
an
issue,
it's
it's
a
domain
event
and
if
we
want
to
have
in
the
future
CI
events
where
it's
okay,
if
I
modify
an
issue,
I
want
to
a
pipeline
to
be
triggered.
I
can
actually
just
leverage
those
domain
events,
regardless.
What
kind
of
Technology
we
use
so
I
wanted
a
domain
to
happen,
a
domain
event
to
happen
within
the
product
I'm
here
for
now,
I'm
just
kind
of
a
scoping
out
a
little
bit.
F
F
The
the
event
store
does
today
and
ideally
we
should
convert
all
this
existing
technology.
We
have
the
web
web
books,
the
system
Hooks
and
the
you
know
posture
receive
is
like
one
of
the
workers
does
like
a
million
of
things,
and
these
are
all
events
that
should
be
made
more
explicit
with
subscribers
and
I
think
that
by
first
solving
the
problem
within
rails
but
say,
okay,
we're.
B
F
F
You
know
from
from
the
outside
of
git
lab
and
maybe
have
some
subscribers,
so
this
I
think
then
would
be
the
next
step,
but,
as
we
were
saying,
we
should
also
like
if
we
go
into
the
details
about
the
implementation,
but
we
shouldn't
use
something
that
is,
you
know
whatever
too
generic
technology
you
know
to
solve
problems
from
within
the
rails,
app
with
the
could
be
a
lot
cheaper,
a
lot
simpler
in
terms
of
manage.
You
know:
infrastructure
management
like
Sidekicks
that
we
have
leveraging
a
lot
today.
We
have
a
lot
of
things.
A
F
F
Yes,
yes,
but
I'm
thinking.
The
problem
I
think
we
have
today
is
that
we
already
have
a
lot
of
Technologies
and
the
event
store
can
replace
these
Technologies
today
right
we're
just
not
doing
this
kind
of
refactoring
or
we
you
know
we
just
need
to
use,
adopt
that
a
little
bit
more
because
we
can,
in
theory,
like
rewrite
web
books
system
hooks
by
using
event
store
today.
There
is
no
use
case
that
we,
you
can
say:
oh
this,
can
it
can't
be
supported?
F
The
problem
might
be
like
if
I
want
to
be
notified
in
a
different
system.
If
a
user
is
added
to
a
group
like
some
kind
of
domain
event,
then
today
we
cannot
do
it,
but
I
mean
we
have
to
do
so
with
some
like
we
do
with
webbooks,
where
we
have
a
subscriber
that
listens
to
certain
events
and
fires,
an
HTTP
request
somewhere
else.
Maybe
we
can
do
that
like
the
way
we
do.
We
wear
books,
but
there
is
this
kind
of
connection
external
and
internal
that
is
missing.
B
D
D
You
can
scale
things
that
don't
need
like
persistence,
way
higher
right
and-
and
you
know,
if
we
just
built
this
straight
on
redis
like
say
you
took
sidekick
out,
you
know,
and
again
this
is
going
back
to
my
previous
experience
and
with
real-time
stuff
like
Reddit,
can
do
phenomenal
things.
I
think
sidekick
adds
a
lot
of
layers
on
that.
F
Today,
the
subscription
are
static
because
you
define
them
in
code
and
you
know
so.
A
subscriber
is
just
an
entity
sitting
in
a
domain
that
keeps
listening
to
all
events,
so
you
can
do
some
filtering
with
you
know
conditional
dispatch.
You
can
do
that
if
they
are
cheap,
because
this
conditions
are
available.
B
F
F
Yes,
but
there
is
now
like
some
use
cases
that
are
emerging
today
like
which
are
actually
already
existed
with
the
with
the
web
books,
which
you
have
you
have
a
user
that
decides
to
enable
webbooks
for
specific
events,
and
we
persist
this
specific
kind
of
subscription
data
in
a
in
a
database.
And
then
we
say
when
this
event
is
fired.
They
say,
okay
for
this
project,
we
have
do
we
have
to
fire
a
Web
book
for
for
this
event,
if,
if
so,
we
we
fired
so
we
have
to
check
the
database
to.
D
A
I
think
that
event
store
is
the
great
first
iteration,
but
I
still
believe
that
it's
missing
a
couple
of
pieces
of
a
puzzle.
The
one
is
the
abstraction
for
defining
the
backends
like
side
Keys,
one
of
the
many
possible
backends
for
the
event
store.
The
second
one
is
that
I
believe
we
might
need
some
syntactic
sugar
around
how
we
emit
events
from
code
right
now.
A
It's
just
calling
a
perform
or
can
I
guess,
remember
exactly
method
on
on
the
class
yeah,
but
I
think
that
eventually
emitting
events
should
take
into
the
account
groups
like
there
should
be
an
even
group.
There
should
be
an
even
scope
and
only
the
event
is
just
the
last
thing
in
like
what's
being
emitted,
because
if
we
suddenly
start
adding
events-
and
we
add
hundreds
of
them
matching-
subscribers
is
going
to
be
incredibly
expensive.
A
If
you
do
that
in
a
way
that
events
are
equal,
then
it's
it's
much
different
so
and
then
of
course
Dynamic
subscriptions
and
if
we
could
actually
fix
those
things
and
deliver
the
next
iteration
for
the
event
store
with
especially
those
abstract
gateways.
That
will
be
the
domain
code
to
implement
all
the
separate
use
cases
for
different
groups.
Then
it
will
be
actually
something
really
really
really
good,
but
I
think
those
things
are
still
not
there
and
of
course
we
don't
have
this
documented
anywhere.
C
I,
don't
know
if
that
helps,
but
if,
if
we
just
think
about
this
problem
at
this
stage
more
like
an
event,
routing
problem
than
an
event,
delivery
problem,
I
think
maybe
it
might
be
easier
to
come
up
with
this
common
abstraction
and
the
reason
I
say
this
is:
it
seems
to
me
just
hearing
between
the
lines
there's
so
many
like
what
Andrew
touched
on
as
well.
The
devil
is
in
the
details.
Right.
Do
you
want
an
event
to
persist?
C
You
know
or
Kafka
plants
in
the
participant
of
all,
but
maybe
you
don't
even
want
that
if
you
don't
use,
if
you
don't
do
event,
sourcing
or
something
I
already
know
for
our
real-time
architecture
that
is
currently
being
built,
even
we
have
an
at
least
once
delivery
guarantee
or
that's
what
we
kind
of
shoot
for.
We
don't
expect
it.
Individual
events
are
stored
right.
C
These
These
Are,
the
crdts
are
stored
temporarily
until
the
session
concludes,
and,
and
that
is
the
source
of
Truth
and
once
the
session
completes
that
all
goes
away
and
then
some
final
state
is
the
database.
So
so
we
don't
need
persistent
events,
for
instance,
but
if
we,
but
but
we
can
I'm
saying
this
because
I
think
we
can
make
the
problem
but
ignoring
all
of
this
for
now
and
first
coming
to
some
kind
of
agreement
on
what
what
the
entry
points
should
look
like.
C
What
should
the
schema
look
like
how
do
I
even
publish
an
event?
How
do
I
root
it
to
a
different
subsystems
and
that
could
be
Pub
sub?
That
could
be.
There
could
be
graphql
some
kind
of
a
listener
that
fires
graphical
triggers
or
something
else
entirely
that
I
don't
need
to
know
about
I
guess
arcade's
example.
It
could
be
something
in
observability
and
and
leave
that
first
to
the
stage
groups
that
also
have
all
that
knowledge
or
like
what
needs
to
happen,
and
if
we
find
that,
then
there
are
more
commonalities.
C
A
A
When
you
have
some
concrete
implementations,
you
can
triangulate
with
to
build
those
abstractions
and
right
now,
I
believe
that
we
have
enough
concrete
implementations
to
triangulate
the
proper
abstractions
graphql
events
triggers
web
hook
system
hooks
audit
events,
gitlab
CI
events
that
there's
a
lot
and
that's
why
I
believe
it's
actually
a
good
moment
to
try
to
translate
those
abstractions
for
me,
like
I,
have
some
model
in
my
head,
and
it's
for,
like
this
model,
is
fairly
simple.
It's
you
emit
an
event
you
define
to
which
Gateway
is
going
to
be
rooted.
A
The
gut
way
still
written
in
Ruby,
can
receive
that
and
then
push
that
for
further
processing,
that
to
a
service
or
a
module
or
a
class
in
gitlab
that
is
being
owned
by
a
team
like
there
can
be
a
very
specific
implementation.
You
can
persist
those
events
there,
if
you
need
to
you,
can
you
can
you
can
push
them
outside
of
gitlab?
If
you
want
to
and
like
there
are
many
possibilities,
so
yeah.
C
I
like
this
approach,
because
this
would
immediately
solve
my
question
from
earlier,
which
is
how
would
this
work
with
self-manage,
because
whatever
we
come
up
with,
if
this
runs
in
the
rails,
monolith
or
if
that's,
where
events
originate
from,
which
maybe
that
maybe
I'm
jumping
to
conclusions
here
but
I
would
imagine
most
of
the
domain
events,
because
most
of
our
business
logic
is
in
the
rails.
Monologue
would
originate
from
the
rails
monolith.
C
So
this
needs
to
work
and
self-managed
and
if
Pub
sub
is
not
available
to
a
customer
that
this
needs
to
kind
of
degrade,
gracefully
right,
so
that
this
would,
if,
like
using
your
gateway
analogy,
this
might
just
not
exist.
But
then
maybe
that
step
is
to
scale
right.
So
so
the
event
will
propagate
to
other
subscribers,
for
instance,
whether
that
be
even
store
or
something
else
or
graphql
trigger,
but
but
maybe
not
in
these
external
systems,
because
they
simply
don't
exist
right.
If
I
yeah.
A
C
I
I
just
want
to
add
one
more
thing:
I
think
what
I'm,
also
trying
to
get
with
at
with
this
is
as
a
developer.
I
don't
want
to
have
to
think
about
this,
like
if
I,
if
I
fire
a
domain
event
because
effect
happens
in
the
gitlab
system
at
I
cannot
be
expected
to
think
about.
Oh,
this
will
go
to
Pub
sub
and
oh,
this
will
require
this
graphql
trigger
this.
This
is
this
is
not
going
to
end
well.
E
I
think
the
key
that
you
mentioned
Matthias
was
that
one
right
like
building
the
subtraction
is
going
to
be
super
hard.
So,
instead
of
focusing
that
or
like
trying
to
solve
for
the
wrong
problem,
it
would
be
much
prudent
to
establish
what
that
protocol
looks
like.
So,
if,
if
we
were
to
just
segregate
the
problem
in
three
steps,
it
looks
like
publish
transport
and
routing
and
then
subscribe
right,
like
that's
the
only
sane
definition
of
the
problem
and
then
if
we
leave
the
end
users
to
what
their
definition
of
public
publish
looks
like.
E
Of
course,
you
can
tween
a
tune
across
pack
and
saying
my
back
end
is
Google
pops
up
right
now
my
backend
is
Kafka,
my
backend
is
ready
pops
up
and
that
could
change
depending
on
what
the
implementation
looks
like,
but
as
a
general,
an
event
Eventing
system
or
whatever
this
is,
could
be
published.
Transport
subscribe
and
and
like
going
back
to
what
Rick
Ross
mentioned
about
event,
store
I
I,
actually
researched
through
the
things
that
bring
event
store
to
life.
E
So,
like
Fabio
great
work
on
that
actually
read
through
the
191
comments
that
went
into
bringing
that
thing
and
it's
a
great
job.
It
does
a
very
great
job
with
the
things
that
were
present
at
the
moment
right.
So
it's
very
contextual
in
that
sense,
but
it
also
kind
of
differs.
The
discussion
that
we
are
having
like
down
the
road
and
I
think
we've
kind
of
reached
the
stage
where,
like
deferring
this
decision
further,
actually
adds
to
the
problem
instead
of
moving
away
from
it
right.
F
E
F
F
F
You
know
inside
the
event
store
where
you
still
use
the
event
store,
but
then,
rather
than
rooting
things
to
sidekick,
you
can
do
synchronously
or
you
can
do
async
using
Kafka
or
whatever,
but
there
is
already
a
level
of
abstraction
that
within
the
rails
application
you
can
just
keep
using
that,
and
you
don't
have
to
you
just
have
to
from
a
publisher
perspective.
You
have
to
just
emit
an
event
and
you
don't
care
like
where
that
goes,
and
then
from
a
subscriber
perspective.
F
Currently
there
is
sidekick,
but
like
again,
this
can
be
if
we
suddenly
think
that
we
can't
use
that
kit
for
some
reason,
and
then
we
have
to
use
something
else.
We
can
build
an
adapter
abstract.
That
said
kick
layer,
so
existing
subscription
remains
as
they
are,
but
now
we
have
another
way
of
subscribing
to
that
event.
F
So
building
I,
in
my
opinion,
will
be
best
to
build
on
top
of
what
we
have
today,
because
I
did
already
that
kind
of
work
of
thinking
of
all
the
problem
or
all
the
various
ways
of
we
do
today
from
again
within
a
context.
I'm
not
I,
didn't
want
to
solve
all
the
problems
with
with
domain
events.
I
did
I
want
to
solve
the
problems
within
the
rails,
application
that
caused
a
lot
of
coupling.
C
I
think
that's
a
fair
point.
You
may
because
it's
also,
you
know
in
the
spirit
of
iteration
and
everything,
but
can
we
frame
this
and
I
like
the
way
Ankit
framed
it
like
these
four
different
problem
areas.
We
were
very
likely
gather
around
right,
because
these
are
the
core
issues
that
we
all
need
to
solve.
C
If
we
start
thinking
from
that
angle,
could
a
good
first
step
then
be
to
review
event
store
because
because
honestly
I
haven't
even
used
it
myself
right,
I,
I,
read
the
documentation
and
I
looked
at
the
implementation
and
I
appreciate
all
that
that
work,
but
I,
probably
don't
even
have
a
a
reasonable
opinion
right
now
on
whether
it
checks
all
these
boxes.
But
what
a
reasonable
First
Step
then
to
be
to
write
down
how
we
would
expect
these
four
core
areas
to
operate
and
then
just
review
event
store
against
it
and
see.
A
And
I
think
that
that
is
definitely
a
good
idea
to
extend
even
store
that
exists.
Today.
I
mentioned
that
I
believe
that
it's
missing
a
couple
of
pieces
of
a
puzzle
like
abstract
Got
Away
the
dynamic
subscriptions,
but
in
order
to
actually
see
that
we
should
start
writing
a
blueprint
about
how
we
want
this
system
to
look
like,
and
then
we
can.
We
can
look
at
the
even
stores,
implementation
and
the
blueprint
and
understand
what
is
missing
there
and
we
can
add
it
I'm
not
saying
that
even
store
is
not
a
good
solution.
A
It's
just
incomplete
solution
and
perhaps
built
on
a
slightly
different
level
of
abstraction,
but
we
can
push
it
down.
We
can
extend
the
scope
of
the
abstraction
layers
covered
by
event
store
and
it
can
be
actually
very
useful
implementation,
but
my
point
is
that
we
should
probably
start
with
writing
a
blueprint
about
how
we
want
this
to
look
like
what
are
the
abstract
gut
ways?
Why
do
we
need
them?
F
Yeah
I
mean
it.
The
event
story
is
not
a
complete
solution
and-
and
it's
been
even
in
in
the
merge
request-
was
declared
as
like.
This
is
just
like
a
first
implementation
and
it's
meant
to
find
the
common
abstraction
among
the
existing
use
cases
we
had
at
the
time.
So
now
we
might
have
different
use
case,
so
that
means
like
okay,
we
have
to
extend
it.
F
C
I
also
want
to
give
that
a
plus
one
that
we
need
to
write
it
down
somewhere,
like
what
are
we
looking
to
solve
here
and
I
I
touched
on
the
problems
we're
facing
earlier,
but
that
sounded
very
different
from
what
others
need
to
solve
and
that
might
be
disconnected
a
bit
disconnected
at
first.
But
I
think
it
would
help
us
kind
of
shape,
like
I,
think
I'm
gonna
use.
A
A
F
A
A
B
A
E
Okay,
probably
going
round
in
circles,
but
just
as
a
concluding
dot
I
think
in
my
head,
like
events
store,
happens
to
be
a
concrete
implementation
of
this
interface
that
we
are
talking
about.
It
could
be
doing
a
majority
of
the
published
part
in
some
parts
of
the
Subscribe
part,
but
it
can
be
broken
open
into
the
three
stages
that
we
talked
about
right,
I,.
A
Think
this
is
this
is
aligned
with
what
how
my
mental
model
of
this
looks
like
right
now,
but
it
might
change
and
I.
Think
Fabio
is
going
to
challenge
my
ideas
in
the
blueprint
as
well,
which
can
actually
be
very
useful
for
us
and
I'm
looking
forward
for
discussing
all
the
all
those
details
with
everyone
who's
going
to
review
the
emerging
Quest.
A
I
will
share
some
details
about
the
blueprint.
Sorry
when
I
start
when
I
push
it
to
GitHub,
probably
the
next
week.
I
will
share
that
in
the
even
Store
working
group,
slack
Channel
I
think
that's
probably
this
live
Channel.
We
can
repurpose
here.
So
thank
you.
I
will
upload
this
recording
to
the
YouTube
unfiltered
and
I
wanted
to
thank
everyone
for
great
conversations
with
a
conversation
we
had
today.
So
thank
you
very
much
and
see
you
next
time.