Event Sourcing • Greg Young • GOTO 2014

[@GOTO-]

Looking for books & other references mentioned in this video? Check out the video description for all the links! Want early access to videos & exclusive perks? Join our channel membership today: kzbin.info/door/s_tLP3AiwYKwdUHpltJPuAjoin Question for you: What’s your biggest takeaway from this video? Let us know in the comments! ⬇

[@deyan.todorov]

As people saying, old talk but precious as a gold!

[@TheHippyhopp]

This isnt an old talk, its a Young talk

[@ElgersNiels]

@@TheHippyhopp 💀

[@-andymel]

00:00 Introduction (it is not a new idea) 01:00 What brought them towards Event Sourcing 01:25 Mature businesses like finance, banking, gambling, insurance are all naturally event sourced 03:00 *Definition* of event sourcing - all state is transient, only store facts 06:46 We *never update or delete facts* in event sourced systems 11:52 Event Sourcing is the only model that you can possibly use that does not loose information 14:05 *Projections* - Deriving state off of an event stream 15:04 Projections must start at event 0 16:16 Projections can be done for every point in time since the start of the system 17:09 "You can not change what happened in the past, but you can have a new perception of what happened in the past" 17:39 *Advantages of event sourcing from a developers point of view* 17:52 It's sequential writing -> fast (~50.000-100.000 requests per sec on a fairly naive system on one node) 18:39 Go back in the past 19:19 Easy smoke tests (for me he even describes full regression tests not just smoke tests) 20:16 Prevent super user attacks 24:45 *Snapshots* 26:42 Store snapshots off the side and point back to the version of the event log 27:11 You can also have multiple different folds with different perception of the same version of the event log in parallel 27:26 Avoid snapshots if you can (state is hard to version) 29:53 How do I query a series of events? You don't. You use *read models* . 36:22 Consider a graph database for read models 37:36 You can have as many read models as you want - they just have to subscribe to your event system *Wrong statements you hear about event sourcing:* 38:01 *Event sourcing needs a service bus* 39:12 Problem: if you want to add a new read model you need to replay the former events. With a service bus you would need an additional control channel to ask for events. Use a consumer driven subscription system like Kafka 41:55 *Event sourcing is more complex (than CRUD systems)* It seems more complex to people that are used to the CRUD way just because it's another way of dealing with the domain and have to learn it. 42:55 *What big companies are using Event Sourcing?* Don't decide what to use because of other companies. 43:29 *Event sourced systems must be slow* They can be really fast and it's used for latency sensitive systems eg for trading 44:25 *Event Sourced systems must be object oriented* No, it is an inherently functional system. You have an immutable series of events and "left fold" your state out of this series 45:12 *What is the "bestest" Event Sourcing framework ever?* Probably none. 45:51 *But what about all my data? With Event Sourcing it must be huge!* Don't think about the amount of data you are going to have but at which current and which future rate you will be retaining data and compare that to moore's law. If you are slower than moore's law ( < ~5.000 req/sec) your data will get cheaper over time. 47:40 *CQRS is just a teaching pattern* "CQRS is the dumbest pattern ever written". It was never meant to be a pattern. The main idea is to make people see the benefits of separating the reading and the writing part of the process. 49:34 *Event Sourcing is not 'enterprisy'* True, thanks. *Questions* 50:33 *How to know what details to put in an event?* That's an use case analysis problem 51:59 *How to avoid the big bang release when switching to event sourcing?* Two ways of dealing with migrating data to an event sourced system - Either migrate all data and transactions of all accounts to the new system - or just bring in the initial balance Decide which one to use aggregate by aggregate. Either you can reverse engineer the history or save a snapshot as init-event. This allows to run the systems side by side. The old system can already raise the events.

[@uberwachGG]

thx man

[@dimitrisbaltas6321]

Thank you Andreas! Really helpful!

[@rum81]

Wish could bookmark this comment

[@Benforeva]

Doing the Lord's work.

[@piotrlasota2670]

Not all heroes wear capes, some wear hoodies

[@thonEtMais]

So valuable still in 2019.

[@KeithWhittingham]

30:48 Which DB is the not cool DB?

[@RodrigoBranas]

Is Martin Fowler in the front row, near Greg?

[@OhhhThatVarun]

Wondering the same thing.

[@steveroger4570]

I've actually once come out this idea my own, where instead of C R U d (with soft delete), I can just use C R in database such that all data is logged as transaction, essentially like bank account balance and no 'act' is ever deleted. But my uni lecturer discarded my idea and said my implementation is the 'Wrong' way to do it, plus homework required implementing C R U D. Since then, I always thought I was wrong and not doing correctly. my life is filled with lies.

