Please enable JavaScript.
Coggle requires JavaScript to display documents.
Queues - Coggle Diagram
Queues
Message Exchange Types
- Direct (acts as Message Queue) - sending in round robin manner to one of the consumers (useful for scaling)
- Topic/ Header (acts as Message Queue) - i.e. topic by country and every county has own queue (because payment options for every country may differ); header is similar to topic, but uses header instead of topic name
- Fan-out (Pub/ Sub Model) - all consumers will receive the message
Pros & Cons
PROS:
- Scalability (services can scale independently)
- Loose Coupling (between services) - producers and consumers are independent, they may be implemented with different technologies
- Async. Execution (Non-blocking) execution, increases throughput
- Improves reliability of the system (If some of the services crashes, this won't affect the other services; messages won't be lost)
- The queue acts as a buffer, and the messages won't be lost if a service crashes
CONS:
- Increased Complexity => Additional layer, Additional code to implement async execution
- Increased latency (response time)
Messaging Models
- Message Queue
-- Action (async action)
-- The message is delivered once (payment should be processed only once)
-- Messages arrive out of order
-- Adds scalability because we may add more consumers to process messages faster
- Message Queue:
A message queue receives incoming messages and ensures that each message for a given topic or channel is delivered to and processed by exactly one consumer.
An example scenario is issuing paychecks–it is critical that every paycheck is issued once and only once, but it does not matter which exact processor issues each check.
- Message queues can support high rates of consumption by adding multiple consumers for each topic, but only one consumer will receive each message on the topic.
- Message queues support use cases where it is important that each message is processed (and only processed once), but it is not necessary to process messages in order. For example, in the case of network or consumer failures, the message queue will try re-sending an affected message at a later time (not necessarily to the same consumer) and as a result, that message may be processed out of order.
- Publisher/ Subscriber
This one is used when we want to notify multiple subscribers about an event that happened i.e. we want to notify RecieptService and BillingService that payment is successful.
-- Notifications
-- At least one delivery
-- Messages arrive in the same order (since there is are no retries)
- publish-subscribe messaging allows multiple consumers to receive each message in a topic
- pub-sub messaging ensures that each consumer receives messages in a topic in the exact order in which they were received by the messaging system
- Publish-subscribe use cases are frequently associated with stateful applications. Stateful applications care about the order of messages received because the ordering of messages determines the state of the application and will, as a result, impact the correctness of whatever processing logic the application needs to apply.
Products
- RabbitMQ
-- AMQP protocol
-- Stores until one of the consumer reads it
-- Used to schedule heavy tasks
-- Used to distribute load between servers
-- Supports Fan-out, Direct & Topic/ Header exchange types
-- Supports channels in order to reuse single TCP connection (because it's expensive to create) for message exchange
-- Supports acknowledgement mechanism
-- Very useful for payments as we want to know if the payment is processed successfully
PROS:
- Best as message queue
- Can act as Pub/ Sub
- Provides reliability thanks to acknowledgements
- Concurrency through channels
- Kafka
-- Most popular
-- Event-streaming platform
-- Pub/sub model
-- Messages are deleted after specific period of time (no acknowledgements)
-- In Kafka, Queues = Topics & Messages = Events
-- Events have: key, value, timestamp
-- Topics are sharded (partitioned)
-- The partitions are divided between consumers
-- If there are more consumers than partitions, some consumers won't receive any messages => we need as many partitions as the target count of the service instances
-- Can process 100K+ events per sec.
-- Slow consumers don't affect performance
Pros & Cons:
++ Higher Throughput (thanks to partitions)
++ If consumer crashes, no messages are lost
-- Increased Latency (when too many partitions)
-- Be careful how many partitions you will pick and why! (on interview you will be asked)
Consumer groups:
- Every group will get the message once
- Only one instance of the service will read the message
Consumer Offsets:
- Each consumer reads the messages from the queue in it's own pace. When consumer reads the message, it increases it's offset
- If consumer crashes, no messages are lost
PROS:
-- Producers append new messages in the end of the queue:
---Appending is very fast
--- The order of the messages is preserved
--Easier to delete older messages
Purspose:
- Asynchronous (Non-blocking) Messaging (we don't wait for response)
-- We put a message in a queue, so that the slower service can process the messages on their own and we don't have to wait for response. This is a way to decouple services.
Role Types of Services, regarding Queues:
- Producer (inserts messages in the queue)
- Consumer (reads messages from the queue)
Acknowledgment in order to delete the message in the queue:
-- Automatic - delete the message asap when the message is sent
-- Explicit - only when consumer confirms that it has received the message
(Acknowledgement is the ability of the queue to wait for consumer to confirm that the message is received before the message is deleted from the queue)
-