11–20 of 51 posts
Earlier quoted context omitted.
I disagree. The last version only had a message bus. Its an inversion of communication - instead of the Gateway knowing that it has to communicate to the other services, it just publishes an event and the inventory service knows that it has to listen to events from the Gateway (or even simpler: Just listen to 'inventory-updated' message).
Why is that different from an ESB?
I just love the way that consultancies are selling micro services as though it's some big thing that will revolutionise their business. Like big data or the cloud before it. Looking at the article it seems that you've got an event driven system at the end with some components / pieces of code handling events e.g. Update inventory, inventory updated.
...Phew! Turns out it's really "Is request-response the best Microservices architecture?"
I just love the way that consultancies are selling micro services as though it's some big thing that will revolutionise their business. Like big data or the cloud before it. Looking at the article it seems that you've got an event driven system at the end with some components / pieces of code handling events e.g. Update inventory, inventory updated.
REST is synchronous in terms of request/reply, but that doesn't mean that higher-level actions must (or even should) be restricted to that cycle, so subprocesses like the notification should never have to block the stock update. Even if the requester needs to be informed about that, the stock updating mechanism should instead create a new Resource that tracks the notifications, and send the link to it so that the client can see how it's going.
But this wouldn't be necessary, because I agree that the stock updating shouldn't have to known about the notifications - but again, REST does not require it to!
The way to architect this using REST would be for the Notification Service to track how the stock of each product is currently. Since polling each product is inefficient, the stock manager could offer a feed that lists the latest stock updates, just like blogs do with posts.
This doesn't require a SPOF like a messaging bus, it doesn't suffer from the "service going pop" problem (since we've eliminated the dependency the inventory service had on the email system) and it's proven to work at a huge scale - the web.