diff --git a/daprdocs/content/en/developing-applications/building-blocks/pubsub/howto-subscribe-statefulset.md b/daprdocs/content/en/developing-applications/building-blocks/pubsub/howto-subscribe-statefulset.md
index 16db2b0c0..b53b28e16 100644
--- a/daprdocs/content/en/developing-applications/building-blocks/pubsub/howto-subscribe-statefulset.md
+++ b/daprdocs/content/en/developing-applications/building-blocks/pubsub/howto-subscribe-statefulset.md
@@ -39,7 +39,10 @@ spec:
 
 When subscribing to a pub/sub topic via Dapr, the application can define the `consumerID`, which determines the subscriber's position in the queue or topic. With the StatefulSets sticky identity of Pods, you can have a unique `consumerID` per Pod, allowing each horizontal scale of the subscriber application. Dapr keeps track of the name of each Pod, which can be used when declaring components using the `{podName}` marker.
 
-On scaling the number of subscribers of a given topic, each component in Dapr has its unique settings to determine the behavior. Usually, there are two options for multiple consumers: broadcast or shared. In the broadcast configuration, each message published to the topic will be consumed by all subscribers. While in the shared option, a message is consumed by any subscriber (but not all).
+On scaling the number of subscribers of a given topic, each Dapr component has unique settings that determine the behavior. Usually, there are two options for multiple consumers:
+
+ - Broadcast: each message published to the topic will be consumed by all subscribers.
+ - Shared: a message is consumed by any subscriber (but not all).
 
 Kafka isolates each subscriber by `consumerID` with its own position in the topic. When an instance restarts, it reuses the same `consumerID` and continues from its last known position, without skipping messages. The component below is an example on how a Kafka component can be used by multiple Pods: