Why Event Sourced Systems Fail [eng] / Greg Young

[@andherium]

Issue 1: 9:54 Issue 2 - Versioning: 12:30 Issue 3 - Modeling: 16:58 Issue 4 - Eventual Consistency: 19:15

[@vitalii7413]

Dima is that guy with strong opinions)) If you have a guest, let him talk.

[@zimareff]

Not sure why Dima keeps calling Event Sourcing "CQRS". Greg clearly explained that CQRS is orthogonal to Event Sourcing.

[@xavierlevaux621]

Really, did he listen to Greg Young and documented himself about what is cars and what is event sourcing. Pretty disappointing when people say they did a project using patterns they apparently did not understood.

[@alexanderkhlystov1917]

exactly

[@bluejanis5317]

Of course, they are different strategies, but they work very well together. This makes it more complex for new people, because they have to learn multiple interacting concepts at the same time.

[@dax4306]

Another great and thought-provoking talk from Greg Young. I really love this one! It's not the usual "how-to-do-event-sourcing" talk, but a great insight into why people are failing to utilize patterns such as event sourcing (ES). As Greg mention, tools and frameworks will not solve that problem. Also, 100% agree that business problems should drive if and how you should use something like ES. If such a link can't be made, the project is likely going to fail no matter what. In my experience, you need a cross-functional team featuring people with good domain analysis skills and some tech-savvy polymaths that enjoys finding elegant solutions to real problems. Unfortunately, what I often see though, is that many software engineers are tied to particular frameworks and methods, sometimes already when they leave university. Also, it's not uncommon to see developers being forced to use a particular architecture and/or development method by some senior "uncle" lacking both domain knowledge and polymathic problem-solving skills. But if you put some effort into analysing the business problem while building up the necessary skills to model stuff in terms of events (say, put effort into learning stuff like DDD, event storming etc.), then ES is truly an awesome powerful pattern in your problem-solving-toolbox. Greg gives this inspiring example of sharding multiple read models at different geographical locations. It's really powerful stuff, and easy to do technically with ES, as he mentioned. But as he also implies, the magic does not work unless you understand the users/business. To create effective read models, solve eventual consistency problems, and decide how to shard/partition/replicate data etc., you need to "dance" with the business and understand their needs and current pain points. You need the right team to pull this off.

[@Miggleness]

The last few minutes are cringing. Dima seems like he wanted to get an engagement going but didn't get a chance to think his question through. I'm sure after rewatching this he'd be "what was I thinking?"

[@dale-palmer]

Love how Greg has basically given up at 47:34. His laugh was far more polite than my reaction if somebody still refused to listen to me. Dima, you've embarrassed yourself here. Go back and listen to what Greg's been saying all that time. I worked on a project where I was brought in to teach the team how to use event sourcing. The lead dev was determined to write everything I'd taught them into a framework. When it became apparent that I wouldn't be able to stop him I promptly quit and I hear the project failed soon after. As Greg said, it's all about people, not tech.

[@S1lverFire]

Hello, Dale. Thanks for your comment. I appreciate your attention to Greg's talk on Fwdays and my Q&A session with Greg. Discussing any kind of Framework is always flammable :D Despite frameworks can simplify some routines and help beginners avoid well-known pitfalls, they often create limitations that are usually hard to overcome. In questions to Greg, I was curious to discuss the possibility of having any kind of ES framework: *IF* there is any sense in creating an ES framework, what should it look like? I tried to lead the discussion this way and clarify the possible pros and cons, but Greg has a strong position against frameworks and I respect it: nothing to discuss)

[@nezzdk]

@@S1lverFire Greg isn't against frameworks but tries to tell you that parts of the problem needs business or developer decisions, as some times eventual consistency, can easily be overcome by telling users the status after an action differently than from traditional systems, where you have the updated state available immediately. It all comes down to human decisions, on how we decide to show the users the current state. CQRS and Eventual Consistency is a very big change for guys used to working with transactional systems as SQL.

[@CodeOpinion]

@@S1lverFire Just to clarify for anyone reading this, as Greg pointed out at the beginning in the slides, CQRS and Event Sourcing are totally different things. As the Q&A was going, CQRS was mostly referenced when Event Sourcing was really what was meant. Now to the framework portion, the reason why a framework isn't needed is because the "problems" are contextual and need to be made in every single situation. There is not prescription solution because there are only "problems" when it's actually a problem. For example, how you version isn't cut/dry. It totally depends on the situation. And you may use various ways each time it comes up. Should you use snapshots? It totally depends on the situation. Most often, a problem is only a problem in some context. There are generally multiple "solutions" which are also dependent on the context.

