Exposing an Internal Process as a Partner API Under a Rate Cap
A logistics company has an existing Boomi process that accepts shipment inquiries from internal systems and queries a mainframe via a connector. A partner now wants a REST endpoint for the same inquiry. The partner will send up to 40 requests per second at peak and expects a JSON response within 800 ms. The mainframe tolerates no more than 15 concurrent inquiries and starts returning errors above that. The internal process currently returns a flat file and has no authentication beyond network location. The partner contract requires an API key plus OAuth-style bearer tokens, and the security team wants per-partner usage visible.
1. Describe the API layer you would put in front of the existing process and how you would protect the mainframe, being specific about where throttling and concurrency limits belong.
Read the worked answer
Do not expose the internal process directly. Put a managed API in front of it that terminates authentication, enforces policy, and translates JSON to the internal contract, then calls the existing process as the backend.
Authentication belongs at the gateway: validate the API key to identify the partner, then validate the bearer token, rejecting unauthenticated traffic before it reaches any integration logic. Usage visibility also belongs at the gateway, since that is the only point that sees every request regardless of backend outcome.
Protecting the mainframe needs two distinct controls, and conflating them is the common mistake. A rate limit caps requests per second per partner - set it near the contracted 40/s so a single partner cannot monopolize capacity. A concurrency limit caps in-flight mainframe calls at 15 or slightly below, queuing or shedding excess. Rate limiting alone will not save the mainframe, because 40 requests per second with slow mainframe responses can still produce far more than 15 simultaneous calls.
The 800 ms target interacts with this. If the mainframe is slow, queuing behind the concurrency cap will breach the target. Measure mainframe latency first; if p95 latency times expected concurrency exceeds 800 ms, the queue depth must be bounded and excess requests returned as a retryable error rather than held, so the partner sees a fast failure instead of a timeout.
2. The partner reports intermittent 429 responses during their own peak. What do you check before raising the limit?
Read the worked answer
Check whether the 429s are the rate limit, the concurrency cap, or the mainframe itself, because each has a different remedy and raising the wrong limit makes things worse.
Start with gateway telemetry: are rejections counted against the per-second rate limit, or are they queue-shed events from the concurrency control? If they are queue sheds, the partner's request rate is within contract but mainframe latency is stretching in-flight time, so raising the request limit would deepen the queue and increase sheds. The real fix is mainframe throughput or caching.
If they are genuine rate-limit rejections, compare the partner's observed request pattern to 40/s. Bursty clients often exceed the average briefly; a token-bucket allowance with modest burst capacity absorbs that without raising the sustained ceiling. Also confirm the limit is scoped per partner and not shared, since a shared bucket would make one partner's traffic affect another's.
Finally, verify the 429 responses carry a retry hint and that the partner honors it. Many "intermittent 429" reports are clients retrying immediately, which amplifies load. Only after these checks would I consider a limit increase, and then only with mainframe headroom confirmed.