@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