From a641eaa6c11b4fcc935a096d0f68969865c3c657 Mon Sep 17 00:00:00 2001 From: Hannah Hunter Date: Tue, 18 Jul 2023 17:23:39 -0400 Subject: [PATCH 1/3] clarify at-least-once and consumer groups Signed-off-by: Hannah Hunter --- .../building-blocks/pubsub/pubsub-overview.md | 14 +++++++++++--- 1 file changed, 11 insertions(+), 3 deletions(-) diff --git a/daprdocs/content/en/developing-applications/building-blocks/pubsub/pubsub-overview.md b/daprdocs/content/en/developing-applications/building-blocks/pubsub/pubsub-overview.md index fa633486846..dd111d74621 100644 --- a/daprdocs/content/en/developing-applications/building-blocks/pubsub/pubsub-overview.md +++ b/daprdocs/content/en/developing-applications/building-blocks/pubsub/pubsub-overview.md @@ -100,16 +100,24 @@ Dapr solves multi-tenancy at-scale with [namespaces for consumer groups]({{< ref ### At-least-once guarantee -Dapr guarantees at-least-once semantics for message delivery. When an application publishes a message to a topic using the pub/sub API, Dapr ensures the message is delivered *at least once* to every subscriber. +Dapr guarantees at-least-once semantics for message delivery. When an application publishes a message to a topic using the pub/sub API, Dapr ensures the message is delivered *at least once* to every subscriber. + +> **Note:** All Dapr pub/sub components support the at-least-once guarantee. + +Even if the message fails to deliver, or your application crashes, Dapr attempts to redeliver the message until successful delivery. ### Consumer groups and competing consumers pattern -Dapr automatically handles the burden of dealing with concepts like consumer groups and competing consumers pattern. The competing consumers pattern refers to multiple application instances using a single consumer group. When multiple instances of the same application (running same Dapr app ID) subscribe to a topic, Dapr delivers each message to *only one instance of **that** application*. This concept is illustrated in the diagram below. +Dapr handles the burden of dealing with consumer groups and the competing consumers pattern. In the competing consumers pattern, multiple application instances using a single consumer group compete for the message. Dapr enforces the competing conusmer pattern when replicas use the same `app-id` without explict consumer group overrides. + +> **Note:** Not all Dapr pub/sub components support the competing consumer model. + +When multiple instances of the same application (with same `app-id`) subscribe to a topic, Dapr delivers each message to *only one instance of **that** application*. This concept is illustrated in the diagram below.

-Similarly, if two different applications (with different app-IDs) subscribe to the same topic, Dapr delivers each message to *only one instance of **each** application*. +Similarly, if two different applications (with different `app-id`) subscribe to the same topic, Dapr delivers each message to *only one instance of **each** application*. ### Scoping topics for added security From e58ba2ff7bb3c88dc654916049789fc6c8e30cf7 Mon Sep 17 00:00:00 2001 From: Hannah Hunter Date: Wed, 26 Jul 2023 15:42:11 -0400 Subject: [PATCH 2/3] add list of components that support consumerid Signed-off-by: Hannah Hunter --- .../building-blocks/pubsub/pubsub-overview.md | 13 +++++++++---- 1 file changed, 9 insertions(+), 4 deletions(-) diff --git a/daprdocs/content/en/developing-applications/building-blocks/pubsub/pubsub-overview.md b/daprdocs/content/en/developing-applications/building-blocks/pubsub/pubsub-overview.md index dd111d74621..1d1522888bf 100644 --- a/daprdocs/content/en/developing-applications/building-blocks/pubsub/pubsub-overview.md +++ b/daprdocs/content/en/developing-applications/building-blocks/pubsub/pubsub-overview.md @@ -102,16 +102,14 @@ Dapr solves multi-tenancy at-scale with [namespaces for consumer groups]({{< ref Dapr guarantees at-least-once semantics for message delivery. When an application publishes a message to a topic using the pub/sub API, Dapr ensures the message is delivered *at least once* to every subscriber. -> **Note:** All Dapr pub/sub components support the at-least-once guarantee. - Even if the message fails to deliver, or your application crashes, Dapr attempts to redeliver the message until successful delivery. +All Dapr pub/sub components support the at-least-once guarantee. + ### Consumer groups and competing consumers pattern Dapr handles the burden of dealing with consumer groups and the competing consumers pattern. In the competing consumers pattern, multiple application instances using a single consumer group compete for the message. Dapr enforces the competing conusmer pattern when replicas use the same `app-id` without explict consumer group overrides. -> **Note:** Not all Dapr pub/sub components support the competing consumer model. - When multiple instances of the same application (with same `app-id`) subscribe to a topic, Dapr delivers each message to *only one instance of **that** application*. This concept is illustrated in the diagram below. @@ -119,6 +117,13 @@ When multiple instances of the same application (with same `app-id`) subscribe t Similarly, if two different applications (with different `app-id`) subscribe to the same topic, Dapr delivers each message to *only one instance of **each** application*. +Not all Dapr pub/sub components support the competing consumer model. Currently, the following pub/sub components support this pattern: + +- [Apache Kafka]({{< ref setup-apache-kafka >}}) +- [Azure Service Bus Queues]({{< ref setup-azure-servicebus-queues >}}) +- [RabbitMQ]({{< ref setup-rabbitmq >}}) +- [Redis Streams]({{< ref setup-redis-pubsub >}}) + ### Scoping topics for added security By default, all topic messages associated with an instance of a pub/sub component are available to every application configured with that component. You can limit which application can publish or subscribe to topics with Dapr topic scoping. For more information, read: [pub/sub topic scoping]({{< ref pubsub-scopes.md >}}). From b55cb7bd69ea0be5c09845d44e4de37b49f3477e Mon Sep 17 00:00:00 2001 From: Hannah Hunter <94493363+hhunter-ms@users.noreply.github.com> Date: Wed, 26 Jul 2023 16:15:46 -0400 Subject: [PATCH 3/3] Update daprdocs/content/en/developing-applications/building-blocks/pubsub/pubsub-overview.md Co-authored-by: Mark Fussell Signed-off-by: Hannah Hunter <94493363+hhunter-ms@users.noreply.github.com> --- .../building-blocks/pubsub/pubsub-overview.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/daprdocs/content/en/developing-applications/building-blocks/pubsub/pubsub-overview.md b/daprdocs/content/en/developing-applications/building-blocks/pubsub/pubsub-overview.md index 1d1522888bf..3fc16c417a7 100644 --- a/daprdocs/content/en/developing-applications/building-blocks/pubsub/pubsub-overview.md +++ b/daprdocs/content/en/developing-applications/building-blocks/pubsub/pubsub-overview.md @@ -117,7 +117,7 @@ When multiple instances of the same application (with same `app-id`) subscribe t Similarly, if two different applications (with different `app-id`) subscribe to the same topic, Dapr delivers each message to *only one instance of **each** application*. -Not all Dapr pub/sub components support the competing consumer model. Currently, the following pub/sub components support this pattern: +Not all Dapr pub/sub components support the competing consumer pattern. Currently, the following (non-exhaustive) pub/sub components support this: - [Apache Kafka]({{< ref setup-apache-kafka >}}) - [Azure Service Bus Queues]({{< ref setup-azure-servicebus-queues >}})