Asynchronous messaging is the foundation for most service integrations. It’s proven to be the best strategy for enterprise architectures. It allows building a loosely coupled architecture that overcomes the limits of remote service communication, like latency and unreliability.
As you break out the monolith or continue to build services for platforms, different services have to interact. We want to avoid bottlenecks, synchronous I/O, and shared state.
In the example above Service A is triggering events and a message broker distributes these events to other services. When new services are deployed they can subscribe to the channel, and start getting messages as events happen.
Messaging infrastructure is reliable. Offering better encapsulation than a shared database. Perfect for asynchronous, event-based communication.
Different technologies have different constraints and offer specific guarantees. It’s important to be aware of these trade-offs. The most common services for messaging on AWS are SNS, SQS, AWS MSK (AWS Managed Kafka Service) and Kinesis.
Besides the known limitations and guarantees of each messaging service, there should be conscious considerations for message duplication, message ordering, poisonous messages, sharding, and data retention.