The current PubSub model notifies consumers by making a roundtrip per message. A way to improve message throughput would be to allow consumers to declare the intention of consuming messages in batches. Processing messages in batches lead to the following optimizations:

• roundtrip reduction between dapr and consuming component by sending messages batches
• consumer computation by observing a message batch instead of a single item

Expected behavior: Subscribers can (optionally) choose to receive messages in batches.

Example of a subscriber's response where batching is requested:

{
  "subscriptions": [
    {
       "topic": "A",
       "maxBatchSize": "10"
    }
  ]
}

The optional parameter maxBatchSize defines the maximum number of messages to be delivered in a single receive loop. By default, maxBatchSize should be 1.

Message checkpointing in batch mode are for all messages (all succeeded or failed).

Distributed tracing should track each message inside the batch in such a way that users can still find them in the target telemetry backend. In other words, if messages A, B and C were processed in the same batch, searching for message B telemetry should return the batch execution.

In order to enable receiving multiple messages the subscriber callback contract could be changed from:

// NewMessage is an event arriving from a message bus instance
type NewMessage struct {
	Data     []byte            `json:"data"`
	Topic    string            `json:"topic"`
	Metadata map[string]string `json:"metadata"`
}

to

// Message is one event arriving from a message bus instance
type Message struct {
	Data []byte `json:"data"`
	Metadata map[string]string `json:"metadata"`
}

// NewMessages contains one or more events arriving from a message bus instance for a given topic
type NewMessages struct {
	Messages []Message `json:"messages"`
	Topic    string    `json:"topic"`
}

Impact

• Components Contrib: each implementation needs to handle the new property (impact on certification), defaults to "1" otherwise. Still need to change code so it can return an array of 1 and avoid compilation error.
• For GRPC, this is a breaking change given the change in proto change. Any example for GRPC will need to be fixed in every SDK as well.
• For HTTP, we can make use of the lack of structure and send the payload to subscriber as-is (CloudEvent) when batch size is configured to 1. When batch size is configured to greater value, the payload to subscriber is an array of CloudEvent.

Parent: #843
Note: At time of code checkin, submit a docs PR on this issue dapr/docs#2407