This is interesting, I quickly wrote 2 triggers on a platform event. And when I fired them I could see 2 debug logs, saying both triggers were own transaction.
Both being own transaction means, they get own set of limits. Also as both are the async process you genuinely don't care about the order of execution.
I have made architecture where we split our process via events and subscribe via triggers, but never tried something like having 2 triggers on 1 event.
I believe you can do this when you wanna make a couple of complicated processes independent of each other. Having multiple subscribers to same event do makes sense in my opinion.
Maximum size allowed is 1048576 bytes (1.05MB)
When you exceed the limit, you will get below message:
(Database.Error[getFields=();getMessage=The event payload size of 1179064 bytes exceeds the maximum allowed size of 1048576 bytes;getStatusCode=PAYLOAD_SIZE_EXCEEDED;])
TESTING:
Create a platform event POC_PE__e and create 9 long text fields and use below apex method:
public static void publish() {
String str = '1234567890', longStr = '';
for(Integer i=0; i<100; i++) str+='1234567890';
for(Integer i=0; i<131; i++) longStr+=str;
longStr = longStr.left(131000);
System.debug(poc.getBytesSize(longStr));
POC_PE__e pe = new POC_PE__e(Long_String__c=longStr,
Long_String2__c=longStr,
Long_String3__c=longStr,
Long_String4__c=longStr,
Long_String5__c=longStr,
Long_String6__c=longStr,
Long_String7__c=longStr,
Long_String8__c=longStr,
Long_String9__c=longStr
);
System.debug(JSON.serialize(pe));
String APIs = '"attributestypePOC_PE__eLong_String__cLong_String2__cLong_String3__cLong_String4__cLong_String5__cLong_String6__cLong_String7__cLong_String8__cLong_String9__c"';
System.debug(poc.getBytesSize(JSON.serialize(pe))-poc.getBytesSize(APIs)); //1179064 bytes
Database.SaveResult sr = EventBus.publish(pe);
if(sr.isSuccess()) System.debug('SUCCESS => '+sr.success);
else System.debug('ERROR => '+sr.getErrors());
}
Long_String__c, Long_String2__c.... are event fields.
Solution:
Use this method to get string bytes size (used in example above)
public static Integer getBytesSize(String str) {
Blob myBlob = Blob.valueof(str);
return myBlob.size();
}
Got to this by using https://mothereff.in/byte-counter.
Number of chars is same as number of bytes. Note: we get exact bytes size (1179064 bytes) shown in error message (1179064 bytes).
Conclusion:
Salesforce serialises the event object(s) for transmitting to various destinations and deserialises before delivering. Only data is calculated for message size and not field API or Object API names.
Additional info:
Same is the case with lightning platform - got confirmation from salesforce support. Thats the reason you see error message on object record page when so many formula,lookup,rich text fields are included in page layout
Best Answer
Platform events are inherently momentary. They don't have a duration as such, but they are stored on the platform for 24 hours to facilitate replay.
Events exist in a channel, a stream, which is watched by one or more subscribers. They aren't independent objects, they don't store state, and they have no permanence - they simply represent some occurrence that is to be observed. If an event exists, it has been published; there's no transition into or out of a published state.
The CometD-based Streaming API, on which Platform Events are built, supports a replay mechanism, whereby subscribers can jump backwards in the stream of messages to a fixed point (the Replay ID of the last message they received) and have messages between that point and the present re-sent to the subscriber. That doesn't imply that the events are in a "published" state for 24 hours (because, as above, events don't have that kind of state), but that they can be accessed by a client through replay during that time window. For example, if a client drops connection for an hour, it can replay all of the events since the last event it received by supplying that event's replay ID. If its connection drops for more than 24 hours, it's out of luck.
Replay is available only through API subscriptions, not Apex.