In Module 7, Tiffin handed slow work to a queue: "send this receipt email", and one worker picked it up and did it. That's a message with exactly one job and exactly one place to go.
Now Tiffin is split into services (Module 11), and a lot of messages aren't jobs at all. They're news. "Order 5521 was placed" matters to the restaurant service, the rider dispatch service, the notifications service, the loyalty points service and the analytics pipeline. Each of them needs its own copy. That's a different pattern, called publish/subscribe, and this module is about it.
The chain of calls
Here's how checkout looked right after Tiffin split into services. When an order is placed, the order service calls everyone who needs to know:
This has three problems that get worse as the company grows.
It's slow. If each call takes 50 ms, four calls add 200 ms before the customer sees "Order placed". In parallel it's better, but the slowest call still sets the pace.
It's fragile. If the loyalty service is down, does checkout fail? It shouldn't. Points can be added later. But with a direct call, the order service has to decide, for every downstream service, what to do when it's unavailable. Module 12 showed how one slow service can take down the ones calling it.
It's tangled. Every time a team wants to react to new orders (fraud checks, a "first order" coupon, a restaurant dashboard), the order team has to add a call, test it and deploy. The order service ends up knowing about every other service in the company.