When one service must wait for another to answer, maintenance or failure in the second service can interrupt the first. Asynchronous communication lets services exchange events without waiting for downstream processing. With Kafka, a service produces data to a topic and other services consume it independently. section 1.2 section 17.1
Choose the communication path according to what the caller needs:
- Use an event when other services need to learn that something changed. They can update their own data before a later customer inquiry. section 17.3.2
- Keep synchronous communication where an immediate response is necessary. Kafka favors throughput, scalability, and decoupling, but requires messaging infrastructure and operational expertise. section 17.3.2
- Keep service-internal state in a relational database when appropriate; use Kafka to exchange data between services. Retained events let consumers recover or reconstruct state independently. section 17.6 section 1.1
Confirm the action, not the whole workflow
After a user clicks a button, do not send the action through Kafka and hold the web request open until another service replies. Record the action and acknowledge receipt; CDC and the Outbox Pattern can then move it to Kafka. As processing advances, subsequent events can update the status shown to the user. 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 contrasts a Kafka request-response wait with acknowledging a user action and reporting asynchronous progress. section 18.5.2
