Event Carried State Transfer: Keep a local cache!

Cool video. Let's say we have the pattern in place. Now we want to introduce new service that we want to cache the same data (or subset of it). What's the best way to approach it? Reply all the events? Manual export/import? sync calls?

Hi Derek, what are your thoughts on using this technique for events that need to be aggregated? e.g. some service needs info on payments (total amount) that happened since some time? API call could be used to build initial state, then use events to modify state?

How would you handle the initial load, if you connect to the dependency late and data doesn't get updated regularly?

I have been trying to access various resources to understand events and your videos are one of the best explanations out there. I also appreciate how you reply to almost all comments. Thank you!!!

I like your videos. These are very informative.
Question: when service A calls Service B and waits until it times out or gets data back, does this mean Service A is blocked and cannot be used/called by any other process?

How does a delta vs fat work here ?

What do you think about trying not to duplicate the data at all, just some sort of correlation ID and use UI composition to display stuff from various services. I've seen this approach on few conferences and trying to implement this in some side projects. Seems like a very hard thing to achieve but not impossible I guess 🤷

If you’re using Kafka and have something like the customerId as the partition key, then you don’t have issues with competing consumers pulling from that stream.

You can take it a step further and create a ksqldb query to define the local cache/table and it should get updated automatically (I’m working on a POC of this nowish).

I wonder what are your experiences with the "versioning": do you use timestamps? Counters (if yes, then how they are implemented)? I remember probably from Martin Kleppmann's book that relying on timestamps can be prone to errors, as the clocks on different machines can be set up differently, plus other time-related issues.

Ok, what can you say about meta information in this context? For example authentication information, or smomething like that. Do I need put it into a message? And how it looks like?

Awesome. Very well explained, thanks!

Really interesting, thanks for sharing!