Asynchronous programming lets distributed services communicate through messages without requiring the producer and consumer to be available at the same time. A producer places a message in a broker; a consumer retrieves it later, supporting event-driven architectures and separating service lifecycles. section 7.1 section 7.1.4
Common implementation concerns include:
- Use a message broker such as Kafka, RabbitMQ, or a cloud-provider messaging system to carry events between services. section 7.1
- Group messages into topics so services can share a broker while consuming only relevant streams. section 7.1.4
- Account for broker-specific protocols, client libraries, connection settings, credentials, versions, and programming-language dependencies. section 7.1.4
- For high event volumes, process events asynchronously at configured intervals instead of blocking on every incoming event. section 9.2.5
Hide broker-specific complexity behind a platform API
Service A can use a platform-provided messaging API to emit and consume messages while the platform uses Kafka underneath. Most application changes no longer require Kafka knowledge; specialized Kafka behavior remains isolated in a separate service accessed through HTTP or GRPC. This reduces coupling and the cognitive load for teams modifying common service behavior. section 7.1.5
Figure 7.10 Asynchronous messaging interactions
Visualizes a producer placing messages in a broker and a consumer retrieving them later, including the possibility that the consumer is temporarily unavailable. section 7.1.4