[@cupofkoa]

@@S1lverFire These solutions to the pitpalls are conceptual. If you're talking about a conceptual framework, then this would be productive. A code-based framework? What if my write model was in c#, my stream processor in java, and my read model in nodejs? A code framework would be completely useless. Greg main a clear point that we're using different models in the system.

[@TJ-hs1qm]

I wouldn't have dismissed the host's question so easily, his point was absolutely fine. Fact is, industries in their respective domains don't differ a lot. Be it healthcare, finance or e-com. Q is how do I make an informed decision, whether and how an event based approach could increase business outcome (i.e. making or saving money)? Studying those patterns might be helpful. Maybe a e-com framework could come out of it why not? Anyway, just be aware to never become a cargo-cult follower. Speaking on conferences has turned into viable business, which needs to create hypes around event sourcing or mircroservices etc etc

[@jub0bs]

46:25 I wouldn't trust anybody who tells me a framework is the answer to my problems...

[@myth00s]

Did Dima waste 10 minutes of everyone else's time?

[@ozzyvknox]

Yes. Asking questions to prove a point, instead of to learn from knowledge and experience of the speaker.

[@deep232]

Dima is that People Grey talking about :) . In my career dealing with CQRS & event sourced system , one thing I will never do is to create a generalized framework for CQRS & Event sourcing as its bound to fail , every domain need there own optimization. Good luck Dima !!!!

[@bfg5244]

sounds more like miscommunication to me. Frameworks that deal with infrastructure (specific DBs, retries on version mismatch, trigger updates on Read models, etc.) are a good (domain independent) tools. For example, Greg mentioned that re-streaming events to a new store on every release, which you can't afford to do manually.

[@evangal7357]

To all the people who perceive Dima as rude to Greg, this is exactly why Greg is at the conference. Fwday is a tech conference in Ukraine, which has a developer culture different to the USA. 44:12 = Example of under developed business culture relative to the USA. How often does a business offshore their business needs? 44:50 = Lack of understanding of the software development cycle. Greg flipped a cartoon strip blaming people to emphasize poor decision making in the software development cycle, while Dima interpreted it as elitist due to the perception that the people who dont understand arent smart enough. 45:52 = Questioning the existence of software design patterns as something you can buy or download like any another framework. Most of the development work off shored to Ukraine revolves around using a framework. Greg mentioned that there are some things for enterprise applications that can never be simplified into a framework because the business needs are too specific, such as analysis on a specific business process. This highlights the lack of experience from the developer, and likely the targeted audience, with the scope of their projects. That last part, Dima specifically asked whether learning all this stuff is even necessary when a lot of software does get thrown into a framework. If your software industry revolves around frameworks, why not wait for the next framework to come along? It's a shame that Greg made a friendly chuckle and Dima said whatever. There may have been a cultural misunderstanding to some of this. Good talk though.

[@TM-yc2qi]

I think that Dima guy would of been considered rude in any culture.. talk was great until he came up and started speaking nonsense

[@danflemming3553]

I didn't perceive Dima as necessarily rude, but definitely pushing too far with his idea, and apparently completely rejecting the idea that maybe Greg, who has much more experience, could be right, maybe he is was missing something. Regarding the laugh at the end, Dima was actually rude saying "whatever" to Greg, who is the guest. If you do not agree with your guest, that's fine, but generally you should show a bit more respect for him/her. There is no "cultural misunderstanding" here, but more like some guy, Dima, who is actually very pushy to the edge of being rude.

[@MatthewLaMeyerMad]

Many speakers preach the same thing over and over. There is no silver bullet. Our businesses drive the need to create software but it is up to us to understand how to deliver the best experience to the business. Dima, you were way off base and your questions were just personal opinions with a question scattered in there somewhere.

[@attilauhljar3636]

Nailed it! The ultimate question at the end, that is. 😊 Thanks for the excellent presentation, and the conclusion, which deep down we all know the answer to, at the end.

[@cupofkoa]

Why are people so obsessed with frameworks? If you have a distributed system with a variety of technology and domain models, a framework will fuck you.

[@DodaGarcia]

Because they don’t want to have to think about the app’s design, they want to start coding and see something happen. And then as you said, they eventually get screwed by the system. I know because I was one of those.

[@brentsteyn6671]

I agree.

[@someguy3176]

It gets tricky in large groups, but perhaps software shouldn’t be written by large groups.

[@mackie1001]

Make your own because boiler plate concerns do exist. Definitely don’t be a slave to other people’s (often trivialised) interpretations though. Excessive abstraction leads to. It maximising the capabilities of the underlying DB etc which can lead to extra complexity

[@coneryj]

