Messaging architecture

Message formats:

• Text, such as JSON/XML. Readable & easier for debugging.
• Binary. Eg: Protocol buffers (with self-defined tagged fields), Avro (requiring consumer to know the schema) & Thrift.

Message protocols:

• http. Eg: REST, SOAP. REST requires mapping calls to REST verbs.
• IPC, such as gRPC, a client-server framework using binary Protocol buffers.

Service discovery:

• Self registration with a service registry.
• Client service discovery. eg: Netflix Eureka: a HA service registry, Eureka client & Ribbon, a http client. Pivotal Spring Cloud, a Spring Java client that works with Eureka.

Message types:

• Document
• Command
• Event

Message channels:

• Point-to-Point channel: 1-1 interaction.
• Pub-Sub (Publish-Subscribe): 1:many interactions.

Message notifications:

• One-way notification: no reply required.
• Pub-Sub: Async responses.

Message broker?

• Brokerless messaging: Peer-to-peer (P2P) like ZeroMQ. Simple, performant, guaranteed delivery complex, reduced availability.
• Message broker: Helps two services communicate. Popular.

Message broker:

• Standards: AMQP, STOMP.
• Open source: ActiveMQ (queues/topics), RabbitMQ (exchanges/queues), Apache Kafka (Topics).
• Cloud: AWS Kinesis (streams), AWS SQS (queues). Uses sharding to improve availability.

Database for idempotency:

Another abstraction layer. Choose a database & store unique messages based off an id (say message id) to implement idempotency. Push to message broker from db.

• Debezium / Eventuate Tram: Db to Kafka.
• LinkedIn Databus: Oracle transaction log published as events.
• DynamoDB streams: Time-ordered DynamoDB log & publish as events.

Source: Microservices Patterns by Chris Richardson