Pub/Sub API and Event Allocations

Check out allocations for Pub/Sub API, including the event message size, how many events you can publish and request, and how many events can be delivered to subscribers.

Check out allocations related to event publishing.

We recommend that the total size of a batch of events in a PublishRequest doesn’t exceed 3 MB. The 3 MB recommendation is below the gRPC 4 MB limit and ensures optimal performance. If your PublishRequest exceeds 4 MB, the publish call fails with this gRPC error, and the server closes the stream.

Each event message in a batch in a PublishRequest has a maximum size of 1 MB. If you publish a batch of events containing an event larger than 1 MB, the PublishResult of that event contains an error, and the event can’t be published. Each event in the batch has its own PublishResult, so it can still be published if there are no errors.

We recommend that you send no more than 200 events in one publish request for best performance results.

Platform events are subject to an hourly publishing allocation. For more information, see Platform Event Allocations in the Platform Events Developer Guide.

Check out allocations related to event subscription.

The maximum number of events that can be requested across all FetchRequests or ManagedFetchRequests in a Subscribe or ManagedSubscribe call, respectively, is 100. If a client requests more than 100 events, the server considers the number of requested events to be 100. The client sets the number of events to request in the num_requested field of the FetchRequest or ManagedFetchRequest. The server adjusts the total number of requested events based on the requested events sent in one or more requests and how many events were already delivered.

The maximum number of unique managed subscriptions that can be created per Salesforce org is 200.

When you subscribe with the Pub/Sub API, the event delivery allocations for platform events, change data capture events, and real-time event monitoring events apply. For more information, see the documentation for each event type.

A gRPC channel can have a maximum of 100 concurrent streams on an underlying HTTP/2 connection. Concurrent streams are RPC calls that are made on the same gRPC channel and that are active at the same time. For example, if a client uses one gRPC channel and makes 100 RPC requests on that channel concurrently, such as GetTopic and Subscribe requests and others, the client hits the concurrent stream limit. After the limit is reached, additional RPCs are queued in the client and must wait for active RPCs to finish before they’re sent.

For more information and for a workaround, see Performance Best Practices in the gRPC documentation.