not completely through it yet, but there is some conflation that I don't like between data consistency and whether data has been replicated to all read stores. These are actually different things. The data is always consistent in the latter situation.

[@zapdelivery5169]

Engineers like Dima is exactly the "people problem" greg was talking about. Terrible attitude, over-estimating their own intelligence and understanding of a subject matter. Be very careful of so-called "experts" who end sentences with "whatever". They will impose their authority, stifle thinking and ultimately drive a project off a cliff.

[@arcanernz]

Looks like Greg is recording this at 5:30am and wants to go back to sleep.

[@quipitisi]

So embarrassing to see this young lad trying to outsmart Greg, while Greg is there to share his deeeeeeeep knowledge. What a waste of Greg's time.

[@bored_randomguy]

Wish I knew all this few years back when we had to create a separate audit tables for tracking changes

[@khoi0107]

decoupling instead of having transaction is mostly because of organizational issues and not a technical issue

[@MrDomenic123]

It must be weird for Greg to answer the questions in the end :D

[@RichardOpokuEngineer]

Laravel is a framework, it does not solve my business problem. I have to model my data, services, repositories, etc to meet the business requirements. Whether I stick to MVC, DDD, CQRS (+ ES) is up to what we trying to achieve. The problem I'm solving with Laravel, I could also do with Nodejs with express and it is dependent on how we model it. Frameworks don't solve your problems.

[@pianochess1882]

What is exactly a read model? Is it one projection, one database, etc…?

[@bluejanis5317]

44:00 Is being better than the alternatives not enough?

[@anilaxsus6376]

No, there are certain situations, you would just know what you need when you meet the problem that require that particular solution

[@bluejanis5317]

@@anilaxsus6376 You literally are saying you prefer suboptimal solutions by definition.

[@MohamedSamyAlRabbani]

Instead of building a system with one team, you build it with 10X more people and with absolutely no chance of coordinating in enough time to get anything done so the development is slowed down to a crawl, and a feature that takes 2 days to develop now takes a quarter.

[@alexanderkhlystov1917]

nice talk, and it was interesting to see the cultural clash how the guy asking questions overwhelmed Greg into retracting himself from a conversation probably because of being polite to a host. A lot to learn from this situation. Also Dima was not using the right term in his question - mixing up CQRS and Event Sourcing. as Greg said it is not the same thing at all. Dima has the point that frameworks do make life easier.

[@metax73]

Great talk until Dima came on

[@maurizioita86]

Great talk! How can we accept the read model's delay when two concurrent processes are validated with a set base validation? Let's imagine two "aggregate root creation" concurrent requests, so you cannot rely on the event's version number.

[@vinceve43]

Aggregate tactics is not the best one when you speak about distributed systems. EventStore streams or NATS subjects can act has the aggregate so you get a single source of truth shared between your different process. First thing they do is writing an event with expected revisions to be sure they can continue

[@andrewstewart1698]

If it's important that your 2 concurrent creation events be processed together, then you'll somehow need something that knew both were being requested in order to ask for the new derived state that is at least that "up-to-date". E.g. if it's a client sending 2 simultaneous create requests, as per Gregg's example, you'll get back 2 positions. If you're making a follow-up query that *must* be up-to-date, grab the max of the 2 positions and issue the query with that as the minimum state version. In general any answer that a system gives to a question (response to a request if you want a more specific framing) is only going to be correct for a certain period of time. So find a way to express your temporal requirements and constraints and you can then choose the solution to match.

[@LucianMoldovanu]

Amazing talk by Greg Young!

[@cristianpallares7565]

47:45 I had to laugh with Greg, here 😂😂

[@PietroYT]

Failures is always caused by the actors. I think a more precise response could be that a CQRS failure is due to a no good fit to the use case or as Greg said, to the business requirements.

[@LotmineRu]

Про то что проекты зафейливают люди, а не идеи... от себя добавлю что какой-то подход следует выбирать не только по "подходит ли он проекту", очень важно также посмотреть на имеющуюся команду. Потому что криворуких, недалеких и самоуверенных разработчиков полно, а возможность сделать какие-то изменения в команде не всегда есть. С рукожопами ивент сурсинг строить не надо, хоть проект идеально под это подходит.

[@marriagedance8657]

Greg is looking like biker Undertaker

[@marcinsztof6982]