[@MaximilianBerkmann]

Your implementation indeed seems wrong as far as (traditional/state-sourced) CRUD systems; that's possibly not the case for event-sourced systems.

[@Jaood_xD]

"It depends"...🙂

[@LeviNotik]

Yep, append-only DB, naturally keeps a complete history of all changes, which is valuable for auditing and compliance purposes.This pattern is commonly used in systems where tracking changes over time, maintaining a transaction log, or ensuring data integrity is crucial.

[@Pjblabla2]

Very insightful

[@maour]

Great talk

[@brianevans4]

This guy seems a bit arrogant, but you've gotta give it to him that he has a good sense of humor. "If I can fit your entire database on a micro SD, you're not big data" 😂😂😭😭 That is so funny. Every company thinks their database is massive, until you put it in perspective like that

[@itihas9958]

All his talks has the same information. It's a great talk but I am looking for a talk with inclination towards implementation details.

[@rum81]

kzbin.info/www/bejne/fKTOepVviMaln6s

[@jfaquinojr]

21:03 criminal mastermind i stopped here and tried to search to no avail. Chris Horne or Harn?

[@joshuaharvey4956]

Its Masterminds S1E10 A Day at the Races, you can find the ep on KZbin.

[@na4ma4]

Also the wikipedia article is en.wikipedia.org/wiki/2002_Breeders%27_Cup_betting_scandal

[@FenelHyacinthe]

Event sourcing have the same principal as blockchain. Once a transaction in you cannot delete or update it, you have to do a reversal if mistake happen.

[@CosasCotidianas]

35:15 I think we all had to deal with that. Weird.

[@flippy0808]

Within 2 years we already have 4TB SSD's ^^

[@MNNoxMortem]

@@csivi , @flippy0808 I love this comment. 2018: 30TB (Samsung), 2020: 100TB (Nimbus). While the latter is not cost efficient, but designed for maximum density, let's see how much it will cost in 2 years :)

[@ktxed]

Is event merging an antipattern?

[@dgaston]

8 years later a 2 TB SSD is $100. Double the size for 1/5th of the price.

[@willl0014]

The argument that storing information is some how not a big cost it is false in my experience. As a cloud based Saas, cloud storage for thousands of clients it is expensive

[@JohnMcclaned]

save some oxygen for the rest of us

[@clarkflavor]

@@JohnMcclaned 😂

[@polomarkos]

where can I find Greg's T-shirt?

[@basgys]

It's an old New Relic t-shirt that you were getting with a new account. I doubt you can still have it, but you can ask them.

[@sambergin1132]

It's a new relic tee

[@dr.bnagarajan8858]

the entire speech is full of information ... which is useful for research scholars

[@danyalexsf]

+nagarajan balasubramanian It is a very practical approach to large software systems. I don't think it is targeted towards research scholars.

[@joonasfi]

Ummm, no. I recently worked for the healthcare industry as a software engineer and I can definitely tell you that this style of architecture would have solved many pain points. EventSourcing properly designed even allows for zero-downtime migrations of mission critical software - even if you change the underlying programming language and database technologies. The principle of EventSourcing supports two separate systems listening for same streams of data and be at effectively the same state (albeit if with different implementations) and you can just point your loadbalancer at the new system with zero effect on the users of your mission critical system.

[@DigishAD]

Sweet

[@tarikkhan3873]

Looks like 2GD from dota 2 went in to system designing after being fired by Gaben

[@crazyheinz]

what's up with his breathing tho. Doesn't sound too healthy.

[@MaximilianBerkmann]

Exactly what I'm wondering.

[@PaoloDiBello98]

It felt awful to hear that

[@hongqiwang988]

I didn't notice that at all until I read this comment. Then that becomes so noticeable.

[@geestarrawify]

Sounds like astma.

[@hertzbergny]

god hes hot

[@clarkflavor]

😂

[@watherby29]

Sounds like blockchain

[@xnoreq]

Not at all. A blockchain is a chain of cryptographically securely linked records where new records are usually appended through a consensus algorithm. Event sourcing is just about persisting changes in application state as a sequence of events.

[@sidekick3rida]

His talks would take half the time if he didn't ask the audience silly questions… "how many of you have talked to a lawyer before?", "how many of you have been to the doctor before?", "how many of you have heard of XYZ?" REALLY ANNOYING

[@clarkflavor]

😂

[@tknayak]

Many times he is very boring to listen to

[@leonardocardoso1360]

Great talk