A synchronous call fits a familiar moment: a user clicks a button and expects an immediate response. A frontend can call a backend through HTTP-REST, wait for confirmation, and then tell the user the action was received. REST is easy to adopt and can serve both frontend-to-backend and service-to-service communication. section 18.5.2 section 17.3
The trade-off changes when one service must call another to answer a request. If that service depends on a third, each waiting request depends on the next service being available. Synchronous communication can create temporal and physical coupling; one failure may cascade across services. A local cache can reduce reads, but keeping it current without change notifications is difficult. section 17.3.1
Choose the exchange according to what must happen before the caller receives an answer:
- Use a synchronous response where immediate feedback matters, especially for service-internal reads and writes or genuinely real-time interactions. section 17.1 section 17.3.2
- For exchange between services, consider asynchronous change notifications instead of repeatedly requesting the latest data. A service can precompute what it needs when an event occurs. section 17.3.2
Confirm the click, not the whole workflow
Do not write a button click to Kafka and keep the user waiting for another system to process it and send a reply through Kafka. One option is to record the action in a synchronous relational database, acknowledge receipt, and move the data to Kafka using CDC and the Outbox Pattern. Later updates can report progress. If the backend needs no database, it can accept a synchronous REST call, produce to Kafka, and confirm that the action was triggered—not that downstream processing is complete. section 18.5.2
Figure 18.8 We shouldn’t use Kafka for synchronous request-response communication. Instead, we notify users about asynchronous processes and confirm the process when it’s done.
The diagram separates immediate acknowledgement from completion of the asynchronous work. section 18.5.2
