one solution stated to use a common dss/system setting to track the no. of api calls which I thought is not sufficient and not possible to implement w/o a queue system.
Are there solutions to this?
In my scenario, the example is not hit 10 tps, I think a queue processor which execute with a single thread in the node only, can be use with a wait method in the processing activity, for example, 0.12 seconds.
Say if the API is responded almost instaneously, with 0.12 seconds delay, then this will hit 8 tps.
In the case flow, the cases will call the queue processor, then while waiting for the API to be return, it will use a loop and a wait shape until the API response is returned.
@SvenKrow Don’t use a DSS counter to throttle TPS across nodes because it’s not atomic and you’ll get race conditions under load. A better pattern is to funnel all outbound calls through a Queue Processor (or dedicated Integration QP) and control throughput by limiting consumers to 1 (or a small number) and running it on a single dedicated node if you need a strict global TPS. If you need ~8 TPS, add a small delay inside the QP processing step, but avoid long “wait loops” in the case because that just ties up requestor threads. Instead, make the case fire-and-forget: enqueue the request, let QP call the API and persist the response/status, then have the case use a Wait shape that resumes on a status change (or a simple “response received” event) rather than polling. If you must scale later, use multiple QP consumers/partitions and compute TPS per consumer, keeping the total under the limit. If the limit must be enforced across multiple apps/systems, the cleanest option is an API gateway (Apigee/Kong/Mule/etc.) to rate-limit centrally and let Pega retry/backoff gracefully. Thanks