Since lesson 4.12.1 the Kladde asks its tenders over the network. The lab there ended with a line that didn't exist in the monolith: “Service stopped: HttpRequestException, ConnectionError”. This lesson clarifies what a caller does with that line. The most important answer is often not a better call, but no call at all: Whoever owns the data they need doesn't have to ask anybody at the decisive moment.
Two ways to talk
Between services there are two basic forms. They differ less in technology than in who waits for whom:
| Request with response (synchronous) | Message (asynchronous) | |
|---|---|---|
| Technology in the Kladde | HTTP with JSON, gRPC | Service Bus: queue for commands, topic for events |
| Who waits? | the caller, until the response is there | nobody; the sender hands the message over and carries on |
| Do both have to be running? | yes, at the same moment | no; the message waits in Service Bus |
| Typical content | a question (“which tenders match?”), a command with an immediate result | an event (“tender imported”), a command whose result comes later |
| What happens in a failure | the caller gets an error and has to decide now | the message is delivered later, at least once (lesson 4.6.1) |
The rule of thumb: Questions synchronous, events asynchronous. Whoever needs an answer to show something to their person right now, asks. Whoever tells others that something has happened, sends an event and waits for nobody. A command lies in between: “Reserve this tender” can be synchronous if the person is waiting for the result, or a message if the result may come later.