Ey guys! Cut Dima some slack! When taking a look at the comments before getting to this part of the video I assumed some major shitstorm ensues at the end. It's understandable that in the Q&A section statements/propositions/theories presented by the speaker are somehow challanged. Even when you generally agree with the speaker it's usually worth to challange the idea, so everybody present can potentially gain a bit more confidence in it seing that it can be easily defended. As for having problems with clearly formulating questions on the spot, publicly, in not-your-first lanquage - I think it's not surprising it can get very awkward. I feel like there was quite a bit of miscommunication between them. And regardless of some lapses of thought (like Event Sourcing -> CQRS) and questionable wording, the general question behind it isn't out of this world. When you encounter problem of which significant part can be easily generalised it's quite natural to ask for existing solution to this generalised problem. When building software in professional environment (because for hobby/personal projects, of course, you can do whatever your heart desires) cutting development time, and getting reliability of proven tested solutions shouldn't be an afterthought. If you'd be in a need for a relational DB for a project, in vast majority of cases you wouldn't write your own DB, right? Then say "it's crap, but after I do design few more for other projects, then probably like 8th will finally do it's job well". I totally undestand distrust for overreliance on frameworks and sure - fighting with them is often major part of frustration at work, but I imagine most of the advocates of "Free your thought! Lose the shakles of framework! Don't compromise!" at the end of the day when tasked with actually delivering something, quietly go back to their trusty framework stack, that they've grown to at least partially hate for all the limitations that it imposes on them, but still use it as it makes them overall more productive. And with "Frameworks don't solve your problems" thrown around here - what the hell? Of course they do! They don't solve ALL your problems, usually just a narrow range of them, but that's a truism not worth mentioning. It's just about weighting whether using an existing solution helps you more than it fucks you over. I feel that Dima got a beating here partially because he dared to mention thing that most of us don't want to be associated with, but still is common pragmatic way of approaching non-trivial general problems for most. And I didn't really take Greg's words as "Fuck frameworks and if you use one you should be ashamed", just that event sourcing comes with its own set of conceptual problems that have to be deeply understood by anyone attempting to apply it for their specific business case, so he can't magically make it trivial by just giving us a piece of code. If some parts can be generalised (e.g. stuff agnostic of your domain, infrastructural stuff, overall glue code) I don't see why should we never speak of it. And there already tools to help with that. I have no idea whether they're good and mature enough yet, but they'll probably get there, because a lot of people don't like to solve solved problems, especially when they have some dealines to meet. Aside from that... Really nice talk :)

[@zapdelivery5169]

No one is saying frameworks are bad. Greg is not saying stop using frameworks. Again just like Dima, you are missing the whole point 🤦‍♂️

[@marcinsztof6982]

@@zapdelivery5169 1. Scroll down a bit, quite a bit of people here seem to mean that "frameworks are bad", thought that it's clear that my comment is a counter to that, not the content of the video. 2. Yeah... I know he's not saying that, why else would I say: "And I didn't really take Greg's words as "Fuck frameworks and if you use one you should be ashamed", just that event sourcing comes with its own set of conceptual problems...". But it was a long comment, probably should've add a TL;DR :)

[@alexanderkhlystov1917]

And there is a framework for event sourcing e.g. Axon

[@_arshadm]

I still don't understand what is the problem that event souring is trying to solve. Readonly mirrors are a solved problem using journals and are more efficient and less over engineered. In a micro-services architecture given that we need that read consistency between the models, it seems completely pointless to have the overhead of the event log. It seems like a solution looking for a problem, anybody willing to enlighten me why I would bother with this approach.

[@nicktech2152]

Well, to my understanding the biggest pro is to have the ability to relay events when it is required to have highly traceable domain and apply them to different read models. It is not uncommon that at some point of product lifetime business decides to introduce reports or usage analytics - here event sourcing can become particularly useful because you have as raw record of history as possible. Now if you’ve been saving only the final state for a pretty long time, you won’t be able to access historical flow of data as well as be required to build such a tracking from scratch. This is somewhat of edge case, but for example I just got into the project where there will be multiple products inside one eco-system and one of the products will actually be an analytics platform. So I’m now considering Event-Sourcing as an architecture. Another great thing about Event-Sourcing that I see is the ability to do Fraud-review from day one as all events are recorded in systems that are dealing with some kind of virtual currency.

[@mackie1001]

Think about a world without distributed transactions using horizontally partitioned databases and where there are multiple downstream systems interested in everything that happens to a given entity/aggregate. That world is this world now. You’ve got transactional outbox or event sourcing as options if you don’t want corruption/inconsistencies. Which you choose will depend on the requirements but if you’re not using one of them in an event driven arch then you’re doing it wrong.

[@ozzyvknox]

Great talk Greg

[@thales-maciel]

dima makes me feel really good with my skills rn

[@kostyainfine5528]

he looks like he's just returned from his anonymous alcoholic meeting

[@mo0lo0ko0]

