Amazon Simple Queue Service (SQS) and Amazon Simple Notification Service (SNS).

Enterprise messaging happens at a higher level than that of UDP packets or direct TCP
connections . Not email, texts.
A message typically contains the payload — whatever information your application sends:

 XML,
 JSON,
 binary data, and so on.
-You can also add optional attributes and metadata to a message.

[SQL is a special-purpose programming language designed to handle data in a relational database

management system. A database server is a computer program that provides database services to
other programs or computers, as defined by the client-server model.

Therefore, a SQL Server is a database server that implements the Structured Query Language (SQL).]
 Similarly, a messaging server or service allows a place for your messages to be stored
temporarily and transmitted.

-----x--------------x-------------------------x---------------------------x--------------------------x---------------

The queue and the topic

-For a database service, the main resource is a table.

-In a messaging service, the two main resources are the queue and the topic.

.
1.QUEUE

A queue is like a buffer. You can put messages into a queue, and you can retrieve messages
from a queue.

The software that puts messages into a queue is called a message producer and

the software that retrieves messages is called a message consumer

2. TOPIC

A topic is like a broadcasting station.

You can publish messages to a topic, and anyone interested in these messages can
subscribe to the topic.

Then, the interested parties are notified about the published messages.

-The software that broadcasts topics is called a topic publisher and

-The software that subscribes to broadcasts is called a topic subscriber.

When should you use messaging?
There are some common use cases that might instantly make you think “I should use messaging
for that!” Here are some of these use cases (to be discussed in greater detail in future posts).

 Service-to-service communication
You have two services or systems that need to communicate with each other. Let’s say a
website (the frontend) has to update customer’s delivery address in a customer
relationship management (CRM) system (the backend). Alternatively, you can set up a
load balancer in front of the backend CRM service and call its API actions directly from
the frontend website. You can also set up a queue and have the frontend website code
send messages to the queue and have the backend CRM service to consume them.

 Asynchronous work item backlogs

You have a service that has to track a backlog of actions to be executed. Let’s say a
hotel booking system needs to cancel a booking and this process takes a long time (from
a few seconds to a minute). You can execute the cancellation synchronously, but then
you risk annoying the customer who has to wait for the webpage to load. You can also
track all pending cancellations in your database and keep polling and executing
cancellations. Alternatively, you can put a message into a queue and have the same
hotel booking system consume messages from that queue and perform asynchronous
cancellations.

 State change notifications

You have a service that manages some resource and other services that receive updates
about changes to those resources. Let’s say an inventory tracking system tracks
products stocked in a warehouse. Whenever the stock is sold out, the website must stop
offering that product. Whenever the stock is close to being depleted, the purchasing
system must place an order for more items. Those systems can keep querying the
inventory system to learn about these changes (or even directly examine the database—
yuck!). Alternatively, the inventory system can publish notifications about stock changes
to a topic and any interested program can subscribe to learn about those changes.