7 Reasons why your microservices should use Event Sourcing & CQRS - Hugh McKee 

We are glad you found this useful. You might enjoy Hugh's latest video. It's on the Reactive Summit 2020 playlist.

I think your query is about patterns around event schema versioning. Give it a read around the Internet, it is a trivial problem with this system. People have written books on it.

But, isn't that a normal that in Sales domain a Customer has one meaning and in Accounting domain a Customer has totally different meaning? I think this is how things in real world works. The same for Orders. In context of Sales dep. it has one meaning and in context of Warehouse it has another meaning. And protobufs as well is a good option to establish contracts between different services.

​ Dzintars Klavins Yeah.... you've COMPLETELY missed the point and further what you're asserting (i.e. specific business terms having contextually sensitive meanings ) is at best: entirely inconsequential and at worst: tantamount to a straw-man argument. That said, I recognise that perhaps you ,may well have, GENUINELY failed to understand the point(s) raised in my preceding message and thus i'll attempt clarify a few things here if I may: 1)The general issue of data inconsistency (and the logical errors that may be introduced into a system as a result) is COMPUTER SYSTEM SPECIFIC and actually has very little analogues in the: "real world" as you put it. Well....at least when viewed through a classical (i.e. non quantum) lens and this is principally because the state we ascribe to ANY noun is, by all accounts, binary in nature.... that is an object either has a particular attribute or it doesn't.... there generally should exist no frame of reference where BOTH SIMULTANEOUSLY hold true in a specific instance. This is however NOT true for the real world objects we attempt to model in a computer system and in fact great care has to be taken by the programmer to ensure that a CONSISTENT VIEW of model data is available to a computer system to ensure that associated data and indeed the entire system is not corrupted going forward. This is specifically why most programming language abstractions (Java, C++,GO) provide integrated concurrency primitives (e.g. locks, semaphores, synchronous contexts,etc) 2)Please note that the e-commerce model cited in my preceding comment was selected on an entirely arbitrary basis purely for the purposes or more clearly illustrating the point but note that ANY real world object we attempt to model in a computer system will be subject to the same data inconsistencies unless great care is taken; data consistency, especially as a system begins to scale, is a NON TRIVIAL concern. 3)Perhaps now, having regard to the full details of data consistency issues specifically as they relate to computer systems, you can appreciate the point I was attempting to make in my prior comment....put simply: if MULTIPLE VERSIONS of a SPECIFIC INSTANCE of a model exists in a computer system, each with their own respective states then this may introduce a huge amount of, difficult to debug, unreproducible, errors if care is not taken especially when the data is very dynamic in nature (i.e very likely to change between one instance of the application to the next) So the POINT I was making was that a Customer/User model is typically static in nature in most systems.... that is, once a customer has registered, their details tend to remain consistent and thus an "eventually consistent" pattern of execution should not present a problem here. However when you contrast this with say the model of a commodity in a trading system (a specific Currency in a Forex (Foreign Exchange) system for example) where there is very likely to be sub-microsecond fluctuations in the pricing data of such a model, I would ABSOLUTELY NOT be comfortable in allowing trades to execute on Index data that may well be stale ; clearly a "strongly consistent" model would be suitable here. Again it comes down to picking the right architecture for the task at hand which may vary greatly, sometimes within the SAME application.

@@cazino4 Thank you for spending your time and explaining. I am totally not an expert. I am just simple man interested in this topic. Anyway... i kinda understand what challenges you are talking about. I just got probably dumb idea... what if i can implement some kind push based temporary event store and when Kafka consumer consumes a new command/event it first informs some pull based event store, that "i will process this message" and this event store could notify all other consumers of the same consumer group, that this is the last message been processed, and this is current message in process. After message is processed, consumer again can inform "I'm done with this message" and then retention process comes in the play. So.. if in the middle of nowhere consumer dies, we have some additional partie which knows about last messages processed and messages which hangs in "processing" stage so we can react on this. This something like kids inform their parents that they are going to some party. If they does not come back in time, parent start to look up for them. They don't know what exactly happened, but they know, where to start issue handling. Don't blame me hard. :)

@cazino4, can you give an example of the same data being used to enforce business rules in both the Sales and Accounting domains, and what the business cost would be if one of the domains was out of sync by (for example) a couple of seconds?

@@cazino4 Its common sense , there is nothing wrong with that the speaker is saying, you missed the point totally. For static data - allow the data to be replicated, for dynamic data don't use stale replica/snapshot data. The speaker is proposing a concept which says "it's ok nowadays to keep a copy of some data as storage is cheap". It's expected people have common sense to not design biz logic on data which cannot be stale as in your example of Forex. If the phone number of a customer is out of sync for 3 seconds its ok - we can still continue to function by allowing a copy of the data since storage is cheap.. is the point being made here. You missed the point , going on and on about something which is basic common sense.