Yeah and still he is one of the smartest experts on DDD and EDA.

[@mehrdadk.6816]

No, you start event sourcing and mix it up with CQRS which is just one type of implementation of event sourcing. There are dozens types of implementation of event sourcing and depending of the use case one might use, it does not mean the event sourcing fails!

[@mo0lo0ko0]

CQRS ⚠IS NOT⚠ a "one type of implementation of event sourcing". CQRS and ES are two completely different things. In conjunction, ES makes a write model for CQRS, though you technically can use CQRS alone, as well as using ES alone (for some reason 🤷‍♂).

[@portlyoldman]

I thought that Greg may have known what was ahead and was already losing the will to live while he was talking. Also, poor guy was clearly unwell ☹️ I also think Dima might, in other circumstances, have attracted a fist to the face...

[@TM-yc2qi]

I put money he would of smashed Dima, ill or not

[@Alperic27]

people’s inability to complete projects using the tools they use causes failures…. Never technologies. I just saw it again, trying to explain a number of things yesterday….. ‘there is always someone to blamr’ … what a RIDICULOUSLY defensive thing to say. This Dima guy is truly hopeless… I am scared for the projects he works on. yes Dima… developers HAVE TO THINK.. not just use libraries

[@boblouwe8440]

Great talk Greg, finally someone that has some common sense.

[@williamvankeulen1307]

Great from Greg as usual. Super cringe questions. Next time keep the questions clear and don't argue someone's answer unless its to clarify. Viewers I recommend stopping after the talk so consider the video finished after kzbin.info/www/bejne/fHyppmpuj6p8n5o

[@xavierlevaux621]

The last minutes are just so terrible. No there is no framework that will magically solve people from thinking. No cqrs is not a synonym of event sourcing. There is no silver bullet. There is nothing that will fix a project from failing if people can’t think, be smart and learn from their mistakes. Is that really a question session at the end or just a guy expression some frustration?

[@sbditto85]

I’ve watched this a few times and I think he was trying to say that there are common problems with event sourcing and cqrs (like eventual consistency) so is there a way to make a tool kit or library to make those easier or maybe so that developers don’t really have to think about them. The answer still might be not really. I think the conversation got derailed when the word framework was said.

[@andrewstewart1698]

Some advice for the person asking the "questions". Instead of arguing with Gregg, imisunderstanding what he's saying, you should accept that he might know a few things that you do not. The arrogance on display while completely missing Gregg's points was painful to watch. Other than that, it was an interesting talk.

[@TheCnmota]

I am sorry but next time find someone who is not an opinionated ignorant to ask the questions, most of them only showed he did not know what he was talking about.

[@timmcclure3777]

Dima was so annoying that the end - completely clueless - otherwise great talk

[@ebrahimmansur9815]

Great talk ....people need to re watch it to get a full understanding of what he is actually talking about

[@benisrood]

I love how Greg looks and sounds like kinda like Gronk (the former NFL player) with a 🧠 transplant 😂 (maybe it's just me 😅)

[@Loppy2345]

47:55 hehehheheh ...... no - that's what he was thinking

[@michaelschafer7592]

36:00 Want to know why the projects failed? Hilarious and so true 💯

[@marcom.]

Don't know what Greg smokes, but he should stop it.

[@gjermundgaraba493]

Great talk. But shit, would've been better to just have Greg read questions from the audience and answer them, than Dima starting some kind of awkward discussion :S

[@DennisPush]

сначала услышал акцент, потом увидел надпись на футболке. :))) Годный контент!

[@health_doc]

Good talk but so embarrassing Dima not understanding much of the topic.

[@CinemalecularFilms]

That went well.../s

[@smatsri]

loved the conclusion on why projects fail people are stupid!😂

[@MegaMage79]

People better start understanding Event Sourcing or his eyes are going to fall out :D

[@zyklos229]

- So you start with some fine CRUD Apps on a relational database. Reads are fast, writes are okay, consistency and transactions are just there, even full logs of what happened - Then ... yeah you want to distribute your monolith - Not only fighting man-years about the right kind of APIs and events, to make up a not-so-cdc-shitty event-store, recognize now reads are slow, introducing CQRS and other "patterns" like Saga, Outbox - So fighting with business and technologies you have to adapt to, because you basically lose everything you had - Then it fails, years of frustration passed and the only "argument" why it failed is: "yes you were just too dumb to adopt to my fancy shit" What a shitty story.

[@stevesmith8588]

Dima. Dismissing a guest speaker and expert in his field with a "whatever." Yikes! Don't do that again. You don't have a clue what you're taking about.

[@rostyslavv2006]

не давайте Дімі мікрофон. він не робить домашку