Once Tiffin is split into services, they have to talk. When a customer places an order, Orders needs Payments to charge the card, Catalogue to confirm the prices, Dispatch to start looking for a rider, and Notifications to tell the restaurant.
There are three common ways to make those calls: REST over HTTP, gRPC, and messages through a broker. Each has a cost, and the costs aren't mainly about speed. They're about how tightly the services end up tied together.
Two styles: ask and wait, or tell and move on
Before picking a protocol, pick a style.
Synchronous request/response. Orders sends a request to Payments and waits for the answer before carrying on. Like a phone call: you ask, you wait, you get an answer.
Asynchronous messaging. Orders publishes a message ("order 81 was placed") to a broker and carries on immediately. Whoever is interested picks it up later. Like sending a letter: you don't wait at the post box.
%% caption: Synchronous: Orders waits for Payments. Asynchronous: Orders hands a message to a broker and moves on. sequenceDiagram autonumber participant O as Orders participant P as Payments participant B as Broker participant N as Notifications O->>P: charge Note over O: waits for the answer P-->>O: charged O-)B: order.placed Note over O: moves on N->>B: read when ready B-->>N: order.placed
The key difference is temporal coupling: whether both services must be up and responsive at the same moment. With a synchronous call, if Payments is down, Orders can't finish. With a message, Notifications can be down for ten minutes and catch up when it's back.