Allocations
Module 5 of 8 in the chapter Events, chapter 11 of the Integration Architect course. Each module stands on its own. Previous: Replay, Retention, Order · Next: Events Inside the Org
The question this module answers: How many events can you send, how many can be delivered, and does your design fit?
Two Meters
Section titled “Two Meters”Salesforce meters events twice. Here’s how I put it to a class.
The first meter is publishing: how many events you can put on the bus. Without buying anything, Performance, Unlimited and Enterprise Editions can publish 250,000 an hour, by any method: Apex, flows, the Pub/Sub API, the REST API. That’s about 6 million in 24 hours. Developer Edition gets 50,000 an hour (Default Platform Event Allocations for Event Publishing and Delivery (opens in a new tab), Platform Events Developer Guide, Winter ‘27, checked 2026-11-07).
The second meter is delivery: how many events go out to subscribers in 24 hours. And here’s the number that surprises people:
| Edition | Published, per hour | Delivered to outside subscribers, per 24 hours |
|---|---|---|
| Performance and Unlimited | 250,000 | 50,000 |
| Enterprise (and Professional, with the API add-on) | 250,000 | 25,000 |
| Developer | 50,000 | 10,000 |
From the same page, checked 2026-11-07. Six million in, 25,000 out. The meters aren’t balanced, and that’s deliberate. Both are rolling: publishing counts the last hour, delivery counts the last 24 hours.
Publishing from outside through the REST, SOAP or Bulk API also spends the org’s daily API requests (chapter 6). Publishing through the Pub/Sub API, Apex or a flow doesn’t.
Inside Is Free
Section titled “Inside Is Free”Look closely at what the delivery meter counts: Pub/Sub API and CometD subscribers, the empApi Lightning component, and event relays. What isn’t on the list? Apex triggers and flows. Deliveries inside the org don’t count against the delivery allocation.
So there are two kinds of delivery. A flow or a trigger in the same org listening to an event: not counted. A system outside listening to the same event: counted. That’s a powerful mechanism. You can publish events and catch them inside Salesforce, process to process, and only the publishing meter applies.
It isn’t free of everything, though. Salesforce’s guide adds that an Apex trigger’s or flow’s “event processing rate depends on the subscriber processing time and volume of events received.” Not counted doesn’t mean instant. That’s module 6.
Every Subscriber Counts
Section titled “Every Subscriber Counts”The delivery meter counts each delivery to each subscriber. Salesforce’s own example: an Unlimited Edition org, 20,000 events delivered to two subscribers. That’s 40,000 of its 50,000 used, not 20,000.
Two more things make it bigger than it looks:
- Platform events and change events share it. Change Data Capture to an outside subscriber spends from the same allocation (module 3).
- It’s for the whole org. Say five project teams each build an integration on events. The first sends 100,000 a day out, the second another 100,000, and the third runs out. Nobody broke a rule. They just never added it up.
So the number to work out is: events a day × outside subscribers, for every event and every subscriber in the org, against one allocation.
The Constraints Match
Section titled “The Constraints Match”Now Steve Trucking. Say the org is Enterprise Edition, the same “what if” as chapter 6. The Number of Zeros says about 26,400 status changes a day, going out to the integration layer.
Count deliveries: events times outside subscribers.
One subscriber, 26,400 deliveries a day, against 25,000. Steve Trucking is over on day one. Add a second outside subscriber, say Snowflake listening to change events directly, and it’s 52,800. And by year three, about 58,000 status changes a day: more than twice the allocation with just one subscriber.
This is why I teach allocations with the Number of Zeros. On a whiteboard, “status events to the integration layer” looks fine. With the zeros, it’s a constraint you have to design for, before go-live, not when the subscriber is disconnected at four in the afternoon.
There are three ways out, and they combine:
- Buy more. The platform event add-on “increases the 24-hour allocation of delivered event messages by 100,000 per day (3 million a month),” and publishing by 25,000 an hour (Increase Your Event Delivery and Publishing Allocations with a Platform Event Add-On License (opens in a new tab), Platform Events Developer Guide, checked 2026-11-07). It also changes the rules: usage becomes a monthly entitlement, with a grace allocation for spikes, so a busy day doesn’t disconnect anyone. Change Data Capture has its own add-on. Ask your Salesforce account team for the current terms.
- Send fewer. Below.
- Send it another way. Not every status change needs to be an event. Chapter 7 put “a batch underneath” Steve Trucking’s status events for exactly this kind of reason (Checkpoint 1).
Spend Fewer Deliveries
Section titled “Spend Fewer Deliveries”Salesforce’s own advice for staying under: filter the stream, and “Make sure you don’t have unnecessary subscribers. Each event delivered to a subscriber counts against the event delivery allocation” (Default Platform Event Allocations (opens in a new tab), checked 2026-11-07).
Filter. A custom channel with a filter sends a subscriber only the events it needs. At Steve Trucking, the Snowflake feed passes only Status changes (module 3). Every event filtered out is a delivery not counted.
One subscriber, then fan out. Steve Trucking has three partners that want status: Redrock, Keystone and Brightwave. If each subscribed to Salesforce, every status change would be three deliveries. Instead, one subscriber hears it and passes it on.
One subscriber spends one delivery, however many partners hear the news.
That’s one of the jobs of the integration layer: Salesforce publishes once, the layer subscribes once, and the layer handles each partner’s way of being told. Module 7 goes further: when many systems need many events, a broker outside Salesforce may be the better bus.
Send less often. If a subscriber only needs the latest status every 15 minutes, a scheduled job that sends the changes in one batch spends no deliveries at all. Events are for when “as it happens” is the requirement.
When You Run Out
Section titled “When You Run Out”The default allocations “can’t be exceeded.” What that means in practice depends on the meter (Default Platform Event Allocations (opens in a new tab), checked 2026-11-07):
- Over the publishing allocation: the publish call fails with
LIMIT_EXCEEDED, and “the events aren’t published or queued.” The publisher has to wait and publish them again. A flow that publishes needs a fault path for this (chapter 4). - Over the delivery allocation: “an error is returned and the subscription is disconnected.” In the Pub/Sub API, the error is
sfdc.platform.eventbus.grpc.subscription.limit.exceeded. The events aren’t lost yet: they wait on the bus for 72 hours, and as the rolling 24 hours moves on, the subscriber can reconnect and pick up after its last one (module 4). But a subscriber that keeps hitting the limit falls further behind every day, and at 72 hours it starts to lose events.
So running out of deliveries is a delay that turns into a gap. Plan for it never happening, and know what you’ll do if it does.
Watch the Meter
Section titled “Watch the Meter”You can see both meters (Monitor Event Usage Against Your Allocations (opens in a new tab), Platform Events Developer Guide, checked 2026-11-07):
- In Setup: on the Platform Events page, the Event Allocations section shows usage and the maximum.
- From the REST API: the
limitsresource returnsDailyDeliveredPlatformEvents, and with the add-on,MonthlyPlatformEvents. A monitoring job can read it every hour and warn someone at, say, 80%. - By SOQL:
PlatformEventUsageMetricbreaks usage down by event, by client and over time, so you can see which subscriber is spending the most.
Watch it from the first day of testing, not the first day in production: a test subscriber left connected in a full sandbox can spend real numbers.
The Other Numbers
Section titled “The Other Numbers”A few more allocations an architect should know are there, from the same guides, checked 2026-11-07:
| What | Performance and Unlimited | Enterprise | Developer |
|---|---|---|---|
| Platform event definitions in the org | 100 | 50 | 5 |
| CometD subscribers connected at once | 2,000 | 1,000 | 20 |
| Size of one event | 1 MB | 1 MB | 1 MB |
| Objects selected for Change Data Capture, without the add-on | 5 | 5 | 5 |
And for the Pub/Sub API: up to 100 events requested at a time (module 2), up to 200 managed subscriptions (Beta) in an org, and Salesforce recommends no more than 200 events in one publish request (Pub/Sub API and Event Allocations (opens in a new tab), Pub/Sub API Developer Guide, checked 2026-11-07).
Every number here changes by edition and by release. Check the current pages before you design, and write down which release you checked.
Test knowledge. Two meters: publishing per hour (250,000 in Performance, Unlimited and Enterprise; 50,000 in Developer) and delivery per 24 hours to outside subscribers (50,000 / 25,000 / 10,000). Deliveries to Apex triggers and flows aren’t counted. Every outside subscriber’s deliveries are counted, and platform events and change events share the delivery allocation. Over the publishing allocation, the publish fails and isn’t queued; over the delivery allocation, the subscriber is disconnected. Fewer deliveries: filtered channels, fewer subscribers, one subscriber that fans out, or the add-on.
What an Architect Decides Here
Section titled “What an Architect Decides Here”- The delivery count for the whole org: every event × every outside subscriber, today and in year three, against the edition’s allocation, with the release you checked written down.
- Which subscribers live inside the org and which outside, knowing only the outside ones are counted.
- One subscriber that fans out, or many, and which channels are filtered.
- Whether to buy the add-on, decided before go-live, from the numbers, not after the first disconnection.
- Who watches the meter, how, and at what level someone is warned.
- What happens when a meter runs out: the publisher’s fault path, and the subscriber’s way back inside 72 hours.
Explore
Section titled “Explore”- Default Platform Event Allocations for Event Publishing and Delivery (opens in a new tab): Platform Events Developer Guide, both meters by edition, and what happens when you run out (checked 2026-11-07)
- Increase Your Event Delivery and Publishing Allocations with a Platform Event Add-On License (opens in a new tab): the same guide, the add-on (checked 2026-11-07)
- Monitor Event Usage Against Your Allocations (opens in a new tab) and Common Platform Event Allocations (opens in a new tab): the same guide (checked 2026-11-07)
- Pub/Sub API and Event Allocations (opens in a new tab): Pub/Sub API Developer Guide (checked 2026-11-07)
- Change Data Capture Allocations (opens in a new tab): Change Data Capture Developer Guide (checked 2026-11-07)