Yes I think it can be a design smell. For example:
I think the issue your example displays is a faulty separation of concerns. For example, when looking at your example, I have to ask some questions:
- Does the Shelf Service only shelve books that are owned by the Owner Service?
- Does it make sense for the Shelf Service to try to shelve books that were just released by the Publisher Service?
and more along those lines.
As I look at what you described, there are multiple services that deal with “Books”. However, what might be really at issue is PurchasedBook, PublishedBook, etc.
Sometimes that separation of concerns can simply be managed by having separate queues. The “Book” message on the Purchased queue is inherently different than the “Book” message on the Published queue. You can route those queues between services and keep them as separate things.
Design Smell doesn’t always mean Design Problem
A design smell isn’t always indicative of a bad (i.e. failed) design. You have to go through and vet the design and make sure there are real problems that should be solved. For example:
- Asynchronous systems cannot guarantee message order unless the same producer generates both messages. As long as two autonomous services generate the messages you cannot guarantee message order.
- Is it clear where failures can be introduced, and are those failures by choice (i.e. design), or is it just something that happens sporadically.
If everything checks out, it isn’t necessarily bad design, but at the very least a confusing one. If things are working, you might find that “fixing” the design will lead to system instability until you resolve all the edge cases.