►
Description
Don’t miss out! Join us at our upcoming event: KubeCon + CloudNativeCon Europe in Amsterdam, The Netherlands from April 17-21, 2023. Learn more at https://kubecon.io The conference features presentations from developers and end users of Kubernetes, Prometheus, Envoy, and all of the other CNCF-hosted projects.
A
All
right,
hello,
everyone
and
welcome
to
this
session,
how
to
build
serverless
event,
driven
microservices
systems
with
calyx,
so
in
this
session,
really
what
I'm
going
to
be
showing
you
is
the
how
to
build.
Like
the
title
says,
the
event
driven
Parts
I'm,
really
going
to
be
focused
a
lot
on
event,
driven
design
and
I.
Think
what's
going
to
be
interesting,
is
some
of
the
kind
of
guided
design
driven
approach
to
this.
A
This
process,
where,
because
of
some
of
the
ways
things
work
in
an
event-driven
system
and
also
with
calyx
and
just
the
realities
of
doing
distributed
systems,
things
like
that,
there's
I
think
there'll
be
some
surprising
outcomes
of
what
it
actually
takes
to
do
in
an
event
driven
design
like
this
I
know
it's
for
me.
A
It's
been
an
amazing
about
a
year
now
doing
this
with
calyx
and
finally
getting
into
something
where
I
can
stick
my
teeth
into
building
event
driven
systems
I've
been
talking
about
it
and
doing
it
to
some
degree
for
for
some
years
now,
I've
been
talking
about
event,
driven
at
conferences
and
blogs
and
webinars,
and
things
like
that.
But
now
because
of
of
Calyx,
it's
gotten
so
much
easier
to
do
it.
It's
it's
a
it's
quite
amazing.
A
So,
let's
get
going
so
like
I
said
we're
going
to
dive
pretty
deeply
into
event-driven
design
in
this
session.
So
it
would
help
if
you
have
some
familiarity
with
calyx
I'm,
not
going
to
go
into
a
lot
of
the
details
that
I
often
do
in
many
of
the
other
videos
and
content
that
I
produce
around
produce
around
calyx
in
this
video.
So
if
there's
something
that
I'm
not
covering
here,
there's
plenty
of
other
resources
to
find
I've
done
a
bunch
of
videos.
A
Other
people
have
done
videos
on
calyx
and
you
should
be
able
to
find
and
of
course,
there's
a
documentation.
So
you
should
be
able
to
find
the
some
of
the
basics.
But
here
this
is
a
bit
more
advanced
and
we're
going
to
go
into
the
design
now.
I've,
never
fear
if
you're,
not
that
familiar
with
calyx.
Yet
this
is
really
about
kind
of
the
fundamentals
of
Designing,
a
vent
driven
systems
and
and
that
process
so
I'm
not
going
to
get
into
code
or
or
things
like
that.
A
This
is
really
about
the
conceptual
process,
so
I'm
going
to
be
walking
you
through
the
design
of
this
demo,
application
that
I've
been
using
for
a
while,
now
and
I.
Think
it's
a
really
good
representation.
I
wanted
to
dive
deep
into
the
design
of
this
for
a
long
time
and
I've
kind
of
covered
it
to
some
degree
in
other
videos
that
I've
done.
But
this
time
I'm
going
to
go
pretty
deep
into
the
flow
here,
and
it
was
really
interesting
for
me
to
to
walk
through
the
process
and
also
kind
of
share
with
you.
A
My
experience
as
I
was
working
through
the
design
of
this
and
I
was,
and
actually
what
was
happening.
I
was
unlearning
things
that
I've
known
for
years
about
building,
say
stateless
crud,
like
you
know,
crud
types
of
systems
that
building
that
those
types
of
systems
for
decades
and
agree
to
get
into
an
event-driven
type
of
a
process
and
design.
A
It
really
kind
of
I
had
to
kind
of
let
go
of
some
things
that
I
just
took
as
just
almost
kind
of
intuitive
ways
of
doing
things
and
kind
of
you
know
rewire
my
brain
to
to
do
things
in
in
a
more
event
driven
way.
I
can
I,
hopefully,
you'll
see
that
it's
great
fun
your
head
will
hurt
I
think
the
first
time
you
do
it,
but
there's
some
patterns
that
you'll
see
here
that
not
only
apply
to
this
application,
but
you'll
see
the
same
recurring
patterns
in
other
event-driven
applications.
A
This
is
certainly
what
I'm,
seeing
in
the
other
things
that
I've
been
doing
along
these
lines
in
completely
different
applications,
but
the
processes
there's
this
kind
of
nice
pattern,
that's
emerging
that,
like
I
reuse
over
and
over
and
all
the
the
designs
that
I've
been
doing
so
to
start
out
when
I
first
started
working
with
calyx
and
I
was
learning
it
myself,
which
wasn't
that
long
ago,
because
calyx
is
new,
I
was
really
doing
demos
on
a
shopping
cart.
A
You
know
the
classic
shopping,
cart
demo,
it's
interesting,
and
you
know
so
that
I
was
building
a
service.
So
there's
the
circle
here
in
this
diagram
represents
a
you
can
think
of
it.
They're
called
entities
in
calyx,
but
you
can
also
think
of
it.
As
like,
a
small
microservice.
It's
a
self-contain
service
that
has
an
API
you,
you
interact
with
it
and
it
it
persists
data
to
a
database.
It
can
retrieve
data
from
the
database
those
types
of
things.
A
So
it
is,
you
know
you
think
of
it
as
a
as
a
a
tight
focused
Loosely
coupled
microservice.
That's
this
pretty
what
what
this
is
so
I
was
building
up
the
shopping,
cart.
You
know
adding
the
the
ability
to
add
items,
to
a
cart,
to
remove
items
from
a
card
to
change
items
in
a
cart
and
to
check
out
the
cart
and
I
was
kind
of
playing
with
the
the
programming
you
know
at
the
code
level.
A
You
know
what
I
was
doing,
how
I
would
write
the
code
and
things
like
that
and
I
was
you
know
so
I
was
learning,
but
then
I
was
getting
kind
of
bored
with
it
because,
like
okay,
you
know
shopping
cart,
not
a
big
deal,
but
yeah
I
started
thinking.
Well,
it
would
really
be
cool
to
do
something
more
interesting
like
what
about?
Okay,
we've
got
a
shopping,
cart.
The
shopping
cart's
been
checked
out.
So
what
about
implementing
the
process
of
allocating
stock
to
the
shopping?
Cart?
A
So
that's
where
I
started
to
build
up
so
the
first
thing
I
did
I
started
to
add
some
of
that
logic.
To
the
shopping
cart
service
that
I
had
built,
but
it
started
to
feel
like
it
was
getting
heavy
weight.
You
know
the
design
was
starting
to
smell.
You
know.
You
know
that
feeling
when
you
you
you're
doing
something,
and
it's
like
I'm
doing
too
much
here.
I
really
should
be
kind
of
breaking
this
thing
up.
So
what
I
did
was
I
introduced
a
second
service
that
I
called
order.
A
So
the
idea
was
that
shopping
cart
was
focused
on
building
shopping
carts
and
once
a
shopping
cart
was
checked
out,
then
it
would
emit
an
event
which
would
be
picked
up
by
the
order
service
and
the
order
service
would
create
an
order,
and
so
the
big
difference
here
is
that
you
know
with
a
typical
online.
You
know
shopping
system,
shopping,
carts,
could
get
built
and
then
abandoned
and
no
orders
are
getting
created.
A
So
you
know
that
data
is
interesting
to
analyze,
but
they're,
not
real
orders,
so
I
want
to
kind
of
have
a
a
kind
of
a
clear
delineation
between
just
the
code
in
the
services
responsible
for
handing
shopping,
cart
and
the
code
that
was
responsible
for
handling
orders,
so
that
checkout
event
is
a
significant
event
when
a
checkout
event
occurs.
The
shopping
cart,
basically
freezes
itself
it
it's
no
longer
possible.
The
shopping
cart
service
won't
allow
any
more
changes
to
the
to
the
cart
contents
because
it's
been
submitted
as
an
order.
A
So
when
an
order
gets
the
shopping
cart
now
the
order
goes
okay.
Now
we've
got
an
order
that
we
need
to
fulfill
so
in
the
order
service,
I
started
to
add
a
little
bit
of
like
the
life
cycle
into
an
order
service
and
what
I
mean
by
that?
Here's,
the
the
data
structures,
the
data
structure
is
simple
here,
but
here's
a
data
structure
of
a
shopping,
cart
and
you
can
see
the
main
thing
in
the
shopping
cart
on
the
left.
A
This
is
just
some
Jason
is
just
it's
got
a
card
ID
a
customer
ID
when
a
timestamp
4
is
checked
out
and
there's
a
deleted
flag,
but
sorry
about
that
and
then
there's
a
list
of
items
in
the
shopping
cart,
so
you
can
see,
there's
a
SKU
one
with
a
quantity
of
two
and
a
skew
two
with
a
quantity
of
three.
Now
the
order,
the
data
you
know
the
this
is
the
say:
the
object
that
the
order
is
or
the
state
that
the
order
is
is
building
it
has
a.
A
It
looks
very
much
like
the
shopping
cart,
but
it's
got
some
more
feels,
mostly
a
bunch
of
time
stamps.
That
kind
of
show
life
cycle
like
when
was
it
ordered?
When
was
it
shipped?
When
was
it
delivered?
Was
it
returned?
Was
it
canceled
those
types
of
things,
and
then
you
can
see
in
the
order
items
which
is
just
a
list
or
an
array
here
in
Json
there's
also
a
new
field
called
shipped
as
well.
It's
a
shift
timestamp,
so
I,
so
I
had
the
order
and
then
I
started
thinking
all
right.
A
Well,
what
do
we
do?
How
do
I
write?
The
code
in
this
way
doing
an
event
driven
type
of
approach
to
to
allocate
stock
to
an
order,
so
I
started
thinking
about
it.
I
didn't
start
really
implementing,
because
I
was
started.
I
was
kind
of
at
the
early
stages
of
the
design.
Okay,
what's
the
stock
order?
What
does
it
do
and
how
does
the
what's?
The
kind
of
the
Eventing
interaction
between
order
and
stock
order
so
to
right
away?
A
I
started
running
into
some
interesting
things,
so
here
I'm
taking
things
down
to
a
little
bit
more
level
of
detail,
so
the
circles
again
represent
the
microservices
which
are
called
entities
in
calyx.
So
this
is
a
order,
is
an
Event
Source
entity.
Stock
order
is
an
Event
Source
entity
and
what
happens
is
there's
a
there's,
a
this.
These
A's
there's
one
in
the
center
here
and
there's
one
right
on
the
edge
on
the
left.
Those
are
called
actions
and
actions
are
stateless
functions
and
these
V's
are
views.
A
These
are
just
queryable
views,
so
this
is
event
sourcing
and
cqs
command.
Query
responsibility:
segregation
where
the
commands
are
handled
by
the
service
entity
and
the
queries
are
handled
by
the
views
and
in
between
those
is
that
each
entity
has
an
event
room.
So
what
happens
is
that
the
action
is
a
function
that
received
that
checkout
message,
that
of
that
a
checkout
event
from
the
shopping
cart
off
to
the
left
side.
A
Here,
the
action
then
sends
a
command
to
create
a
new
order
entity,
so
the
order
entity
is
created
and
when
it's
created
it
just
simply
emits
an
event
like
order
created
event
which
gets
written
into
the
orders
adventure
and
then
that
triggers
that
event
is
picked
up
by
another
action
which
the
arrow
in
the
center
here
is.
This
action,
then,
is
responsible
for
taking
that
order
and
getting
stuck-
and
this
is
where
things
started-
to
get
interesting,
because
here
an
order
could
have
multiple
stock
items.
You
know
skus
to
that.
A
We
need
stock
for
and
we
need
to,
and
we
need
to
do
this-
you
know
transactionally,
you
know
we.
We
want
to
allocate
stock
to
the
order,
but
we
don't
want.
You
know
we.
We
want
to
make
sure
that
this
happens
precisely
and
doesn't
corrupt
the
data,
or
anything
like
that.
So
you
know
they
say
that
this
action
function
sends
a
command
to
the
stock
order
and
the
stock
order
does
something
you
know
to
allocate
stock,
which
emits
maybe
one
or
more
events
to
the
event
room.
A
But
the
the
challenge
is
that
the
problem
is
it's
like.
We
have
quantities
like
the
order
has
a
quantity.
You
know
that
skew
one
wants
a
quantity
of
two
skew.
Two
wants
a
quantity
of
three
and
the
challenge
here
is
that,
when
we're
doing
this,
we're
trying
to
you
know,
say,
consume
some
stock
like
I
need
two
of
this.
You
know
so
like
say
the
excuse.
A
But
this
is
not
a
a
durable,
totally
reliable
operation
and
the
reason
being
that
what
can
happen
is
that
the
event
of
say,
decrementing,
the
stock
that
will
trigger
the
decrementing
the
stock
and
getting
written
to
the
order,
the
stock
order,
event
Journal.
That
could
happen,
but
before
it
acknowledges
that
back
to
the
action,
the
action
is
waiting
for
all
this
to
happen,
so
that
it
knows
that
the
message
was
consumed
say
something
fails.
I
turned
everything
red
here,
something
fails,
so
the
action
goes
out
that
last
operation
failed.
What
the
actions
will
do.
A
Is
it's
just
going
to
do
a
return?
Whatever
the
failure
was
when
the
failure
is,
the
problem
is
resolved
and
everything's
back
online.
The
action
is
going
to
retry
that
operation,
and
this
is
where
the
problem
starts,
because
when
we
retry
the
operation,
we
need
to
make
sure
that
we
don't
decrement
some
more
stock.
A
A
If,
when
there's
a
failure
of
this
process
here
and
the
action
doesn't
acknowledge
or
if
it
or
it
says
there
was
a
failure
that
tells
calyx
okay,
we
still
haven't
processed
this
message,
so
it's
going
to
retry
it.
So
that's
what
it
at
least
once
delivery.
Is
that
what
it
means
is
that
every
single
message
will
get
delivered,
but
in
some
cases
some
messages
will
get
delivered.
More
than
once,
which
gets
into
the
next
point
that
I've
highlighted
here
that
that
the
consumer
of
these
messages
need
to
consider
item
potency.
A
They
need
to
be
item
potent
so
that,
like
in
our
case
when
we
do
get
that
same
hey,
we
need
to
allocate
some
stock
message
twice,
that
we
don't
keep
allocating
stock
over
and
over
and
over
again.
Until
you
know,
the
the
whole
operation
is
successfully
completed.
A
This
really
drives
things,
because
now
it's
like
okay
I
can't
do
it.
This
way,
I
need
to
come
up
with
some
other
a
way
of
of
Designing
the
system
to
to
handle
this
stock
allocation
to
an
order.
So
I
thought
right.
This
is
getting
complicated,
so
I
introduced
us
a
third
service,
a
third
entity,
a
college
shipping
order
and
in
shipping
order.
The
idea
was
that
order
is
just
kind
of
interested
in
the
full
life
cycle
of
handling
orders,
but
the
actual
process
of
allocating
stock
to
an
order.
A
The
solution
that
I
finally
came
up
with-
and
this
took
some
thinking,
but
but
now
that
I've
seen
the
pattern
like
this
is
one
of
these
patterns
that
I
see
a
lot
is
I
needed
to
take
things
down
to
another
level
of
granularity
and
what
I
mean
by
that?
Is
that
what
happens
here?
A
These
arrows
represent
flows
of
events
between
these
services
and
these
backwards
and
forwards
flows
between
some
of
these
and
I'll
walk
through
this
in
more
detail
in
a
moment,
but
what's
happening
is
the
shipping
order
gets
created
and
here's
an
order
and
here's
a
shipping
order?
The
shipping
order
takes
the
order,
but
you
can
see
that
there's
an
order
items
list
in
the
shipping
order.
Hopefully
you
can
see
it's
big
enough
and
then,
within
each
order
item,
there's
a
sub
list
of
what
I
called
order.
A
Sku
items,
which
is
the
this
entity,
this
new
entity
that
I
created,
so
you
can
see
that
for
an
a
given
order
item
for
whatever
the
quantity
is,
there's
a
an
Associated
number
of
individual
uniquely
identified.
They
each
have
their
own
ID
order,
SKU
items,
so
the
quantity
is
two,
so
this
has
a
two.
The
quantity
for.
The
second
cue
item-
skew
item
skew
id2.
The
quantity
is
three,
so
there's
three
order,
skew
items
so
what's
happening
is
that
the
shipping
order
gets
created.
Intermits
an
event
says:
hey
I
got
a
new
shipping
order.
A
So
what
What's,
Happening
Here
is
that
the
the
processes
the
design
process
is,
it
was
being
kind
of
driven
by
the
realities
of
at
least
once
delivery
and
item
potency
I.
You
know
I,
don't
want
to
consume
stock
incorrectly
and
and
not-
and
you
know
it
shows
that
it
has
been
consumed,
but
this
some
stocks
not
actually
needed
for
a
given
order
because
we
we
double
booked
it.
A
Basically,
so
I
want
to
walk
through
some
of
these,
these
four
things
and
a
little
just
a
little
bit
of
detail,
so
it
it
at
least
once
delivery
is
what
I
was
talking
about.
But
this
is
an
example.
That's
very
common.
In
other
approaches,
that's
called
at
most
once
delivery
and
it
most
ones.
Delivery
is
kind
of
like
this.
You
have
a
function
say
some
kind
of
operation
that
it
does
two
steps.
One
step
is
that
it
creates
an
event
say
in
an
event:
Journal.
A
The
problem
with
this
is
this
is
a
two-step
operation
and
I
actually
ran
across
somebody.
This
isn't
calyx
code.
This
is
from
some
other
some
somebody
else
and
I
got
a
I
did
a
screen
capture
of
this
snippet
of
code,
where
they
have
these
two
examples
and
I've
got
red
arrows
and
underlines
to
kind
of
show
what
I'm
talking
about.
But
you
can
see
in
this
code,
there's
a
Save
State
operation
and
then
there's
a
publish
event
operation
and
there
there
are
two
separate
steps.
A
It's
got
if
it's
kind
of
hard
to
see,
but
it
looks
like
he's,
got
two
very
expensive
cameras
in
each
hand
and
I,
don't
know
if
he's
made
it
or
not
to
me
it
doesn't
look
like
he's
gonna
make
it,
but
in
any
case
the
the
idea
is.
Maybe
he
makes
it
because
he
looks
pretty
tall
and
he's
got
long
legs,
but
I
don't
know
if
I'd
make
it
I,
don't
know
and
I
think
other
people
would
make.
A
But
the
point
is
that
this
Gap
here
is
kind
of
like
this
Valley
of
Doom
or
this
period
of
vulnerability
in
this
code
and
really
what's
happening
is
what's
being
put
into
production.
Then
I
think
this
happens.
A
lot
is
leaky
code
that
most
of
the
time
like
well
into
the
high
90s.
You
know
90
99
range
everything
works
fine,
but
every
once
in
a
while
there's
a
fair
that
happens
at
the
very
very
worst
time
somewhere
in
between
this
operation
and
the
second
operation.
A
And
now
you
have
data
corruption
that
the
the
code
obviously
wants
both
of
these
operations
to
happen.
But
it's
not
an
atomic
operation,
so
you're
kind
of
going
into
production
with
these
teeny
little
leaks
that
will
drive
you
crazy
I've
been
in
this
kind
of
situation
and
it's
not
a
fun
place
to
be
at
all.
So
the
solution
to
this
to
get
at
least
one's
delivery
is
that
the
functions
the
the
producer
simply
produces.
A
Whatever
they're
they're
producing
and
then
there's
some
other
process
running
on
the
side
or
in
the
background
that
is
consuming
the
new
data
as
quickly
as
possible
and
passing
it
on
to
the
consumer.
So
the
the
the
and
this
read
side
processes
I'm
calling
it
is
usually
if
this
is
a
very
coffee-like
type
of
operation.
A
You
know
Kafka
is
famous
for
he's
just
reading
by
offset
and
if
it
fails
when
it
restarts
it's
just
going
to
pick
up
where
it
left
off,
which
means
it
could
be
that
some
messages
that
were
sent
will
get
sent
again,
which
is
okay,
but
as
long
as
you've
designed,
you
know,
that's
going
to
happen
and
you
design
the
system
for
it.
Then
you
can
deal
with
it.
A
It's
an
item,
quoting
operation
and
what
I've
been
doing
in
the
test
code
that
I
write
for
these
calyx
services,
this
I
I'm,
getting
in
the
habit
of
always
writing
item
potency
tests,
I'll
set
up
the
service
I'll
get
an
entity
into
a
certain
State
and
then
I'll.
Send
it
a
command
to
make
a
change
of
state
so
and
I'll
make
sure
that
the
state
changed
the
way
I
want
it
and
then
I'll
send
that
same
command
again.
A
I'll
make
sure
that
the
state
still
looks
like
what
it's
supposed
to
be
so
I'm
I'm,
designing,
specifically
and
implementing
for
item
potency.
This
is
multi-transactional
as
well.
This
is
really
important
because
for
for
a
long
time,
we've
lived
in
a
world
where
we've
had.
You
know
this
wonderful,
comfortable
database
world,
where
we
have
these
lovely
Atomic
transactions,
but
when
you
start
to
build
distributed
systems
in
which
a
lot
of
us
are
now
with
microservice
systems
and
things
like
that,
you've
left
the
multi-transaction
world.
A
If
you
have
multiple
services
that
are
triggering
each
other
to
perform
State
changes
outside
the
bounds
of
a
transaction.
You
you
need
to
consider
these
things.
If
you
don't
you're
going
to
have
those
leaks,
those
little
buckets
picking
up
those
little
drops
of
water,
every
drop
is
a
unhappy
customer
is
unhappy.
Business
is
unhappy.
Manager
is
an
unhappy
developer.
A
The
other
final
thing.
The
fourth
thing
is
that
the
system
is
eventually
consistent
in
that
the
function
writes
an
operation.
The
data
is
in
the
journal.
It's
there
to
be
used
sometime
later.
This
readside
process
is
going
to
pick
up
that
data
and-
and
you
know,
send
it
to
the
consumer,
but
it
doesn't
happen
as
a
single
Atomic
operation,
it
happens
is
multiple
independent
operations,
which
is,
which
is
the
eventual
consistency
so
going
back
to
this
design.
A
This
is
where
things
get
interesting
and
I'm
going
to
walk
through
some
of
the
higher
level
parts
of
it,
and
then
we're
going
to
focus
on
the
the
the
Eventing
between
the
order,
SKU
item
and
the
stock
screen.
So,
like
I
said
you
know,
there's
a
client
clients
are
loading
up
their
own
shopping
carts.
You
know,
I
have
a
shopping,
cart,
you
have
a
shopping
cart.
Somebody
else
has
a
shopping
cart.
Each
one
of
us
has
their
own.
Our
own
instance
of
a
shopping
cart
the
state
of
each
of
our
shopping
carts.
A
Is
you
know
what
our
shopping
carts
look
like
and
when
somebody
presses
the
the
buy
button
that
triggers
an
event,
you
know
like
a
checkout
event
and
that
checkout
event
admit
is
emitted
by
the
shopping,
cart
and
there's
an
action
that
picks
it
up
and
sends
a
command
to
a
downstream
service.
In
this
case
order
to
say,
hey
order,
we
need
to
create
a
new
order
when
an
order
is
created,
intermits
an
event,
and
here
I
just
want
to
show
where
the
same
event
could
be
picked
up
by
multiple
consumers.
A
So
in
this
case,
there's
an
order.
Item
I'm
not
really
going
to
go
any
detail
on
this,
because
this
is
just
used
for
like
an
example
of
doing
queries
and
manipulating
data,
but
the
shipping
order
picks
up
the
the
event
when
the
shipping
order
picks
up
the
event
like
I
said
before
it
emits
an
event
and
says:
hey
I
got
this
new
shipping
order.
It's
blown
up
internally
the
order
items
into
the
order.
Sku
item
sub
list
that
whole
object
is
passed
to
the
action.
A
There's
an
and
that
action
take
kind
of
a
decomposes,
this,
the
single
shipping
order
into
the
multiple
order,
SKU
items
again
the
example:
two
are
two
order
items:
one
quantity
of
two
one
quantity
of
three:
that
means
that
that
action
is
going
to
send
fi,
send
out
five
commands
to
five
different
order,
SKU
items
to
be
created-
and
this
starts
a
kind
of
a
whole
Cascade
of
a
lot
of
concurrent
operations
that
are
happening
all
at
the
same
time
when
he
wrote
a
skew
item
or
discrete
items
are
created.
A
They
emit
events
which
then
start
a
process
of
trying
to
hunt
down
available
stock.
For
that
you
know
order
SKU
item,
and
this
is
where
I
want
to
dive
into
more
detail
of
how
the
interaction
occurs
in
an
event-driven
flow
between
the
order,
SKU
item
and
the
stock
screen.
A
If
you
graph
this,
then
I
think
this
is
one
of
the
most
important
things
is
just
kind
of
how
how
this
whole
flow
works.
So
I'm
just
going
to
walk
through
it
step
by
step.
So
we've
got
the
order.
We've
got
the
shipping
order.
Remember
again
the
shipping
order.
There
was
there's
multiple
order:
SKU
items
we've
taken
each
one
of
these
order,
SKU
items
that
were
built
into
the
into
the
shipping
order,
but
now
we've
created
individual
entities
for
each
of
these
order,
SKU
items.
A
So
what
happens
is
the
action
that
pick
that
sends
those
commands
to
or
to
SKU
item
create
a
new
order
screw
item
that
produces
an
event
that
event
gets
picked
up?
There's
some
views
that
pick
up
the
events,
but
that's
not
the
main
thing
here.
The
the
event
also
gets
picked
up
by
another
action.
Remember
actions
or
stateless
functions,
they're
kind
of
the
glue
that
ties
everything
together,
because
actions
are
the
things
that
can
do
things
like
perform
a
query.
So
in
this
case,
that's
exactly
what
this
action
does.
A
It
got
a
message
from
the
Avenger:
okay,
Alex
passed
a
message
and
invoked
the
function
to
say:
hey
I've
got
this
new
message
for
you.
The
function
gets
that
message,
and
the
first
thing
it
does
is
it
performs
a
query
against
this
View
and
this
view
is
set
up
for
doing
a
query
against
available
stock,
skew
items
for
a
given
stock
ID.
A
So
the
query
result
comes
back
and
there's
two
possible
outcomes:
either
there
is
available
stock
for
this
SKU
item
right
or
there's
no
available
stock.
If
there's
no
available
stock,
the
action
is
just
going
to
in
turn,
send
a
command
back
to
the
order.
Sku
item
and
say:
hey
put
yourself
into
a
backorder
state
right
now,
there's
no
stock
available
and
I'll
get
back
to
this
one.
In
a
minute.
A
However,
if
there
is
stock
available,
what
the
action
will
do
it
will,
it
will
grab
one
of
those
available
stock,
SKU
items
and
it
will
build
a
command
to
send
to
that
stocks.
View
item
service
and
the
the
service
request
is
I
need
the
order
screw
item
effectively
wants
to
join
with
a
stock
experiment.
We
want
to
identify
here's
a
specific
order,
skew
item.
We
want
a
physical
unit
of
stock.
Excuse
me
for
that
order
screw
item.
A
So
the
command
comes
into
the
stock,
skew
item
and
there's
two
possible
outcomes
here:
either
the
stock
Square
item
is
still
available
or
it's
not
so
it's
the
request
is
either
accepted
or
is
rejected.
Now
the
reason
this
can
happen
again
this
it's
the
eventual
consistency
that,
between
the
time
we
do
the
query
and
the
time
we
actually
get
the
command
into
the
stocks.
Again,
there's
no
locking
going
on
here
and
somebody
else
could
have
grabbed
that
stock.
Skew
item
that
this
command
is
going
for
and
it's
no
longer
available.
A
So
the
the
idea
is
that
the
stock
screw
item
is
the
single
point
of
processing
of
of
handling.
This
no
locks
are
required
because
it's
a
single
Rider
type
of
a
principal
here,
so
the
stock
screw
item
takes
that
command
and
if
it's
still
available,
it
will
accept
the
join
request.
If
it's
not
available.
A
So,
in
either
case
it
produces
an
event
that
gets
picked
up
by
a
third
action
which
is
taking
the
event
from
the
stocks
you
item
and
sending
a
command
to
the
order
securing.
If
the
join
was
accepted,
then
the
order
screw
item
is
updated.
You
know
what
state
has
changed
to
reflect:
yep
we've
we've
got
an
A
stock
screw
item
for
this
order,
Square
if
it
was
rejected.
A
A
So
this
is
the
way
the
system
works.
The
the
really
interesting
thing
here
is
that
we've
got
two
independent,
very
Loosely,
coupled
micro
Services
here
order,
SKU
item
in
stock,
skew
item
they're
both
making
independent
non-transactional
state
changes,
but
because
of
the
design
of
the
sequence
of
events
that
you
know,
I
designed
as
a
design.
You
know
the
the
designer
of
this
system.
They
come
to
a
mutually
agreeable
set
of
State
changes,
your
first,
the
stock
screw
item.
A
If
it
accepts
a
join
request,
it
changes
its
state
to
say
yep,
I
know
exactly
what
order
SKU
item
I
belong
to.
It
updates
itself
with
that
information,
then
that
stocks
item
admits
an
event
which
goes
back
to
the
order.
Sku
item
and
the
order
screw
item
gets
that
that
command
is
desire.
I've
got
a
an
available
stock.
A
Sku
item
I'm,
going
to
change
my
state
to
reflect
the
stack,
the
state,
the
status
that
I've
I've
been
allocated
stock,
so
it
the
nice
thing
about
this
is
that
each
one
of
these
services
are
really
simple:
there's
barely
any
business
logic
in
it.
The
the
kind
of
the
the
the
fun
of
this
is
the
actual
design
of
the
sequence
of
events
that
goes
on
between
these
two
things,
which,
honestly,
to
be
honest
with
you,
it
took
me
some
time
to
work
out
just
because
it
was
this.
A
This
was
one
of
my
first
exercises
to
go
in
this
much
detail
of
doing
it,
but,
like
I,
said
now
that
I've
I've
gone
through
this
I've
I've
seen
the
same
pattern
in
other
things
that
I'm
doing,
and
this
kind
of
sequence
of
events
where
you
come
with
up
with
mutually
agreeable
State
changes
is
getting
to
be
second
nature
to
me
now.
It's
it's
quite
easy.
A
Also.
The
Brilliance
of
this
is
that
this
is
a
dead,
solid
type
of
implementation.
Anything
can
break
here
and
when
it
recovers
itself
feels
it
just
picks
up
where
I
left
off
so
anything
to
break,
and
it
just
keeps
going
and,
of
course,
it
scales
and
and
all
those
other
things
and
because
of
the
way,
because
I'm
doing
it
at
a
kind
of
a
lower
level
of
granularity
I'm
not
doing
it
at
an
order
level
of
granularity.
This
is
all
happening
like
at
the
items.
The
individual
stock
items
that
need
to
be
allocated.
A
It's
a
high
degree
of
concurrency-
that's
happening
here.
So
in
a
real
system,
processing
lots
of
orders.
This
would
be
a
simple
database
operations,
we're
just
inserting
events
into
journals.
Those
events
are
being
picked
up,
sent
to
actions,
actions
make
decisions,
do
queries
that
that
type
of
thing
and
then
The
Individual
Services,
basically
perform
very
simple
non-locking
non-blocking
types
of
operations
and
the
system
just
kind
of
Screams.
You
know
screens
along
as
it's
doing
this
no
leaks
as
well.
It's
all
taking
into
consideration
at
least
once
delivery
means.
Every
single
message
will
get
delivered.
A
What
it
does
is,
it
does
a
query:
Against
The
View,
that
is
a
view,
is
there
to
to
look
up
back,
ordered
order,
SKU
items
by
SKU
ID.
So
if
the
query
finds
some
some
back,
ordered
SKU
items
or
to
skew
items,
it's
going
to
then
send
a
command
to
that
order.
Sku
item
and
say:
hey
I've,
got
some
stock
to
join
with
you.
A
But
you
know
there's
a
lot
of
symmetry
here
in
the
way
this
this
works.
So
that's
the
the
behavior
here
so
the
stock
SKU
item
you
know,
does
all
this
work.
It
emits
it
those
events.
You
know,
we've
seen
this
at
a
lower
level
of
detail
here
in
the
past
few
minutes.
The
order
skew
item
when
it
changes
its
state.
It
emits
an
event
that
goes
back
to
the
shipping
order
and
the
shipping
order
is
updating
its
state
to
reflect
individual
order
screw
items
that
have
been
allocated
stock
and
what's
happening
here.
A
You
can
see
like
this
is
on
the
left.
These
are
a
couple
of
the
order,
SKU
items
and
you
can
see
now
there's
an
artist
qid
underlying
the
first
underline
and
then
there's
a
stock
SKU
ID.
The
second
underline,
so
you
can
see
that
these
both
of
these
order
screw
items,
have
been
allocated
stock.
So
the
these
order,
SKU
items
emitted
an
event
with
this
information
which
goes
back
to
the
shipping
order
to
the
shipping
order,
hunts
down.
A
It
just
digs
into
the
order
items
list
and
then
the
order,
SKU
items,
sub
list
and
hunts
down
that
order,
skew
item
and
it
changes
its
state
in
there
as
well.
So
now
that
the
shipping
order
sees
every
change
as
different
units
of
stock
are
allocated
to
the
shipping
order,
and
then
it
can
monitor
the
progress
and
you
know
so,
for
example,
when
all
of
the
items
within
a
given
order,
skew
items
within
a
with
a
given
order.
Item
have
been
allocated
stock,
it
will
emit
an
event
that
says
all
right
skew
one
is.
A
We
have
all
the
stock
we
need
for
skew
one,
and
the
same
thing
would
happen
in
force
Q2,
which
means
that
the
shipping
order
is
emitting
events
which
are
updating
or
changing
the
state
of
the
order
item.
You
know
the
order
item
has
ship
dates
in
it
as
well.
So
the
whole
shipping
process
flows
back
Upstream
from
stock,
skew
item
to
order
SKU
item
to
shipping
order
back
to
order
to
show
that
the
state
of
the
order
you
know
have.
A
And
you
can
see
here,
you
know
all
the
the
the
ship
dates
our
time
stamps
are
are
updated
and
the
the
the
associated
order
has
that
shift
to
UTC.
It
was
kind
of
at
the
default
1970
time
stamp,
and
now
it's
at
a
you
know,
occurred
time
step
to
indicate
that
we
found
stock
for
for
all
this
order.
A
Another
thing
I
want
to
point
out,
though,
is
that
the
shipping
order
this
this
concept
of
lists
of
like
a
parent.
You
know
you
can
think
of
the
shipping
order,
as
kind
of
apparent
to
the
the
order.
Sku
item,
children
and
there's
kind
of
a
one-to-many
relationship,
and
this
this
pattern
of
having
the
parent
have
a
detailed
list
of
its
children
is
also
kind
of
a
recurring
theme,
because
this
provides
item
potency
as
well
when
a
say
stock
allocated
event
is
sent
to
a
shipping
order
for
the
same
order.
A
Sku
item
id
more
than
once.
Those
are
item
potent
operations
if
I
was
just
like
changing
a
counter.
That
would
be
impossible
to
make
it
as
a
or
not
impossible,
but
it
would
be
more
difficult
to
make
it
as
an
item
important
operation.
So
part
of
the
reasons
for
this
civil
list
is
also
to
handle
item
potency
as
data
flows
back
Upstream
from
the
order
SKU
items
to
the
to
the
shipping
order
and
to
the
to
the
order
itself.
A
So,
in
this
event,
driven
design,
these
things
are
really
important.
You
have
to
think
as
you're
going
through
the
design.
You
have
to
think
about
it
at
least
one's
delivery.
You're
you,
your
services
are
going
to
get
the
same
message
more
than
once.
How
do
you
build
an
item
potency
that
will
drive
your
design
I
this
every
time
I've
gone
through
design,
it's
more,
it's
kind
of
an
intellectual
exercise.
How
do
I
design
this?
How
do
I
unlearn?
A
What
I've
known
before
and
learn
something
new
and
redesign
my
flow
into
something
that
takes
the
realities
of
at
least
once
delivery,
which
is
great
because
every
single
message
will
get
delivered
versus
the
alternative
which
many
people
use,
which
scares
the
heck
out
of
me.
Is
that
they're,
using
at
most
once
delivery
or
some
kind
of
sloppy
retry
without
item
potency,
just
I?
Think
it's
a
nightmare
here.
You
just
kind
of
go.
A
It's
kind
of
like
go
with
the
flow
you're
gonna
work
through
the
design
process,
you're
going
to
run
into
something
and
you're
going
to
say.
Oh
man,
this
is
not
an
item
put
in
operation
and
my
I
think
the
the
voice
in
your
head
should
be.
You
need
to
make
it
item
potent
it's
like
Luke,
you
know
go
with
the
force
yeah.
You
know
that
it's
the
same
thing
Luke
go
for
item
potency
figure.
It
out.
A
You
know,
redesign
the
flow
so
that
you're
you're
dealing
with
the
reality
of
at
least
one
slavery
and
your
operations
are
item
potent
because
that
will
make
it
so
that
you
know
things
are
multi-transactional
and
also
you
have
to
consider
things
like
eventual
consistency.
I
showed
you
a
little
bit
of
that
as
well
that
the
you
have
to
to
consider
that
so
a
lot
of
the
event
flows
are
kind
of
Saga
type
flows.
A
Because
of
of
of
this,
these
realities
of
building
a
vent,
driven
types
of
systems,
and
that's
it
a
little
bit
hopefully
a
little
bit
quicker
session
here.
The
QR
code
is
for
the
excuse
me
for
the
GitHub
repo
of
this
demo
project.
A
It's
a
Java
version
of
the
demo
project
and
it
you
know
it's
the
one
I
use
to
test
and
play
with,
and
the
logging's
fun
to
watch
when
you
enter
orders-
and
you
know
things
like
that,
so
feel
free
to
grab
that
and
and
play
with
it,
and
you
know,
look
look
at
the
code,
the
code's
you
know
for
the
most
part,
the
actual
business
Logic,
the
code
is
pretty
straightforward.
The
fun
part
is
the
design
piece
of
it.
A
So
I
know
if
we
have
any
questions,
but
thank
you
very
much
for
your
time
and
I'll
hang
around
for
some
questions,
but
otherwise
we're.