This post is a collection of content from David Boike from the Particular.net blog calling out some common problems and solutions for building message based distributed systems. They are relevant to anyone building apps using messaging, and anyone building a Microservice based solution should definitely be interested in the first post about slimming down events. It goes a long way towards avoiding unwanted coupling between services.
Slimming down your events
Anybody can write code that will work for a few weeks or months, but what happens when that code is no longer your daily focus and the cobwebs of time start to sneak in? What if it’s someone else’s code? How do you add new features when you need to relearn the entire codebase each time? How can you be sure that making a small change in one corner won’t break something elsewhere?
Complexity and coupling in your code can suck you into a slow death spiral toward the eventual Major Rewrite. You can attempt to avoid this bitter fate by using architectural patterns like event-driven architecture. When you build a system of discrete services that communicate via events, you limit the complexity of each service by reducing coupling. Each service can be maintained without having to touch all the other services for every change in business requirements.
But if you’re not careful, it’s easy to fall into bad habits, loading up events with far too much data and reintroducing coupling of a different kind. Let’s take a look at how this might happen by analyzing the Amazon.com checkout process and discussing how you could do things differently. Read on…
Do you need ordered delivery?
In our family it’s a tradition that you get to decide what we’ll have for dinner when it’s your birthday. On my daughter’s last birthday, she picked pizza. I took her to the nearby pizza shop to decide what pizza to get.
A large screen dominates one wall of the pizza place, showing each order as it progresses through each stage of preparation. As I was looking at the screen, I noticed some names suddenly switched. Some pizzas with fewer toppings could be placed in the oven faster, and some would take longer to bake than others. In various steps towards putting the pizza in its box, the process could take longer depending on the pizza. My daughter’s pizza required additional preparation time, so other customers were able to leave before we were. In short, pizzas were not being delivered in the same sequence as they were ordered.
So, is ordered delivery really required? Read on…
Conclusion
Hopefully you’ve found these interesting and useful for building your own distributed application. For comments about the content of these two posts be sure to post on the Particular blog so that they will are sure to be seen by the authors.
The post Messaging Practices appeared first on .NET Blog.