Introduction to Messaging

What is messaging?

Sending data from one part of an application to another via a channel

Channel: Could be a web-socket connection, HTTP request, etc

What are the use cases of messaging?

1. Delivery guaranteed
   • We should have a way of knowing if the messaging was received by the client
2. Decoupled:
   • The server and client should not heavily depend on each other
     • We shouldn’t have to change the whole infrastructure if we decide to add more clients later on
3. Scalable and highly available:
   • Should have option to scale message broker to avoid single point of failure
4. Asynchronous:
   • System should not have to block and wait for a response
   • Asynchronous messaging allows for a fire and forget approach

Messaging Design Patterns

Broker

• Manages the connection between client and server
  • Responsible for distributing the messages
  • This is ‘glue’ that allows client and server to interact
  • Server: Refers to back-end that is running the messaging system

Types of messaging models

1) Point to point

• Used to send a message from the server, directly to one client

2) Publish-subscribe

• Message is ‘published’ to a channel
• The message broker will distribute the message to clients subscribed to that channel
  • Note: Subscribes have the message ‘pushed’ to them; they don’t have to ‘pull’ the message down such as in long-polling

Why use messaging?

Lets say we have a distributed system with many servers that run our application.

When it comes time to scale our application, we might choose to scale it horizontally by creating many instances of our application.

If we wanted all these instances to be able to communicate with each other we could use a message system.

This would act as a central-system that all instances can talk to.

For example:

One server can publish a message to a topic, and the rest of the servers can receive that message if they are subscribed to that topic.