A new upstream API Is being designed to offer an SLA of 500 ms median and 800 ms maximum (99th percentile) response time. The corresponding API…

Correct Answer: Set a timeout of 100ms; that leaves 400ms for other two downstream APIs to

complete

*****************************************

Key details to take from the given scenario:

>> Upstream API's designed SLA is 500ms (median). Lets ignore maximum SLA response times.

>> This API calls 3 downstream APIs sequentially and all these are of similar complexity.

>> The first downstream API is offering median SLA of 100ms, 80th percentile: 500ms; 95th

percentile: 1000ms.

Based on the above details:

>> We can rule out the option which is suggesting to set 50ms timeout. Because, if the median SLA

itself being offered is 100ms then most of the calls are going to timeout and time gets wasted in

retried them and eventually gets exhausted with all retries. Even if some retries gets successful, the

remaining time wont leave enough room for 2nd and 3rd downstream APIs to respond within time.

>> The option suggesting to NOT set a timeout as the invocation of this API is mandatory and so we

must wait until it responds is silly. As not setting time out would go against the good implementation

pattern and moreover if the first API is not responding within its offered median SLA 100ms then

most probably it would either respond in 500ms (80th percentile) or 1000ms (95th percentile). In

BOTH cases, getting a successful response from 1st downstream API does NO GOOD because already

by this time the Upstream API SLA of 500 ms is breached. There is no time left to call 2nd and 3rd

downstream APIs.

>> It is NOT true that no timeout is possible to meet the upstream APIs desired SLA.

As 1st downstream API is offering its median SLA of 100ms, it means MOST of the time we would get

the responses within that time. So, setting a timeout of 100ms would be ideal for MOST calls as it

leaves enough room of 400ms for remaining 2 downstream API calls.