Building Event-Driven Microservices: Leveraging Organizational Data at Scale

Again one of those situations when I find it difficult to accurately put into words what I liked about a technical piece of writing and of course the why behind the what. So let's start with the bad instead.Unless you're familiar with DDD, you may miss the motivation behind some of the presented ideas and ideally you'd want to read both DDD by Eric Evans and Implementing DDD by Vernon Vaughn, although the latter would be more important since the idea of domain events is introduced there and Event-Driven Microservices builds on from there. In doing so, the author also takes a bit of a Kafka-centric approach, and some of the best-practice advice regarding the way you organise events and streams doesn't make a lot of sense if you're creating your event-driven services using a different technology, e.g. Akka.Now, with that off my chest here's what made this one so worth reading for me. First, I recognized some of the issues with the traditional approach to microservices, which at my current company we managed to solve with event sourcing. Which, as things go in software, gave us a completely different set of issues, and this book deals with them. While I can't say the book had much practical value at this point, it did help me articulate better why some approaches work and why others don't. Second, I particularly liked the mix of high-level abstraction of the patterns and the low-level technical detail that can be found in every chapter - the author managed to perfectly time the jumps/switches between the abstract and the technical and also strikes a fine balance between the two, keeping most of the patterns abstract, but delving into the nitty-gritty details when they are important to the way you implement the pattern or, sometimes, if those technical details are the cause or the enabling factor behind the pattern. Finally, while I know I've mentioned this under the 'bad' column, it's a actually a good thing in my case - the book is a perfect sequel to blue and red DDD books and promotes those ideas even further.

This is a very good high-level overview of all the problems and solutions to deal with humongous volumes of data. This helps the decision-makers and architects immensely. However, the treatment is shallow and generic to be useful to practitioners of the field. A more practical follow-up would certainly help the field of EDM.

Has a lot of practical information, a great read too!

The thing that was the most valuable to me is the mindset shift that this book gave me regarding the way as which EDM architectures require you to view the data.I got some important takeaways and ideas to improve how to do things at my organization, as well as identified some anti-patterns in my current designs.I was looking for architecture examples of how to design some communication flows and this book has given some examples although it could have more.This book is more advanced and less abstract than the micro services books from Sam Newman, which was exactly what I was looking for.The way sentences are written is a bit confusing. I had to read many times the same sentence to make sense out of it.It has a lot of mentions to technologies (eg. Kafka streams) that if you haven’t worked with them before or don’t know about them then what he says about them is hard to picture.

Judging from the table of content I was excited to read this book, but it turned out to be rather worthless. Concepts we're explained very well, it was written very vaguely, many times it says "be sure to check X as your system will vary" rather than explaining what to check and why. The diagrams! they were the worst. A good diagram will really help me understand but these diagrams were of zero informational value and were confusingly labeled, like Event A, Event B in topic C and topic D processed by service E and combined into topic F. Software dev 101 is good names matter a lot.

It’s a good intro for beginners and that’s about it.The author glosses over the biggest pain points like correct sequencing of events, the 3Rs, edge cases, failure scenarios, missing events, error handling strategies-basically anything that’s required to build stable systems is only mentioned in passing.

I'm only in chapter 3 and there have been many examples so far. I've accepted the fact that I just have to move on when things aren't well explained. Example: Chapter 3. Forward and backward compatibility of schemas. He explains backward compatibility and gives three examples of where it's useful but never gives an example of schema backward compatibility or explains it sufficiently. Frustrating.Here's the irony though, I didn't a google search for "event driven microservices backward compatible schema". The first result was a video on that very topic from his company :( I'm glad it's there but the irony is unfortunate.In a nutshell, it's got a lot of good stuff in it. When he talks about things without explaining them, just move on.

The author obviously has extensive experience dealing with data and put a lot of thought into various event-driven applications, including how to integrate EDM and request/response paradigms, dealing with legacy systems.However, his writing style is quite dry and wordy. Some simple concepts are unnecessarily described and taxonomized to great detail, only to make the reader untangle the words. On the other hand, the author tried to keep the discussion independent from technology choices at length, but also made the discussion less grounded in implementation.