►
From YouTube: 2021 06 16 EMEA Sharding Group Sync
Description
No description was provided for this meeting.
If this is YOUR meeting, an easy way to fix this is to add a description to your video, wherever mtngs.io found it (probably YouTube).
A
B
B
C
B
Now
started
30
minutes
ago,
but
just
to
caught
up
with
email,
to-do
list.
C
B
C
C
All
right,
we
are
past
time
to
start,
so
I
will
start
with
the
first
topic
there.
So
in
slack
there
were
requests
for
an
embedded,
sre
person
and
hoping
christopher.
Maybe
jerry
would
show
up,
but
I
will
follow
up
with
them
offline
and
ask
for
that.
Jerry's
been
joining
the
sharding
work
here,
but
he's
been
providing
some
expertise
for
us
right,
but
I
don't
think
he's
going
to
be
the
one.
C
That's
the
embedded,
stable
counterpart
for
us,
so
yeah
I'll
just
follow
up
on
that
and
see
who
and
and
when
we
can
get
someone.
D
No,
like
I,
I
think
it
would
be
great
to
have
someone,
but
I
think
we
also
need
to
be
mindful
that
the
infrastructure
department
is
swamped
with
probably
500
competing
priorities,
and
so
I
think
one
thing
that
I
will
try
to
review
is:
are
there
a
few
things
that
we
can
do
ourselves
already?
You
know
just
to
like
help
them
a
little
bit.
For
example,
I
think
we
know
that
we
need
security
approval
for
people
to
look
at
production
data,
I'm
sure
there's
a
process
somewhere.
D
Maybe
we
can
do
that
ourselves
and
that
kind
of
that
kind
of
stuff,
because
I
think
that
would
that
would
help
and
be
collaborative,
but
I
I
do
think
that
it
would
be
nicer
to
have
someone
in
the
team
that
can
help
us
work
with
this.
Rather
than
having
to
write
a
a
project
plan
and
say
like
this
is
the
specifications
of
everything
we
need,
and
you
know
somebody
who
has
some
time
and
capacity
to
support
that
would
be
great.
B
So
it's
only
like
their
demand,
actually,
the
it
will
benefit
both
teams.
For
us,
we
get
the
knowledge
we
don't
have
on
the
production
environment,
so
they
can
fill
in
the
hole
and
help
us
to
get
those
production,
related
tasks
articulated
and
down
together
I
mean
the
teams
will
collaborate
and
for
the
infrastructure
team
is
also.
There
are
also
benefits
that
they
will.
B
They
know
why
the
decision
and
how
we
come
to
those
conclusions
so
that
when
in
the
future
is
passed
to
production,
they
have
full
context
how
this
was
developed
and
they
know
how
to
also
they
gather.
You
know
warm
up
to
monitor
and
host
this
environment,
starting.
A
It's
actually
even
more
like
more
complex,
like
preparing
infrastructure
side
of
the
stuff
is
like
multi-month
process
for
them
like
preparing
for
the
migration.
It
means
like
running
five
or
six
different
shots
or,
like
I,
don't
know
how
many
of
that
and
we're
not
gonna,
do
it
alone
and
now
like.
If
we
just
prepare
like
a
beautiful
waterfall
plan
for
next
six
months,
they
will
simply
say
hey,
but
we
are
not
doing
this
like
that.
We
need
to
do
it
differently.
We
kind
of
delay
that
by
another
six
months.
For
this
to
happen.
B
D
It's
like
the
first
time
it
took
super
long
because
we
didn't
have
buy-in
from
infrastructure
the
second
time
we
actually
had
henry
and
scarback
like
there
all
the
time
and
they
could
actually
log
on
to
production
and
check
things,
and
they
knew
how
all
of
the
chef
things
were
configured
and
that
kind
of
stuff,
and
that
was
extremely
valuable,
and
I
think
I
don't.
I
think
what
would
be
important
is
to
be
clear
on
when
we
would
need
such
a
person.
D
The
latest
right,
because
you
know
if
we
meet
that
now,
I'm
sure
we'll
make
a
few
folks
scramble
to
find
that
if
we
need
it
in
six
weeks,
it's
probably
a
lot
easier.
I
think
that
is
something
that
I
would
like
to
understand.
C
Yeah
so
I'll
get
an
issue
going
and
copy
folks
on
it
and
get
brent
involved
and
he
can
start
figuring
out
who
is
best
to
help
support
us
and
ask
for
someone
to
start
joining
as
soon
as
they
can
right.
So
they
can
get
up
to
speed.
Maybe
their
involvement
is
nothing
other
than
observing
the
meeting,
so
they
can
kind
of
understand
the
big
picture
and
slowly
ramp
up
on
the
amount
of
time
that
they
spend
with
the
sharding
group.
So
fortunately.
A
Fortunately,
we
have
jaric
in
this
like
initial
period.
He
he
knows
a
lot
of
stuff
how
it
was
running
for
how
long
time
and
close
so
I
think
we're
going
to
be
fighting
so
far,
but
I
think
in
like
the
long
term
like
like
someone
doing
things
right
now
in
the
infrastructure
would
be
really
helpful.
So
I
think,
like
this
six
weeks
is
like
I
guess,
like
it's,
the
it's
like
the
max,
but
during
these
six
weeks
I
think
we
can
handle
the
coming
questions
ourselves.
A
C
C
D
C
All
right,
then,
bullet
point
number
two
tong
requested
and
I
agreed
I
already
have
the
mr
out
there
for
it
to
remove
the
working
agreement
for
due
date
and
confidence
level.
That
was
mostly
for
getting
the
pocs
off
the
ground,
so
we
could
decide
a
direction
so
angry.
You
know
it's
not
been
asked
for
so
clearly
not
providing
any
more
value
at
this
point
in
time,
so
the
mr's
out
there
to
remove
it
and
it
will
be
gone
today.
A
Yes,
actually
I
had
this
moment
yesterday
that,
like
I,
I
kind
of
got
to
the
point
that
I
wanted
to
gather
my
thoughts
about
like
different
initiatives,
especially
like
the
like
the
outcome
of
the
heroic
investigation
of
like
the
bloating
to
kind
of
like
catch
like
the
the
whole
direction
of
like
how
we
can
scale
database
in
steps
which
is
like
beyond
what
even
we
are
doing
with
the
decomposition
and
what
should
be
before
and
what
should
be
after.
A
It's
actually
like,
I
started
writing
that,
after
like
discussion
with
different
people
and
like
their
perception,
but
in
general.
This
is
like
that.
I
guess
like
from
what
I
see
like
the
bloating
is
like
essential
piece
to
understand
why
we
are
doing
that.
First,
the
composition
is
like
something
that
is
inevitable
for
the
minority
of
the
features
at
some
point,
but
right
and
like
it's,
probably
the
the
thing
that
I'm
kind
of
seeing
that,
like
once
you
do.
The
composition,
like
it's,
probably
very
easy.
A
You
get
to
the
partitioning
next,
because
you're
like
the
compost,
a
lot
of
you
break
a
lot
of
cycles.
You
uncovered
inefficiencies,
and
things
like
that.
So
you're
kind
of
on
the
on
the
wave
so
fixing
like
a
lot
of
structural
problems
long
term
but
really
like
the
starting
or
like
microservices,
is
like
a
last
piece.
A
We
still
have
like
a
lot
of
the
bloating
to
do
and
we
are
didn't
even
like
plan
properly
what
to
tackle,
especially
one
thing
that
I'm
kind
of
seeing
is
like
across
things.
It's
like
we
trying
to
retain
like
the
status
quo.
We
don't
question
why
we
keep
data,
we
don't
question
the
structures
being
used.
A
I
think
we
could
achieve
like
significant
headroom
just
by
questioning
decisions
made
in
the
past
on
the
if
they
actually
made
sense,
because
it's
kind
of
like
quickly
changing
with
the
growing
application,
like
the
iterations
that
we
are
taking,
so
I
would
actually
propose
like
the
kind
of
direction
of
like
looking
at
the
bloating
like
as
a
more
like
white
effort.
A
A
You
know
like
pick
the
right
one
pick
like
the
like
the
best
one,
because
right
now,
like
even
like
with
the
migration
partitioning
getting
to
the
partition
schema,
is
like
a
multi-month
effort
and
like
it's
easy
to
get
it
wrong,
it's
easy
to
break
like
a
lot
of
aspects
of
the
application.
That's
gonna
be
less
performant,
but
it's
kind
of
like
decision
made,
and
there
is
no
really
like
a
easy
way
to
turn
back
on
that.
A
So
I
think
my
perception
is
like
yes,
partitioning
is
needed,
but
it
should
be
like
in
the
in
the
order
that
we
can
actually
figure
out
the
best
partitioning
scheme.
So,
like
not
rushing
that
heavily,
I
mean
we
definitely
have
like
a
lot
of
easy
cases
for
the
partitioning
that
we
can
execute
today
that,
like
they
are
pretty,
I
guess
straightforward,
build
trade
sections
time
decay
pattern.
A
I
think
something
that,
like
we
discussed
yesterday
with
andreas
and
like
it's
clearly
something
that
we
could
basically
keep
like
three
months
worth
of
daytime,
like
don't
care
about
anything
about
that
anymore,
but
like
there
are
more
of
these
kind
of
tables.
But
this
is
like
easy
case,
but
it
doesn't
like
the
the
harder
cases
like
cibs.
A
I
I
think
that,
like
we
don't
have
idea
exactly
like
how
to
partition
that
yet
and
like
we
are
pretty
far
away
from
even
like
having
the
idea
how
to
partition
that,
because,
like
partitioning
by
the
hashing
function,
it's
not
the
greatest
partitioning
by
time.
Decay
has
its
own
drawbacks
or
designing
by
something
different
has
even
different
drawbacks.
So
I'm
kind
of
thinking
right
now
that,
like
the
basically
like
solve
what
we
know
right
now,
and
we
know
that
like
we
can
download,
we
know
that
we
can
decompose.
A
We
know
that
it
will
give
us
like
a
lot
of
headroom
and
then
like.
We
could
really
try
different
partitioning
schemes,
because
we
have
that
headroom
available
for
for
scaling.
Otherwise,
I'm
kind
of
like
worried
like
that.
We
may
end
up
with
something
long,
but
not
really
like
better
than
it
is
now
or
like
put
it
differently,
suboptimal.
C
So
I
totally
agree
with
you
and
it's
something
that
the
database
group
identified
a
while
back
is
like
hey
at
some
point
in
time.
We
should
really
look
at
the
architecture
of
our
database
to
see
if
we
are
doing
things
correctly,
where
we
can
optimize
et
cetera,
and
we
just
never
had
the
time
or
the
bandwidth
to
do
so.
So
I'm
fully
in
support
of
doing
this,
I
just
had
question
about
order
of
operations.
A
I'm
I'm
not
particularly
like
attached
to
the
order.
I
think
there
is
always
like
some
kind
of
wiggle
room,
I'm
just
kind
of
saying
that,
like
in
ideal
world,
this
would
be
my
preferred
order
of
doing
stuff.
A
We
are
not
living
in
the
ideal
world,
so
I
guess,
like
we
pick
what
we
know
and
like
what
we
can
do
right
now,
but
like
even
like,
let's
say,
if
we
squeeze
like
the
deep
bloating
on
the
ci,
we
still
have
some
time
to
do
the
bloating
of
the
things
that
that
are
known
to
us
today
before
we
actually
like
jump
into
the
composition.
So
it's
not
that
we
cannot
squeeze
some
de-bloating
today.
A
It's
maybe
not
gonna,
be
that
comprehensive
or-
or
maybe
it
shouldn't
be,
even
like
that
comprehensive
house-
you
would
approach
it
otherwise,
but
I'm
not
in
particularly
attached
like
very
strongly
to
the
or
there,
but
in
ideal
world.
I
think
this
would
be
like
my
preferred
progression
of
like
scanning.
The
features
like
partitioning
is
really
like
very
far
away
into
like
scaling.
A
I
know
like,
but
usually
like
what
you
want
to
apply
the
best
practices
you
know
at
the
given
moment
and
like
this,
we
should
do
it,
but
it's
also
hard
to
apply
that
for
like
for
existing
data,
because
it's
really
usually
like
very
long
effort
to
do
it.
So
we
need
to
figure
out
some
way
like
to
to
execute
that
for
existing
features.
A
So
I'm
kind
of
thinking
that,
like
like
some
of
these
steps,
would
be
basically
unified
for
the
new
features,
because
you
would
assume
that
you
know
that,
but
it's
very
likely
that
in
few
years
from
now
you
would
still
like
reiterate
on
that
yeah.
But
okay,
right,
like
you
still
like,
because,
like
I'm
kind
of
thinking
like
even
database
structure
like
you,
keep
adding
new
columns,
you
keep
adding
new
structures
after
some
time.
A
It's
gonna
be
bloated
anyway,
because
you
added
someone
in
your
future,
since
that's
have
optimal
ways
so
deploying
we
have
to
happen
at
some
point.
The
question
is
like:
how
important
is
it
becoming?
I
think
right
now
we
are
in
this
space
that
we
have
so
many
bloated
features
that
we
are
kind
of
overwhelmed.
With,
with
that
alone,
this
kind
of
puts
like
a
lot
of
emphasis
on
the
face
number
one.
D
Yeah,
but
maybe
I
missed
something
here,
but
if
I
understood
you
come
here
correctly
like
for
me,
it
was
never
the
case
that
we
would
only
do
decomposition
and
that
would
that
was.
It
was
always
clear
that
we
would
have
to
do
multiple
things
and
to
increase
our
sort
of
scalability
and
that
it
depends
probably
a
little
bit
on
what
kind
of
feature
you're
looking
at
what
you
can
do
first
and
how
how
impactful?
That
is
right,
but
I
think
for
for
ci,
for
example,
we
correct
me
from
wrong.
D
We
believe
that
decomposition
is
the
one
of
the
top
strategies
to
address
this,
but
we
looked
at
merge
request
or
like
the
logs
webhook
logs
right.
We
didn't
need
to
decompose
that
we
just
did
something
else
and
was
also
efficient
right.
So
I
think
it's
a
little
bit
of
a
look
at
this
and
then
decide
what
the
right
order
of
operation
is
and
what
to
do.
But
it's
likely
not
going
to
be
just
a
single
thing.
A
Let's
say
like
we
order
stuff.
The
composition
of
the
web.
Boot
clocks
is
speed
on
the
table.
We
should
not
like
be
like
that.
It's
people
might
grow
significant
in
the
data
storage
over
time.
Just
because,
like
we
move
that
away
problem
away
right
now
because
of
the
easy
data
structure,
it
feels
like
it
still
like
significant
amount
of
the
data
storage
used
by
our
database
in
our
database,
so
archives,
type
of
the
storage.
D
A
Now,
if
we
stop
at
the
decomposition,
we
simply
quickly
run
into
problems
again.
If
we
don't
do
partitioning
but
like
logs,
they
are
already
partitioned
they
to
some
extent
already
like
deep
loaded
because
of
the
way
how
they
are
stored.
A
We
may
execute
on
like
on
the
under
the
composition,
to
make
it
easier,
but
now,
like
another
example
like,
let's
consider
that
we
do
workflow
clocks,
we
do
the
composition
of
the
weapon
clocks
because
of
the
time
leaking
pattern
by
not
migrating
data
at
all.
We
just
start
writing
to
the
new
database.
You
kind
of
like
making
the
composition
significantly
easier
to
execute
because,
as
part
of
the
decomposition,
a
lot
of
effort
is
really
like
into
migration
to
happen.
A
So,
yes,
like
this,
it's
kind
of
flexible.
It's
like
the
ideal
world.
You
are
not
living
in
the
ideal
world.
The
thing
it's
like
this
is
like
the
steps
to
get
into
constant
state,
so
you
could
probably
like
look
at
each
of
the
picture
category
through
the
steps
and
see
like
how
how
much
you
are
in
the
comfortable
state
based
on
the
scalability
of
this
each
feature
and
then
figure
out
which
one
is
the
more.
D
D
D
We
are
there
for
supporting,
but
please
go
ahead
and
do
this
right
and
then
for
whatever
else
next
category
something
similar
right,
because
I
think
then
there
is
maybe
some
ability
to
to
fan
out
that
kind
of
work.
I
think
the
blueprints
will
also
be
helpful,
because
new
features
should
be
designed
with
all
of
those
considerations
in
mind
by
now
right
and
I'm
not
sure
they
always
are,
but
that's
just
my
lack
of
knowledge.
A
My
perception
is
like
it's
impossible
for,
like
even
like
providing
guidance
like
how
to
decompose
and
partition
features,
because
we
don't
know
exactly
how
we
want
this
to
look
like
we're.
Gonna
know
that
in
like
nine
months
from
now,
once
we
complete
this
project,
what
we
really
know
now
we
know
that
we
can
download,
and
this
is
something
that
we
should
push,
because
this
alone
will
take
a
lot
of
effort
and
time
for
things
to
execute
upon
and
and
then
like.
A
The
next
steps
comes,
which
is
like,
I
don't
know,
maybe
the
composition,
maybe
partitioning
you
pick
the
the
right
one.
Maybe
we
will
define
the
partition
in
the
the
single
database,
but
there
is
also
like
the
trickiness
how
you
can
how
you
want
to
roll
out
that.
But
I
guess
like
these
are
the
implementation
details
that
we
need
to
go
through
and
figure
out
how
to
best
approach,
and
we
are
very
far
away
from
from
that.
A
A
So
there
are
a
bunch
of
the
things
that
we
could
probably
kind
of
like
spread
out
today,
alongside
the
composition
effort
on
the
particular
feature,
but
only
like
in
about
few
months,
we
will
have
more
details
like
how
it
could
be
executed
by
other
teams.
C
All
right,
I've
already
reduced
this
meeting
to
30
minutes.
It
was
previously
scheduled
to
an
hour,
so
any
other
topics
folks
want
to
cover
today.