Microservice Patterns - 3.3 Interprocess communication in a microservice architecture - Communicating using the Asynchronous messaging - 2

Reference

https://www.amazon.com/Microservices-Patterns-examples-Chris-Richardson/dp/1617294543

Using a message broker

• broker-based architecture
• brokerless-based messaging architecture

BROKERLESS MESSAGING

• ZeroMQ:  http:// zeromq.org
• Benefits
• lighter network traffic and better latency because no middle broker
• No broker to be the bottleneck
• less operational complexity because no broker
• Drawbacks
• Services need to know about each other’s locations
• reduced availability because sender and receiver must be available (Same as when using synchronous, request / response
• Hard to implement guaranteed delivery

OVERVIEW OF BROKER-BASED MESSAGING

• Examples
• ActiveMQ (http://activemq.apache.org)
• RabbitMQ (https://www.rabbitmq.com)
• Apache Kafka (http://kafka.apache.org)
• AWS Kinesis (https://aws.amazon .com/kinesis/)
• AWS SQS (https://aws.amazon.com/sqs/
• Benefits
• Sends don't need to know consumers' location
• Broker buffer message until consumer available
• Consider to select MQ
• Supported programming language
• Supported messaging standard, such as AMQP or STOMP
• Messaging ordering ( low latency broker might not support ordering )
• Delivery guarantees ( high latency )
• Persistence ( high latency )
• Durability: What broker's behavior when disconnected?
• Scalability
• Latency
• Competing consumers: Does broker support?

IMPLEMENTING MESSAGE CHANNELS USING A MESSAGE BROKER

BENEFITS AND DRAWBACKS OF BROKER-BASED MESSAGING

• Advantage
• Loose coupling
• Message buffering
• Flexibility communication
• Explicit interprocess communication
• Downsides
• Potential performance bottleneck
• Potential single point of failure
• Additional operational complexity

Competing receivers and message ordering

• how to scale out message receivers while preserving message ordering =>  use sharded (partitioned) channels in Kafka

Handling duplicate messages

• Write idempotent message handlers
• duplicate messages are harmless
• Track messages and discard duplicates.
• 

Transactional messaging

• distributed transactions aren’t a good choice for modern applications

USING A DATABASE TABLE AS A MESSAGE QUEUE

PUBLISHING EVENTS BY USING THE POLLING PUBLISHER PATTERN

Publish messages by polling the outbox in the database. See http://microservices.io/patterns/data/polling-publisher.html.

PUBLISHING EVENTS BY APPLYING THE TRANSACTION LOG TAILING PATTERN

Pattern: Transaction log tailing Publish changes made to the database by tailing the transaction log. See http://microservices.io/patterns/data/transaction-log-tailing.html.