►
Description
AsyncAPI Conference 2022 - Day 1
3rd November 2022
In this talk, Luke will describe the design, build, and operation of a cross-domain event distribution service at The LEGO Group. The cross-domain event service is part of a production workload powering global e-commerce at massive scale, running on the AWS public cloud. A novel approach to standardising event schema and payloads that utilises AsyncAPI and CloudEvents will be presented. We will also explore the use of web standards in cross-domain event production, such as JSON Patch for data marshaling and JSON Web Tokens for encoding and encryption of payloads. We'll explore how the use of AsyncAPI tools supports the delivery lifecycle of this system, including Modelina for automated generation of type definitions and Generator for documentation. We will also see how AsyncAPI schema can be integrated with Spotify’s Backstage platform to simplify the onboarding of new event consumers through event documentation and discovery.
A
Hello,
everyone
great
to
be
here
today
at
the
async
API
comp.
My
name
is
Luke
I
work
at
the
LEGO
Group
as
a
lead
engineer
and
I'm
going
to
talk
to
you
today
about
cross
domain
events
with
async,
API
and
AWS.
So,
let's
dive
straight
straight
in
so,
let's
talk
a
little
bit
about
event-driven,
architectures
and
I've
broken
this
down
into
kind
of
two
phases.
A
What
we
tend
to
see
with
adoption
of
eda's
first
phase
is
very
much
about
events
that
happen
within
your
domain
within
your
product.
Within
your
application,
we
make
our
inter-service
communication
event
driven
Service
as
far
as
an
event.
Another
service
consumes
that
event,
and
that's
that's
all
good.
A
That
gets
us
used
to
this
kind
of
event-driven
way
of
working
and
then
what
we
tend
to
see
as
our
applications
as
our
eda's
maturing
and
scale
is
we
start
to
see
cross-domain
events,
so
the
main
a
sends
events
and
domain
B
consumes
those
events,
and
here
what
we
start
to
see
is
the
real
power
of
edas
begin
to
be
unlocked,
and
that's
really.
What
I
want
to
talk
to
you
today
about
is
those
cross
domain
events
and
how
we
can
manage
those
at
scale.
A
It's
a
little
bit
of
context
about
The,
Experience
I'm,
basing
this
talk
on
I
work
on
the
payments
platform
at
Lego
at
the
LEGO
Group,
and
we
were.
We
were
tasked
with
with
this
task
to
produce
Rich
payment
events
in
real
time
to
Consumers,
via
a
transport
that
that
is
convenient
to
them.
So
we're
going
to
look
at
each
of
those
little
pieces,
we'll
break
that
down
and
see
kind
of
the
sort
of
solution
that
that
we
put
in
place
a
little
bit
more
context.
A
So
these
are
the
kind
of
domains
that
that
we're
working
with
here
we've
got
the
payments
domain
in
the
middle
of
the
screen
there,
and
so
that's
kind
of
going
to
be
the
the
central
point
of
this
talk.
That's
going
to
be
the
producer
of
our
cross
domain
events
and
we've
got
a
couple
of
other
domains
here
in
the
in
the
flow
of
a
payment
and
an
order
on
lego.com.
A
A
So
before
we
had
this
event
driven
Nirvana,
there
was
an
existing
solution
that
was
very
much
a
pool
based
solution
where
pet,
the
baskets
domain
after
submitting
a
payments
request,
would
continually
poll
the
payments
platform
to
ask.
Has
that
payment
been
authorized
and
they
would
keep
asking
that
until
the
payments
platform
had
received
the
Upstream
event
that
the
payment
has
been
had
been
authorized
and
we
would
send
that
status
back
in
response
to
the
to
the
requests
from
the
baskets
domain,
and
then
we
can
see
there.
A
The
order
submission
would
would
continue
after
that
that
pole-based
pull-based
mechanism
puts
a
lot
of
emphasis
on
the
basket.
The
baskets
domain,
there's
inefficiencies
there
there's
there's
time
spent
for
a
shopper
on
the
on
the
checkouts
page
waiting
for
that
response
to
come
back
a
lot
of
things
to
a
lot
of
things
to
improve,
and
that's
where
pushed
based.
Event-Driven
mechanism
works
a
lot
better.
So
the
baskets
domain
would
submit
their
payment
request
as
usual
and
then
just
wait.
A
Wait
for
a
response
for
an
event
for
a
notification
from
the
payments
domain
that
that
payment
had
been
authorized
and
then
the
flow
continues.
So
this
is
the
event
driven
cross-domain
solution:
we've
We've
Ended
up
with
now
there's
a
few
properties
that
a
few
desirable
properties
that
we're
going
to
be
looking
for
as
we
build
out
across
the
main
event
driven
architecture.
A
The
transport
that
was
convenient
for
our
consumers
there's
lots
of
different
ways
to
deliver
events,
there's
lots
of
queuing
systems,
message,
Delivery,
Systems,
event,
buses,
and
it's
about
so
you
know
if
you're,
developing
your
own
solution
for
across
the
main
events,
the
best
tech
for
you
and
your
consumers
is
going
to
be
the
the
one
that
that
should
win
out.
What
we
didn't
want
to
do
here
in
our
case,
was
introduce
an
event,
delivery
system
that
was
unfamiliar
to
our
consumers
and
introduce
additional
Tech
person
upon
them.
A
Events
need
to
be
discoverable
well
documented.
This
is
something
we'll
we'll
look
closely
at
and
where
Ace
and
kpi
really
really
helps
us
out
and
standard
standards
is
so
important
when
we're
dealing
with
cross-domain
events,
it's
important
when
we're
dealing
with
inter-domain
events,
but
even
more
so
in
terms
of
cross
domain
events,
because
having
a
standard
way
to
design
Define
deliver
events
makes
them
interrupt.
Interoperable
makes
them
portable
across
systems.
A
Security
is
super
important,
especially
in
the
domain
that
we
were
looking
at
in
a
kind
of
dealing
with
payments
data,
but
whenever
we're
delivering
messages
across
the
main
in
particular,
security
is
really
important.
We
need
to
protect
any
data.
That's
in
those
events
in
those
events
treat
any
data
as
as
sensitive
in
in
this
respect
and
because
the
event
is
likely
to
be
received
via
a
public.
Endpoint
messages
need
to
be
verifiable.
A
A
A
Most
of
us
are
going
to
be
familiar
with
that,
but
this
is
really
book
on
the
industry.
Standard
for
defining
asynchronous
apis,
just
as
open
API
has
has
served
as
well
in
terms
of
synchronous,
apis,
request
response,
apis,
async,
apis,
really
shining
when
it
comes
to
asynchronous
apis
and
there's
this
growing
ecosystem
of
tools
for
building
these
these
event,
driven
apis
and
and
for
operating
them,
and
that's
what's
great
about
async
API.
A
There's
this
whole
Community
around
there
and
I
feel
like
we're
really
just
at
the
beginning
of
of
what's
possible
here
and
it's
great
to
be
a
part
of
that
and
and
being
a
user
and
a
contributor.
So
that's
that's
really
great
and
if
you
haven't
tried,
our
async
kpi
definitely
go
ahead
and
do
that
after
after
the
conference
here
we
have
a
a
small
example
of
what
an
async
API
schema
would
would
end
up.
A
So
it
definitely
became
the
obvious
choice.
There
was
no
new
tech
to
introduce
and
internally
within
the
payments
domain,
we
already
had
events
flowing
through
our
private
event,
buses
that
we
could
subscribe
to
and
and
transform
and
send
on
Downstream
and
another
key
benefit
of
eventbridge.
Is
it
allowed
us
to
Target
AWS
workloads?
So
we
could
Target
go
from
an
event
bus
in
our
account
in
our
AWS
account
into
an
event.
A
So
we
can
see
here
again
a
very
simplified
example,
but
we've
got
the
payments
public
event
bus
defined
there.
We
have
the
target
of
the
buckets
public
event,
bus
and
buckets
baskets,
sorry,
public
event,
bus
and
the
event
pattern.
So
we're
saying
here
send
all
events
from
payments
through
to
the
baskets
domain
that
match
this
event:
type
payment
authorized,
Ecom
or
e-commerce.
A
Cloud
events
deals
with
the
the
the
payload
of
an
event
that
the
the
event
data
itself
and
it
gives
us
a
common
way
to
define
all
the
fields
in
in
that
payload
and
event.
Payload
is
is
often
this
kind
of
unstructured
Json
object
or
and
and
and
and
you
know,
the
the
keys
used
were
completely
up
to
the
producer.
A
So
a
lot
of
these
things
will
will
look
familiar
so
the
first
thing
we
had
to
do
when
we
decided
on
on
these
various
Technologies
and
and
specifications.
We
had
to
kind
of
Trace
our
way
across
this
across
the
three
specs
and
find
the
commonality
map
the
map
between
the
fields,
the
field
names
that
would
defined
in
each
in
each
spec,
and
that
would
give
us
that
consistent
thread
across
across
each
of
these
across
each
of
these
things.
A
So
you
can
see
here
we
have
this
concept
of
channels
and
a
channel
in
async
API
and
that
Maps
very
neatly
to
the
concept
of
of
rules
in
eventbridge
and
in
terms
of
the
type
of
event.
We
see
message
properties
of
the
message
in
async
API
mapping
to
a
detailed
type
in
eventbridge
and
a
subject
in
Cloud
events
and
the
the
payload
itself
in
async
kpi.
A
We
kind
of
we
would
Define
the
payload
within
the
the
properties
key
under
under
message
of
Enbridge
cause
that
detail
and
Cloud
events
calls
that
data
and
time
is,
is
more
or
less
the
same
across
eventbridge
and
Cloud
event.
But
this
was
really
key
to
us.
Unlocking
our
understanding
of
how
the
definition
of
an
event
could
be
consistent
and
and
coherent
across
these
these
three
things.
A
So,
on
the
left
hand
side
here,
we
have
our
event
sources,
and
these
are
internal
to
our
domain
to
to
the
payments
domain.
So
events
really
could
be
coming
from
anywhere
within
our
within
our
domain
and
indeed
they
could
also
be
coming
from
external
sources
such
as
our
third-party
payment
providers.
A
A
A
We
send
that
off
to
a
an
AWS
service
called
Step
functions,
which
is
essentially
a
state
machine
based
workflow
engine,
so
you
can
imagine
just
a
flow
of
of
different
transformation
steps
on
the
data.
In
that
event,
obviously,
if
we
remember
back
to
the
previous
Slide
the
fields
mapping,
the
structure
of
the
event
payload
in
eventbridge
is
is
very
different
to
the
the
cloud
events
structure.
A
So
what
we're
doing
in
this
workflow
is
is
mapping
that
event
Bridge
event
payload
over
to
the
cloud
events
payload,
which
we're
going
to
push
out
to
our
consumers
and
the
second
kind
of
Step
that
we
have
in
that
step.
Functions.
Workflow
is
a
kind
of
encryption
step
using
Json
web
tokens
and
we'll
get
into
the
detail
of
that
a
little
bit
later.
So
once
those
events
are
transformed
and
encrypted,
we
send
those
on
to
the
public
of
Empires.
A
Now
the
public
event
bus
is
where
we
have
rules
set
up
targeting
our
Downstream
consumers,
so
that
could
be
the
baskets
domain
or
any
other
domain
that
was
interested
in
in
payments
events
and
again,
that's
all
rule
driven.
So
we
saw
that
example
of
a
rule
with
the
the
baskets
domain
subscribe
to
payment
authorized,
Ecom
e-commerce
events.
A
Let's
look
at
Discovery
next,
so
big
part
of
of
allowing
our
consumers
to
to
discover
are
the
main
events
is,
of
course,
documentation
to
discover
and
adopt
those
events
and
consume
those
events.
Documentation
is
obviously
super
important
and
we
wanted
a
way
in
which
we
could
automatically
generate
documentation.
That
was
really
clean,
really
simple
and
had
examples
in
there
as
well,
because
examples
make
such
a
difference
when
you're
talking
about
API
documentation.
A
lot
of
it
can
seem
abstract
until
you
see
that
concrete
example.
A
Luckily,
for
us,
we
defined
our
event
driven
API
using
an
async
API,
so
an
async
API
provides
a
generator
tool.
You
can
generate
tons
of
different
things
with
that
tool,
but
you
can
all,
but
you
can
also
generate
HTML
pages
that
end
up
looking
like
this,
so
we
take
our
async
API
spec
and
we
generate
an
HTML
website
based
on
that
spec.
A
We've
done
that
at
Lego,
and
so
once
we've
once
we've
created
our
async
API
specification
generated
our
documentation.
We
can
upload
that
to
the
base
plate
and
that's
accessible
to
any
other
Engineers
within
Lego,
but
not
publicly
accessible,
so
offers
offers
out
of
the
box
discoverability
and
Security
on
on
that
documentation.
A
A
A
We
can
we
see
some
really
powerful
filtering
patterns
applied
internally
within
our
domain,
but
also
for
our
consumers.
They
can
be
as
granular
as
they
need
to
be
when
subscribing
to
events,
so
you
could
subscribe
to
all
payment
events
or
events
about
a
particular
entity
or
domain.
You
could
subscribe
to
all
authorized
events
within
that
payments
domain
or
you
could
be
very
granular
and
say:
I
just
want
to
subscribe
to
the
e-commerce
payment,
authorized
events
or
the
point
of
sale
authorized
payments
event
a
really
powerful
technique
there.
A
A
A
A
And
and
in
terms
of
then
circling
back
to
the
async
API
version,
the
version
of
your
event-driven
API
that
then
can
be
incremented
accordingly.
So
if
you
have
introduced
a
new
event,
you
would
tend
to
move
to
the
next
major
version
updates
to
events.
We
can
stay
on
the
same
major
version
and
increment
the
minor
version
and
any
fixes
to
events
or
to
end
points.
We
would
see
that
as
a
as
a
patch
version.
A
A
Format
and,
of
course,
as
well
as
just
to
kind
of
transforming,
there's,
there's
also
usually
enrichment.
We
want
to
derive
values
of
fields
from
other
fields.
We
want
to
change
and
operate
on
on
certain
of
certain
field
values
and
often
to
achieve
this,
we
need
to
introduce
a
lot
of
kind
of
custom,
business
logic
and
there's
a
ton
of
ways
to
do
this.
A
So
Json
patch
comes
with
a
number
of
different
operations.
We've
listed
them
here,
add
remove,
replace
copy
move
so
pretty
much
everything
you
would
need
in
terms
of
enrichment
of
and
transformation
of
event,
payloads,
and
you
can
you'll
be
seeing
an
example.
Here
of
of
this
apply
patch
method
being
used
from
a
Json
patch
Library.
We
take
the
impound
of
we
take
the
inbound
event
and
we
apply
the
transform
patch
to
the
to
the
to
that
inbound
event.
A
So
if
we,
if
we
take
the
order
ID
field,
for
example,
this
is
how
it
would
come
to
us
in
the
top
level
order.
Id-
and
we
see
here
on
the
the
third
line,
the
of
the
patch.
We
have
the
operation
to
move
the
order
ID
from
that
root
field
to
the
nested
part
at
slash
data,
slash
order,
ID,
so
pretty
simple
operations
there,
but
this
has
given
us
now
a
standard
way
to
to
express
those.
So
any
Engineers
coming
to
update
this
and
they
can
read
it
understand
it
immediately.
A
Event,
IDs
is
another
thing:
I
want
to
touch
upon
here
so
again.
This
is.
This
is
a
key
piece
of
information.
In
your
event,
it
identifies
your
event
uniquely,
and
you
know
you
can
choose
a
wide
array
of
of
different
values
to
to
kind
of
generate
an
event
ID.
But
what
we
sell
done
was
a
spec
called
ulid,
universally
unique
lexographically,
sortable
identifiers
and
there's
a
there's
a
couple
of
really
cool
things
about
these.
So
they're
base
32
encoded.
A
Foreign
potency
is
another
topic
you
can't
avoid
talking
about
in
terms
of
of
event-driven
messaging
and
particularly
cross
across
the
main
events.
So
we
in
the
payments
domain
as
event
producers
in
this.
In
this
example,
we
we
had
a
situation
where
we
could
not
guarantee
exactly
once
message
delivery,
and
that
was
for
a
few
different
reasons.
You
know
third
parties
couldn't
offer
us
the
same
guarantee
or
Services.
Were
you
using
within
AWS,
couldn't
offer
that
guarantee.
A
So
we
had
a
situation
where
we
could
be
sending
the
same
event
to
our
consumers
more
than
once
so
we
had
to
give
away.
I
had
to
give
our
consumers
away
to
to
know
if
they'd
already
seen
an
incoming
event
or
not.
So
they
would
check
the
event,
have
I
already
seen
it.
No
okay,
Carry
On
processing
it
yep
I've,
already
seen
it.
Okay,
that's
fine
I,
don't
need
to
continue
processing
it
and
we
we
put
an
item.
A
Point
item
potency
key
in
our
every
single
event
we
send
to
our
consumers
and
the
value
of
that
key
has
to
be
deterministic,
so
it
has
to
be
the
same
for
every
single
instance
of
that
event.
Even
if
the
event
is
sent
multiple
times,
the
event,
ID
could
be
unique,
but
the
item
potency
key-
must
be
exactly
the
same,
and
this
is
what
a
consumer
can
verify,
whether
they've
already
seen
an
event
I'm
with,
and
we
use
an
md5
based
content
hash
for
that.
A
A
A
A
Is
it
safe
and
secure
to
process
it,
and
so
when
we
sign
our
event
payload,
we
do
that
with
a
private
key
and
we
share
the
corresponding
public
key
with
our
consumers,
and
they
can
then
verify
that
that
signature
with
our
public
key
and
then
we
encrypt
that
signed
JWT
with
a
shared
hmac
secret.
Let
me
share
that
secret
with
our
our
consumers
and
that
allows
them
to
decrypt
the
event
once
they've
received
it,
and
another
bonus
you
see
here
in
the
bottom
right
is
that
that's
an
example
of
a
of
a
JWT.
A
So
it's
consistent.
It's
always
going
to
be
the
same
size.
It's
highly
compressed
compared
to
you,
know
the
Raw
event
and
that's
kind
of
an
added
bonus
of
using
jwts,
obviously
we're
using
them
for
for
security,
but
that
encoding
and
that
compression
is
really
useful
when
you're
transmitting
data
of
a
variable
size
to
to
Consumers
over
and
over
the
network,
yeah
testing.
Another
super
important
topic
really
in
in
terms
of
across
the
main
events,
we
kind
of
used
a
varied
testing
strategy.
Linting
was
a
big
part
of
that.
A
We
can
also
validate
event
payload,
so
we
were
looking
at
the
enrichment
earlier
and
we
can
also
Define
our
events
as
Json
schema
documents,
and
when
we
enrich
our
events
and
when
we
produce
our
event
payloads,
we
can
then
validate
that
enrichment
process
against
a
Json
schema
definition
of
our
events
to
make
sure
that
the
the
transformation
and
the
resulting
event
payload
adhes
to
the
rules
in
that
schema,
and
we
we
do
that
in
our
unit
tests,
pre-deployment
of
of
our
a
solution.
But
we
can
also
do
that
at
runtime
as
as.
A
Well
now,
it's
really
key
in
terms
of
testing
event-driven
systems
to
test
your
integration
points.
We
kind
of
see
two
types
of
integration
Point
in
terms
of
testing
integration,
points
that
we
can
test
at
build
time
via
our
infrastructure
as
code
tests
and
at
runtime,
where
we
actually
test
deployed
resources.
A
Foreign
contract
testing
is
another
really
powerful
approach
to
when
it
comes
to
testing
event-driven
systems
and
across
the
main
events.
So
what
we
can
do
here
is
put
an
event
contract
between
our
producers
between
our
producer
and
our
event.
Consumers,
and
essentially
a
contract
in
this
case,
would
would
be
the
Json
schema
document
definition
of
our
of
our
event,
and
we
place
that
in
a
central
registry
where
producers
can
distribute
the
contract
and
consumers
can
access
that
contract,
and
then
we
run
tests
against
those
contracts
from
our
our
systems
under
test.
A
Observability
now
it's
observability
really
works
in
tandem
with
testing,
so
the
areas
we
don't
test
or
or
very
difficult
to
test
an
event-driven
system.
We
make
sure
we
optimize
in
terms
of
monitoring
and
alerting
and
as
we're
running
on
AWS,
we
can
leverage
a
lot
of
service
of
default
service
metrics
to
monitor
the
health
of
the
resources
in
that
event
pipeline.
A
A
A
We've
looked
at
vent
Bridge
we've
looked
at
Json
patch
for
a
standards
based
event:
enrichment,
we've
looked
at
jwts
for
security
for
securing
our
event,
delivery,
we've
looked
at
test
strategy
and
and
how
we
balance
that
with
with
observability
as
well-
and
that's
all
I
had
time
for
you
can
grab
these
slides
by
via
this
QR
code.
And
if
you
like,
the
talk,
there's
there's
always
more
of
of
this
stuff
from
me
on
Twitter.
So
thanks
so
much
for
listening
and
I
hope
you
enjoy
the
rest
of
the
conference.
Goodbye.