Good catch 👍

Wow. One of the best compliment that I saw. Thanks a lot!!!

Or you miss most of it at that speed 😅

Tim at his best

Our pleasure!

😁

Thanks

Our pleasure...

I'm not sure what you want here. The guy broke down some concepts, and explained the pros and cons of some approaches. It's up to you to look critically at your use case and determine if you "need" it.

exactly what do you want here .

​​​@@samanthamccarthy9765 Hi Samantha, I am guessing that the OP wanted Tim to forgo the digressions-and digressions upon digressions! 😂-and associations. Instead Tim could have just methodically iterated through the various examples and cases he wanted to cover. Not Tim's style, I grant you, but it was more than a little unnecessary this time, and makes it harder to follow the points he is making and wanting to connect together. Not a bad talk, and absolutely a necessary talk, but I can also imagine that the next time Tim gives this same presentation he will probably refine the way he gives it. Maybe it was also situational, perhaps the Poles were a tough crowd 😂 and Tim was nervous!

Yeah, something like this one: A user payed for an order, then decided to change shipping address and placed another order. So, where 1st order will be shipped in this system? Because shipping service maintains its user DB , I assume shipping address is not included into order or payment event. With such design, I guess chances that address change event will come and would be processed BEFORE order payment for order#1 event would be high for any reasonably loaded site causing shipping to wrong address. During promo or BlackFriday - it's almost guaranteed.

Glad you liked it

IMHO, the shipping service isn't 'maintaining' the data so much as it's just keeping a cached view of the data. All the rules around the handling of User data are still kept within the User service.

It is called materialized view . It is not an anti pattern

The materialized view thing is obviously bullshit. I think the point it to avoid coupling between shipping service and user service. If the user service is down for example, you could not ship orders because you cannot get hold of the addresses. Or if the interface of the user service changes, you might have to change the shipping service in tandem. And as @immrsv writes the shipping service still doesn't handle the user domain, he just saves the data that is relevant for it's own domain. I think it's also reasonable to allow those cross-service calls. You just need to consider the pros and cons of either. A EDA purist would probably put it all on the event bus.

My pleasure!

You can use Crypto Shredding (field level encryption). Can / is also be used for personal identifiable data. Meaning: Users that do not have access to a key due to their role, don’t get the data. Thats what key vaults are useful for.

@@dinoscheidt That's a fascinating idea for data access control when multiple services consume the same event. Thanks!

If the universe of consumers/permission permutations is finite and manageable, the approach I've seen taken is for the owners of the original topic to create consumers of their own topic that then publish filtered subsets of the messages to new topics. The downstream consumers would then listen to the filtered topic instead of the original topic. This can potentially be configured dynamically. This is surely not the best solution, and may be difficult to scale, but for relatively limited use-cases, it gets the job done.

Thanks.

Thanks for your feedback.

the real pitfalls as he mentioned here are I think scaling and state management which is hard to figure out on your own and hence he recommends tools to be uses.

Sometimes introduction is necessary for better understanding and explanation

i also around ~22m was thinking why not just replace database and notification system with a blockchain ledger. write and read directly to it.

@@isorry123_ yes exactly. But the devil's in the details of how you decide to allow for performance/trust/availability/etc tradeoffs. For example, a blockchain with a hard-coded consensus algorithm like bitcoin has only one "shape" that it can take WRT how it performs & where it centralizes. Ethereum, both pre- and post-Merge, will also be a one size fits all, and this will always generate lock-in with e.g. requiring solidity to enforce their beliefs on how the math guarantees their level of trust. The same goes for every blockchain-based approach that I've looked at, though if you take the entire blockchain ecosystem as a whole, you get a wide range of dynamics. My approach literally uses the biological paradigm by enabling version control-like dynamics - diffing + DAG like in git, but with the diff transforms themselves as metadata as well. These transforms are not text-diffs but rather semantic diffs, each transform itself being a node in the DAG. So in the event sourcing world, this is like having a redundancy of storing both the events and the hydrated state, which sounds like a waste. But if you use them in context of version control, where you apply the same transforms to **different** branches, you come up with different results (something not wanted in event sourcing). So it ends up looking like biological organisms, having the transform dna "genotypes" and the expressed "phenotypes" of the state when actually being consumed in an app. Interestingly, this has many positive after effects like idempotent CRDT behavior. So when I go to "synchronize" two spaces (merging multiple timeline branches), I can simply look at which transforms have been applied...though only when order is not important. (Ordering implies that you should have a localized space or the standard barrier/critical section/etc parallel constructs. But I digress... My point is that this enables consensus specification to be "on chain" in a consistent manner, whereas with all approaches I've seen host their code on github with no plans to move. (Mine also is on git because I don't have time to implement the version control cli while also doing the entire rest of the shiny UX stuff that I suck at) But the point is that git itself is a blockchain (DAG) under the hood, so right off you're duplicating code, increasing surface area, and decreasing flexibility and agility because you have to edit the code in git as opposed to the code already existing in a granular fashion in its own "version control". This flexibility is absolutely necessary to actually implement the unification that you're talking about. There are a couple projects that are somewhat close (IPFS/IPLD/etc and w3c's rdf triples addressing protocols which have changed over the years), but I don't see them getting the whole picture.

@sergeykichuk2586 this is the bigger picture described as Event-Driven Architecture, ES and CQRS are definitely in play here but he simply avoids explaining them. ES here is when materializing/projecting user data into shipping and CQRS is obvious, the requests.

Perhaps, but in this instance it is definitely appropriate. This topic is about a complex arrangement of interactions between independent processes running on separate hardware but working collectively in a concerted fashion to achieve a task. The roles of the various components, the manner in which they interact and contracts they hold between each other, and the spectrum of implications that the particular arrangement results in - this can aptly be described as the system's architecture.

Good point

What do you mean by annoying?

@@DevoxxPoland I think zero is referring to some of the tangents that came up. Eg he is about to tell us something and then decided to explain his tshirt instead.

@@calebvear7381 breaking the line of thoughts