Update key_concepts.md

courses/level101/messagequeue/key_concepts.md

@@ -7,17 +7,11 @@ Lets looks at some of the key concepts when we talk about messaging queue system
 
 One of the essential aspects of messaging services is ensuring that messages are delivered to their intended recipients. Different systems offer varying levels of delivery guarantees, and it is crucial to understand these guarantees to choose the right messaging service for your needs.
 
-*   **at-most-once-delivery**
+*   **at-most-once-delivery**  This guarantee ensures that a message is delivered at most once to its intended recipient. In other words, messages may be lost, but they will never be delivered more than once. This approach is suitable for scenarios where message loss is tolerable and duplication is not desired.
 
-This guarantee ensures that a message is delivered at most once to its intended recipient. In other words, messages may be lost, but they will never be delivered more than once. This approach is suitable for scenarios where message loss is tolerable and duplication is not desired.
+*   **at-lesat-once-delivery**  Under this guarantee, a message will be delivered to its intended recipient at least once, but it may be delivered multiple times in case of failures. This approach is appropriate for situations where message loss is unacceptable, but duplication can be managed by the recipient.
 
-*   **at-lesat-once-delivery**
-
-Under this guarantee, a message will be delivered to its intended recipient at least once, but it may be delivered multiple times in case of failures. This approach is appropriate for situations where message loss is unacceptable, but duplication can be managed by the recipient.
-
-*   **exactly-once-delivery**
-
-This guarantee ensures that a message is delivered exactly once to its intended recipient, with no loss or duplication. This is the most stringent level of delivery guarantee and is suitable for applications where both message loss and duplication are unacceptable.
+*   **exactly-once-delivery**  This guarantee ensures that a message is delivered exactly once to its intended recipient, with no loss or duplication. This is the most stringent level of delivery guarantee and is suitable for applications where both message loss and duplication are unacceptable. However, it's important to note that it is challenging, if not impossible, for any messaging system to guarantee exactly-once delivery due to the inherent complexities and potential failures in distributed systems.
 
 Selecting the right delivery guarantee depends on the specific requirements of your application. For example, in financial transactions, an exactly-once delivery guarantee is essential to avoid double-processing of payments or missed transactions. In contrast, a log monitoring system may only require at-most-once delivery to reduce system overhead.
 
@@ -26,20 +20,16 @@ Selecting the right delivery guarantee depends on the specific requirements of y
 
 Ensuring the correct order of messages and processing them in parallel can be a challenge in distributed messaging systems. The following strategies help maintain order and ensure parallelism:
 
-* Strict ordering:
-In some cases, maintaining strict order is essential, such as when processing financial transactions. This may require additional overhead, such as sequencing numbers, buffering, and reordering messages.
+* **Strict ordering**:  In some cases, maintaining strict order is essential, such as when processing financial transactions. This may require additional overhead, such as sequencing numbers, buffering, and reordering messages.
 
-* Partial ordering:
-Partial ordering can be used when only a subset of messages must be ordered. For example, messages within a specific group or partition must be processed in order, but messages between groups or partitions can be processed independently.
+* **Partial ordering**:  Partial ordering can be used when only a subset of messages must be ordered. For example, messages within a specific group or partition must be processed in order, but messages between groups or partitions can be processed independently.
 
-* Unordered processing:
-In some scenarios, processing messages in any order is acceptable. This approach reduces complexity and enables higher parallelism, improving overall system performance.
+* **Unordered processing**:  In some scenarios, processing messages in any order is acceptable. This approach reduces complexity and enables higher parallelism, improving overall system performance.
 
 Strategies to maintain order and ensure parallelism:
 Partitioning messages by a key, using sequencing numbers, and buffering can help maintain order while still allowing parallel processing. It is crucial to strike the right balance between ordering requirements and parallelism to optimize system performance.
 
 
-
 ### Fan Out / In
 Fan out and fan in are two crucial concepts in messaging systems that deal with the distribution of messages among multiple consumers and the aggregation of messages from multiple producers, respectively.
 
@@ -60,10 +50,14 @@ A Dead Letter Queues (DLQ) is a separate queue used to store poison pills or mes
 To handle poison pills effectively, you can implement error handling and monitoring, set up retries with backoff policies, and use DLQs for further analysis and resolution. Regularly monitor the DLQ, identify patterns causing poison pills, and implement fixes in the message processing pipeline to prevent future issues.
 
 
-## Use case
+### Messaging Patterns
+
+#### Point-to-Point (Queue-based)
+In this pattern, messages are sent from a single producer to a single consumer via a message queue. The message is consumed by only one consumer, even if there are multiple consumers listening to the queue. This pattern ensures that the message is processed by a single consumer, making it suitable for scenarios where messages must be processed in sequence or by specific consumers.
+
+
+#### Publish-subscribe pattern
+The publish-subscribe pattern involves a producer sending messages to a topic, and multiple consumers subscribing to that topic to receive the messages. This pattern allows for one-to-many communication, where a single message can be delivered to multiple consumers simultaneously. It is ideal for event-driven architectures and applications that require real-time updates or notifications.
 
-### Work queues
-
-### Publish-subscribe pattern