okay so I think that we can start my
name is Oscar dudich and today I came to
talk with you the history of the project
France the worst even sourcing system so
this is me I brought with me today this
special award because we won with the
project France the title in the first
annual context and contest of for the
worst event sourcing
system but what's the single man without
the team so let me introduce also other
people that took part in that so this is
our development team the Morris is a
head of development Roy head of
operations and Katherine is the head of
product Michael is our
CEO Jordan is our head of sales and
Donnie head of compliance and of course
we had a uh stream team dedicated stream
team because we will be crossing a lot
of
streams and of course that's me and
because as you will know in a minute um
it appeared that to build the worst
event sourcing system you actually need
to know how to build event sourcing
systems because we wouldn't like to
accidentally even create the system that
would be good enough because for us that
wouldn't be a correct option so I'm one
of the commenters of the Martin which is
a net library that allows to use uh
pogress as event store and document
database and I was also working with the
first event store so event store DB uh
for some time and I'm also currently a
consultant where I'm not always teaching
people how to build the worst even
sourcing system sometimes I also teach
them how to do it properly but it of the
needs of the client of
course
so um to give you the example because
the the measurement of the success like
if you are winning is the quality of
your competitors right so we also had
competitors um the small
ones the organized
ones the creative
ones the weird
ones and we also had the competition
from the biggest cloud providers AWS
tried to beat
us uh of course Microsoft also wanted to
do it for some reason Google did not but
I think that they were just reasonable
because we they already know that we
will be hard to beat so let's start with
our first idea so the the idea that we
came
up and we gathered together because each
uh project even the worst one needs to
start from the Whiteboard we put a lot
of sticky notes we group together to
discuss that and eventually we came up
with such
architecture um if you don't know this
architecture then that's good for you
but let me explain it and one disclaimer
so I will use the George Orwell analogy
so what is bad for our project is
actually good for like a good practice
in general and what's good for our
project is actually a bad practice so
this will be a bit of twist but let's go
to our first idea so this architecture
might be blurry enough but so to make it
a bit more clearer then I blured some of
the stuff so Our intention was when we
are getting requests from the API then
the first thing that we do of course we
are loading data and there is no
surprise that we are loading this data
from the
database but then we are running the
business logic validating yada yada but
it would be too simple if we store the
result in the database right so we are
storing that in a queue and during the
the um this presentation I will be using
cka as an example because Kafka is
pictured the most as the the best which
is uh we'll see if it's the best option
for even sourcing but if I'm saying even
uh if I'm saying CFA then you can think
the same that the same would apply to
event Bridge Azure event hubs or any
other messaging streaming solution so
again instead of storing data in our
database we are immediately putting that
into the queue I'm almost sure that you
saw that on the internet
right uh because we inspired a lot by
that and then in when we are storing
this event then at some point with the
eventual consistency we are getting with
some delay uh the event and we are
handling it and after that we are
finally storing the result in the
database and let's start with the best
case scenario so how it is picture like
how it should work in general so let's
say that we were building the accounting
system or like the bank account and this
scenario shows that at first we are
recording one inflow and then we are
trying to withdraw twice the same amount
of money so in the perfect scenario so
not perfect for us because that would
mean that the system actually works and
we as I mentioned we don't want that so
the perfect scenario is that we are
getting the balance from the database
then we are appending new event to to
our messaging system and then the the
event is handled we are updating our
stating database we have updated balance
that's fine and then when we try to
withdraw money then we are doing the
same checking balance appending new
event as a result handling it and
finally updating database um
and in the end so the the last the the
last request should fail because we
don't have any money in our account so
we are getting balance it's zero we can
reject the request but reality luckely
for us uh it's a bit different so let's
say what can go wrong in this scenario
so I already mention eventual
consistency and let's try to have a look
how it can uh get into this game so we
are getting the First Recording uh the
inflow um this works the same way
appending even handling
it and uh updating the balance but if we
are withdrawing the first request then
of course we can withdraw the money but
in this case we already might have the
the delay between the event handler is
getting the event and and the the
another request is trying to run the
business logic so of course in some
systems that's not an issue maybe in
some CR not so critical or without a
huge traffic that could work but our
system will be of course really high
traffic high resolution High everything
so in that case if we are trying to get
the balance and the event handler didn't
update the state in our database then we
are having the wrong state so we our
business logic will be validated against
the stale data and that's the re as a
result we are pending the new event
because the balance wasn't updated and
in the wrong in in as a result if we
with the delay apply those two events
then we are getting eventual
inconsistency and that's perfectly fine
for our case because uh we want to have
the system that looks like it's working
but in the itical uh part it won't be
working so let's check another case so
item potency and item potency is a word
that you better watch out when you are
saying but for some reason we we have to
say I that's our systems are IDM potent
and IDM potency means that if we are
handling a specific request twice Thrice
or end times then it doesn't doesn't
matter how how many times we will handle
a specific request we should get
precisely the sem result so let's have a
look on our scenario so we are recording
inflow updating the balance but in this
case our cues so any Q they have the
retries mechanism and those retries
might happen for various reasons maybe
our service was not available maybe the
queue had some issue maybe we had some
temporary issue in our code and then
those messaging systems will try to
redeliver the message and once that
happen and if we didn't foresee that
then we might be handling that twice
Thrice or more times so in this case the
first inflow would be handled twice and
instead of getting $100 on our balance
we are getting 2 200 and not
surprisingly if we try to handle those
two other requests then the second
request won't be rejected because we are
again getting the wrong State because we
didn't assume that it might be the case
of course we could be uh using some
strategies about handling IDM potency
but I can guarantee you that they are
non-trivial and in our system so our uh
uh project France definitely we won't be
using them so we are getting item
noty and the third case that I wanted to
explain you and show why we believed
that this strategy and this architecture
is a great strategy for building the
worst event sourcing system is the event
ordering so this is the department store
and if you have a look on those
cues and if I put those TR three people
so we can try to guess which of them
will be handled
first you you don't know of course the
only thing about this cues in the
department store and the only fact that
always works is that the queue that we
are standing is the slowest one
right but here you can say that probably
if someone is standing in the same queue
then you can guarantee that this will be
uh this person will be handled after
after the person that is staring uh
standing up uh in front of them but
besides different cues you never know
because there can be like a change of
casier the paper in the drawer may be
finished and so on and so forth there
are many scenarios and that's the same
case for our messaging systems so if we
have a look on like cka then we have two
splits one is topic and the other one is
the partition and topic is a logical
split so we can think that our topic in
this example could be department store
and partition could be each of the cues
and in Kafka we only have the guarantee
on the partition level because this is
the physical how the data is laid out
but it's not only for Kafka any other
queing systems like in rabbit you can
also get the guarantee only in for the
specific queue not between the other
cues and of course that's not a rocket
science we can find a way how to and
find a strategy how to split our topics
and and
partitions um but that quite often is
non-trivial and of what I saw many
people forget about that and they are
not thinking about it just using the
default strategies and of course in the
project France we also wanted to use
those default strategies because why do
we have those cues like in the
department store to make the processing
faster because this is the tradeoff we
are trading of the either like I
mentioned consistency or the ordering
because we want to move the data faster
from one place to another but if we
don't know or don't care so like we
didn't care then it actually can be
really Troublesome an example example of
that is if we want to update the re
model then quite often those events can
change the order like there are many
cases even in Kafka like if you have the
pre-flight messages and you so that
means that if you are pending events and
you said that you it will be caching
like 10 10 messages before putting that
on disk then it can get out of order
because of the retries ETC or in the
rabbit mq I heard that the a lot of
people are having strategy that if they
weren't able to process the message then
they are putting it back on the Queue
and then trying to play a roulette until
they get the proper message so the
ordering might be broken and in our case
that's perfect scenario for us because
that's what we wanted to achieve we
wanted to ignore eventual consistency we
wanted to ignore the IDM potency and the
ordering we and as you see if we first
got the the bank account was opened then
that would work and then inflow recorded
but the reality is quite often that this
guarantee might not be fulfilled like
for example if you have your strategy
that uh each topic is different modu in
your services then between the services
you cannot guarantee the
order and of course we are getting the
events disordering which is what we
wanted to achieve because that's cool
that's great that's perfect case for for
us and of course some say and if you
search for the internet then say like
yeah okay but you know you are getting
the extreme frut you get the high
scalability yada yada and that's fine
because you can use the process managers
and you can compensate each of the
business operation and that's also what
we wanted to do
because process managers and handling
distribut processes is really needed
eventual consistency is nothing to be
scared of but if each of the business
operation needs to be handled like that
that you don't know whether your data is
consistent because your stale state may
be always stale and for each business
operation you need to provide the
compensation and then compensation for
that compensation then that creates some
nightmares like on you you can see on
the screen
but the worst thing that happened for us
after one year of development is that
Donnie and I mention you the head of the
compliance called me and said like hey
Oscar we have a
problem and it
appeared that to build the event
sourcing system you actually need to use
event sourcing system and what I just
described is not event sourcing it's EV
streaming
so the first thing was that okay that's
bad how we going to make and change the
transition if we cannot use all of those
anti patterns that I
described but in the end we thought that
wasting one year for development can be
like a bonus for for us for getting the
award so that's fine so we rolled up our
sleeves and we decided that we will
continue our effort and
so let's maybe discuss what's actually
event sourcing so event sourcing in a
nutshell is a really simple pattern so
we have the event store and event store
is a is a database actually
and it's focused on the recording and
handling our events and getting the
granular information about what has
happened in our business logic so the
first thing that we need to have is the
command so the request the intention to
do something and that should be business
meaningful like withdraw cash from
ATM because if we don't have this clear
intention then we won't know how to
record the meaningful event but
essentially that's still a web a request
that will probably came through our web
API so not nothing different from our
regular approach and the first
difference that we have is that we are
not getting the data from some C cash
from some other database because the
only dat the only state that we have in
event sourcing are our events so we are
reading all the events for the specific
stream and a stream is like a
representation of record once we got
those events then in memory we are
applying them one by one to get the
current state or being precisely State
at the certain point in time and once we
have it then again there is no
difference to any handling of the
business logic we need to validate we
need to uh run the business rules
Etc and the other
um and the other difference is that as a
result we are not updating the state we
are just appending another event to the
same stream that we got the events back
because as I mentioned events are our
state so this is a simple pattern and
that wasn't great for us because if it's
a simple pattern then building the worst
system can be really
hard but I already spoiled you the fun
because we made it
right so does that mean that we cannot
use cafka did someone lie in the
internet that's not possible that's not
happening right so let's think how this
confusion came from because when we are
dis describing event sourcing then most
of the resources are starting that event
stores are up and only lock and hello C
is up and only loog right that's
correct but and essentially most of the
implementations or even stor are up and
Only log so in that case people are not
lying but uh the up and only lock if we
have a look then is representing a set
of streams and streams as I mentioned
represent a specific records so for
instance if we have multiple accounts
then each account will have its own
stream if we have order shopping cart um
whatever entity that we have in our
system it will be represented by the
specific stream type an instance of that
object will be represented as a specific
stream so we could have a look on our uh
event store as logically like a key
value database where key is the record
ID and the value is the sequence of
events and if we think about it like
that then it's much easier to reason
what guarantee we can expect from uh
from event store because if it's a key
value database then we can expect the
similar guarantee that we have from any
other key value database bis
right and as I mentioned one stream one
record almost most of the time so maybe
we could use partitions from Kafka
because it looks almost like a stream
right so remember loading events in
Kafka you are subscribing to events you
are not loading them there is no API and
in any other messaging system actually I
didn't s such API of course you can do
some tricks with the um with the with
your code and
and made some wrapper around
subscription but yeah it's still the
case and this is the screen from the
Kafka block and it appeared that in
Kafka in total we can have 200 thousands
of partitions so if we try to put a part
a stream as a partition then how many
record we could have in our system
200,000 right so usually people are
putting like more than one record inside
the partition to went through that
because I I'm sure that if you try to
build like 200,000 partitions in cafka
then it wouldn't be extremely performant
but then if you try to load that data
from partition then you would be loading
not only your specific record but the
huge set of other records right
so does anyone recognize that what's
that anyone is using databases
here yeah Denise what's that oh I don't
know the answer that's right ahead log
or if you're using mssql server this is
the transaction log and in the middle in
each database relational database even
Raven Deb that there is there you can go
them and there and ask them is built
like that as a center piece of each
database is the right ahead log or
transaction log which is the log of all
operations that you have so insert
update delete it's getting first into
this app and only lock and then building
the tables updating inserting data so
from the perspective of the database
like tables are read models
actually and we could build it it in the
same way so event stores are also
databases so if they technically are
right ahead log and you can put events
one after another then that doesn't mean
that you The Logical split is
different so again log physical split uh
streams
logical and that's how for example even
store DB is built it just builds from
scratch you just start zeros and ones on
the disk like in any other databases or
you might implement it like in Martin so
for example keeping all the events in
the specific uh tables because keeping
data as for example Json B and other
information as regular columns because
all those metadata will be the same for
each of of the
event and let's have a look on the last
um and this time optimistic case so
optimistic concurrency so the final
piece of making sure that we are making
decision based on the latest state so
optimistic concurrency works like that
and it's not only about even sourcing
and even stores I really encourage you
to use anywhere with any databases
because any database can handle that so
it works like that when we two requests
that are happening in parallel at first
want to access the state then they are
getting also the version of the specific
state so in event sourcing it could be
like the number of events you have in
stream and then if you are sending that
I want to append new event then you can
say that the version that I saw is
version number three and database can
compare if it's the same as they have in
database and after that uh if those
versions matches then the save is made
and the record in this case event is is
appended and then if someone tries to
run after that and send that I made my
decision based on the version free then
database can say that no no no the
version now is four so your save
shouldn't be
made and actually all of that so
atomicity optimistic concurrency reading
your own rights creates a rock solid
solution so in even sourcing and even
Source we get a so really strong
consistency on rights and all the
guarantees and can we do optimistic
concurrency on cka maybe in the future
but I know that the the Fone is not
great so I will read priority priority
minor resolution unresolved assign
unassigned created in
2015 and last updated 2018 no not a
priority and
but actually kfka is okay is there
anyone's from
confluent here no then that means that I
might be still a speaker on the Kafka
Summit next
month because I really like Kafka
because it's a really good solution and
as I said I'm using kafa just to point
because most often it's picture like
yeah just use Kafka for even sourcing
because kka is a good tool even great
tool but for event streaming and it also
plays really well with event sourcing
because we can put as the Event Source
our event store so database and then
forward and use Kafka as integration
between our services so even sourcing is
about recording and storing business
facts and making decision based on them
so about durability and the quality of
your data
and even streaming is about moving data
from one place to
another and that's the main difference
even though all of that sounds
similar but really it's actually
not
so okay I think that I bored you a bit
with all those technical details then
let's get
Jordan and as I said Jordan
I told you that it's a head of sales
right but actually it's our hype manager
as you can see Jordan is able to deal
really well with people and Jordan
prepared the strategy for our product
because you already know that building
even sourcing system you don't need to
drop those guarantees like strong
consistency you can be still sure that
you are making decision based on the
latest state which is challenging if you
want to build the worst even sourcing
system right because it's actually not
that simple as it seem so we needed to
do some tricks so we wanted to build
something like a revolute because we
wanted to have like the good matching of
the domain just to show people that we
care about that we don't and of course
we wanted to be kind of also like a
Salesforce exposing apis API first Etc
and we also wanted to be like a uber but
no we we don't want to run taxes but we
just want to be running our business for
like 10 years and still not be
profitable yeah it's a good strategy for
the wor system and we also wanted to use
all clouds like all if there is any new
today we will use it right multic cloud
is the
goal and
we also want to be on premise because
why not like I heard like dhh is saying
that we should all be on premise right
then we will also be on premise why not
why not and we will also use
blockchain
blockchain um sorry that was our initial
strategy gen
Ai and all of that is creating a ticking
bump and thinking bomb is something that
we want to achieve because we want to
get a lot of money and thanks to this
money we can be cheating our
stakeholders like you know we are really
busy we need we are building a serious
product serious architecture when this
will be ready soon
soon and uh of course at some point even
the the most polite I wouldn't like to
use other words stakeholders would would
realize that we are cheating so we need
to do more so this is Morris as I
mentioned Morris is our head of
development
and our strategy will be to build our
own event store right because that's
what we are doing if we are choosing new
project and we want to build uh a new
project and use as a database relational
database then we are saying let's build
new relational database
right
no but for even store that's a common
case and I even went to NDC Oslo two
years ago you can check that on internet
and I show you how to build even store
in one hour and actually most of that I
built in a 25 minutes and then I was
doing claim jokes that you heard like
today right I mean no this was much more
technical but I just did a social proof
right for our stakeholders and so why is
it building our own event store so hard
so let's say that as I mentioned we want
to be um multicloud and on
premise then that means that we need to
support if either Cloud native databases
which are quite often
non-trivial and we need to also support
like for example
postgress or other database that we can
run on premise
and we of course want to start because
we are here in the NDC so we start with
the Net Technology but we won't stop on
that because we will also write our API
to uh to support also Java and nodejs
but
why and because Michael told us that it
will be much easier to get more people
to build the event store because and
handle and create our services because
each service can be run in a different
technology it will be easier to
hire maybe that's some strategy maybe
not only for the worst event sourcing
system but that will actually mean that
we will start with a simple event store
but we will need
to maintain all the implementations for
all those other services right and
that's quite common the case
and architecture and that that will be
another question for you I hope that
this time there will be someone that
know the answer so what's
that uh ex could you repeat onion onion
no it's not an onion I mean it looks
similar it's
Atlantis and Atlantis in the ancient
Greece was pictured as the the most
sophisticated culture the most
Innovative like the the best of the best
of the Technical Solutions and when I
thought about that when we were doing
those workshops that I saw you at the
beginning then I F like hell that looks
like a clean
architecture so we decided that we will
use the the clean architecture because
it looks like a maze it looks like a on
own and do you know what how Atlantis
has finished its lifetime then he told
that he's never been there he's not
lying and Atlantis sunk into the ocean
eventually and that's perfect case for
our scenario because we want our project
to eventually sunk but if they are here
like are there any like a clean
coders cool
then Denis could said like yeah we can
use use cases right because use cases
will allow to focus on the domain on the
business uh
Etc and if Denny told that but he
didn't then he would be actually right
but show me the use cases on those
screens I just took it from one of the
clean architecture codes like the
picture of course you can Implement
clean architecture differently but
that's the most common case like you
have the persistence and then you have
like migrations
translators and
infrastructure uh events tracking
validation yada yada so this is a
perfect scenario for us because we want
to make stuff complicated Mash together
hard to maintain and we want to be
circling
around and capup Theorem we also are
aware of the cap theorem because as I
said to make something work we need to
be sure that accidentally we won't
create the proper system right and the
cap theorem is saying that we cannot
have the system that is both available
and
consistent and also we are also
including the network partitioning which
means that we are we won't be losing
data on the
traffic and I mention you that we have
the strong consistency in even sourcing
and we can we have optimistic
concurrency we we know that if we are
making decision then we are making it
based on the latest state but that's not
the case for actually for the re models
because quite often not in all solution
but for re models we have this eventual
consistency and also for the
communication between Services we have
that and that's fine but we can do a a
bit of magic to spoil that as I
mentioned eventual inconsistency we can
have events disordering and we can have
item neny when our business and read
model can be broken so that's good
that's good and network partitioning I
already mentioned that we will be doing
multicloud and on premise see how Roy is
happy when he learned that he will be
needing to hosting
that and delivery guarantees so
exactly once delivery like a Holy Grail
like all all uh Solutions like Kafka
like a pools are like any streaming
solution is saying that if you publish
message then you will get it exactly
once but let's have a look how it is in
reality so if we are appending like
storing State and at the same time
trying to append new event then it might
be that we store the data in database
and when we publish then our service is
crushed and no message will be sent and
then we are getting inconsistent State
potentially then even if we manage to
send it then our Q May crash like
actually that happens really uh it might
be the case that it didn't crash but
maybe retention policy just kicked in
like the default uh retention policy for
messages in CFC I think two
weeks and then delivery might be CR
because our service might not be
available maximum number of rri has been
reached or any other reason like even
back in our code I mean we don't do
backs but we will in France
right and then if if we even get the
message then we might have an issue and
don't store the message so in in in
general getting at at least once
guarantee is really hard because of that
so because all of those cases in the
meantime can just fail which is good for
us so we could use outbox pattern but we
won't and let me tell you why because
outbut SP turn means that um you are
storing in your database your state
update together with the message in the
same transaction so either both state
and message are stored at the same time
or none of them so when you store that
into for example some table with the
messages or if you are using event
sourcing you just appended the event
then there is either some process that
continuously try to pull new messages
and forwards them or you can use some
CDC so push based notification and
forward them and all of those me
messaging system have built in retries
so they will be trying to continuously
retry and reprocess that but that
creates the item potency because it's
not that someone wants to spoil our
system like we did in in France right
people build those retries to make the
processing and ensuring that once you
send the message that you will get it
but technically that means that you want
like the exactly once delivery is
impossible only at least once exactly
once processing yes if you handle that
on application side which we don't
intend to do and so in instead of cap
theorem we will do the crap
theorem which means that we will ask our
Dev team to ensure that we have
100%
consistency 100% availability and
100% uh toleran for Network partitioning
I'm sure that some of you heard that
words from your managers right I did and
speaking about the managers
so we already know that we can build a
product model that won't help us to use
event sourcing we can use some strates
in architecture to make that harder but
that's not enough so we wanted to do the
product design and unfortunately the
next obstacle to win the worst event
sourcing uh system title is that
actually events are helping in your
running your business process because
those are screens from event storming
event modeling anyone is using
that yeah some of you so for others I
really encourage that you to check that
I mean at least if you don't want to
build the worst system right because
those techniques are like we are
grouping both business and Technical
people and we are starting to think
about the events so critical parts of
our system because business because
events are technically both um like
showing
the what's happening in the business
process and they can also be mapped to
the technical messages so that helps to
streamline discussion between business
and Technical people but luckily we have
Katherine because if we put the Kine
there then she can derail those
discussions right and we can have a
skewed modeling so for for instance we
can use the pattern like CR sourcing CR
sourcing is like we are doing CR but on
events so instead of having events like
transaction initiated payment method
selected payment confirmed fraud
transaction detected we will be just
storing transaction created upd updated
deleted so because of that we will be
losing one of the biggest benefits of
event sourcing so having the granular
business information about the process
but flattening that to just
understanding of created updated deleted
and then the subscriber will need to try
to guess what has
changed the other pattern that we want
to use is the other way rout so property
sourcing instead of having a single
event like for example user personal
data uh update updated or refined then
we for each of the property of this
event we will provide a dedicated event
so user first name updated user last
name updated uh user address change user
email change you can imagine how the
comp complexity or the how complicated
will be to handle all of that because we
will be adding a lot of such
events and the other anti patterns that
we want to use is passive aggressive
events did anyone of you heard that
phrase like the
the trash bin is
full or that the dishwasher has finished
cleaning none of you okay I did so
passive aggressive events is the pattern
where we are changing we are ignoring
that there are cases valid cases where
we want to have the direct communication
and tell someone to do something or in
our technical meaning meaning send a
commment some intention to do something
and then someone can say like not at the
moment I'm busy just watching
Netflix or in our case it's really
important in system to model the
communication as it is in reality so
sometimes of course we should prefer
events because they give us the Loosely
coupling potentially and and so on and
so forth but sometimes it's really
required to to have a clear intention to
do something so instead of request pay
request payment command we will be
publishing like order confirmed and you
just do whatever you want so that
creates an issue because then tracking
what precisely has happened or what
reaction we expect from from other
services will be much much
harder and stream design stream
design as any other storage
technique because even sourcing in the
natural is a storage technique like
relational databases document approach
even sourcing is also storage technique
so with the relational databases we are
normalizing data document approach we
are denormalizing and in in even
sourcing we we need to have also our
patterns so the first one and the the
the thing that you you you usually learn
at the end why you should be doing that
since the beginning and we of course in
France we were telling that we learned
that at the end that and that surprised
us is that the having the clear
distinction between the private and
public events or in other words internal
and external or as DDD likes to phrase
it domain events and integration events
why is it so important because let's say
that we have those five services so
payments configuration report reporting
anti fraud detection and notification so
if we have even sourcing in our payment
module then that means that all the
other modules if we just push all those
events to the queue then all the other
modules will need understand what all
those granular events like transaction
initiated payment method selected
payment sent via Gateway means because
they need to gather a bit of the inform
information from each of those events to
to run the processing and that creates a
lot of coupling and also leaking
abstraction and if we Event Source
everything and we will be publishing all
the events all our granular business
events outside without doing any other
techniques then that will create such a
spider web and this is not the place
that you would like to be it's called
hell
or distributed
monolith and I've been there don't
recommend that so how to deal with that
it appears that most often those other
modules don't care about our granular
information who cares that someone
selected the payment method if the
transaction wasn't uh completed most of
the time they care about the critical
parts of the business process so then
you can think about the internal events
as those that should be understood
inside our module and public events or
external as understood in the global
space so instead of publishing all those
granular events we could potentially
just publish payment completed or maybe
some other checkpoint mapping be before
we send it from the granular information
and reaching them and sending like a
summary
event but of course of course we won't
be doing that and let me tell you about
the other thing which is extremely
important in event sourcing and of
course we will be ignoring that so long
living streams so usually when I'm
trying to teach and I'm doing Workshop
or consultancy then people are asking me
okay but what about bank accounts see
how many uh transactions you might have
I think that I calculated for one of my
talk like because I had my bank account
created when I was 18 years old so I
could have I didn't check that like
30,000 of transaction if I had like free
transaction per day then that wouldn't
be good if we need to read all those
events and M shilov did a thought
experiment to show what's the impact of
the length of the stream to the io
operation so let's say that if we are
reading one event then it's one IO
operation if we are storing one event
then it's one IO operation again so this
is showing the line how the time is
passing like let's say every second we
are appending new event always to the
empty stream so this is the line are
grow it's all
fine so this is like one iio operation
zero for reads one for writes if we have
stream with one event then that means
that we are doing one read and one right
which is two iops for two events is free
and so on and so forth for 10 it will be
like 10 IO operation and one an
additional for right but if we cumulate
how to get to the stream that have five
events then actually to get to that
point we need to do 20 IO
operation and for 10 events it's 65 so
as you see it start to escalate and
that's also visible on those diagrams
the blue line is for one event and here
here the green line is for 10 events and
it's still like a linear growth a bit
worse but still sounds manageable for
100 events things start to
escalate and I will show you for 1,000
events and you might not see that but
those previous lines are at the
bottom so that clearly says I mean even
stores are doing better it's not a real
thing like this is like a real each
reading each event is like reading one
IO they they are optimized for that but
still it clearly shows that the L the
longer stream you have the slower it
gets so no issue we'll use snapshots
that's the most common answer for that
and of course that's what we did because
that was good for our project but not
necessarily a good practice let me
explain you why because if we try to do
the snapshot after each event so store
our state somewhere else then it means
that we are potentially doubling the
size so if we start with that then at
some point we realize that okay that
doesn't make much sense then let's try
to do it every some period of
time and then we can read the snapshot
and all the events that were appended
after the snapshot was created but how
to define how often is enough like
everything minutes every day every 10
events every hour or specific event type
I can tell you that you definitely will
be wrong about how often is enough and
usually it means that um in the case
like for example break fighter if you
are building a Commerce platform then
then you will have the most the biggest
number of events register it and then
everything will fail so it is like a HDD
pattern which is like hope driven design
because we are hoping that we will be
right but we won't at some point because
snapshots are cash and we all know that
if you try to solve an issue with a cash
then you have two issues now
right and that's what Roy told me at
least so we could do closing the books
and closing the book means that we are
uh instead of keeping a long stream then
we might realize that accounting doesn't
work like that and we are having like a
closing accounting mouth and opening a
new one so instead of keeping a long
stream we could keep and break it down
into streams instead of account to
accounting month and then for each month
we will get another stream and make it
more manageable so see this is like each
stream would start with the accounting
mouth open and all those that were
closed with the accounting mouth closed
and that creates usually the man the
manageable size of the
stream but
still did anyone heard about closing the
books not in the France
project so the final thing is that if
that wasn't be enough then just to
double check like to to do this Final
Touch the chef keiss we wanted to build
the system to ensure that accidentally
people find out how to do it right
because unfortunately people tend to do
things right at some point like they
learn they make it better so we will
create the system so we will take
experienced people opinionated people
like rock style developers that are
experienced but not in those
Technologies a bit similar but they will
like say like hey it just like or why
don't you do this one insert right
and we were also inspired by William
Deming so um that means that a bad
system will beat a good person every
time and that's what we're going to do
and we also Inspire by the Conway law so
we will do use Conway law to to make our
system worse because we will create
organization that will impact in and
create the wor architecture also so
right now they are really popular the
team topology
so of course we will use them but in the
skewed perspective so we will create the
stream align team that is so cross
functional that they don't they are not
good at anything we will create the
enabling team so the team that in in fur
should enable but they will be like yeah
we are core team we are busy doing our
core staff right and complicated
subsystem team most of our teams will be
complicated subsystem teams because as
you know it's complicated and the
platform team of course and we will use
sapper which is great because at the
beginning when I saw this picture of saf
then I said like well that's a great
joke someone make a pasage of the agile
and then I realized that this is real a
thing so we use
it and of course we will use
jira and we will use the fear
uncertainty and doubt we will just use
all all the best management strategies
and won't people quit well we will use
also Peter Principle which means that
you are getting in the higher rank until
you are reaching the your the highest
level of incompetence so our old people
will reach that level we will be if they
were complaining then we will move them
up Etc until they realize that they are
incompetent and better be quiet
and we keep them busy in Poland we are
saying that you are running with a Empty
Barrel so that's what we're going to do
remember we will build our own event
store we will use clean architecture and
we will pay them a lot because Jordan
will handle that
right and we will let them play with the
fancy technology stack solve those
developer Sudoku Etc every day without
solving the real
case and what if all of that won't be
enough any other
ideas we will hire
consultant and thank you that's
[Applause]
all so if you scan this QR code there
will be a link to my article which is
like much shortened and uh with uh less
uh lame jokes uh that you can also read
and maybe share with your colleagues and
I'm here the whole day also tomorrow so
don't be shy to uh go to me and uh and
talk I'm really happy to discuss that
not only how to build the words but also
like how to build a good one yes Marco I
have an idea to make it yeah something
yeah God damn it that will be for the
next Edition
thank you