Q4) Server (avg response 500ms) <---> Security Gateway (timeout is 100ms) <---> Client (React UI) This is a setup where the average server response time is 500ms, but the organization's security gateway is 200ms. You can't change the security gateway. And also you can't greatly scale the server.. (ex by adding more machines and loadbalancing them, introducing caches like Redis for faster lookup etc to reduce the response time from 500ms). So the avg response time 500ms is fixed. You have only control over the client and server. And can make small changes.
Sigiloso
Answer: My approach was: Breaking the request and response. -> When the client requests the server, then the server returns a success response with a UUID. -> then the server computes the request and upon finish keeps the response in a map/in-memory cache with UUID as key and response as value. -> When the client receives the UUID, it queries next with the UUID at a certain interval. -> The server then receives the UUID, and if the UUID is still not computed or not present in in-memory, then it returns a response with status 'InProgress'. or if the computation is finished and the response is available in in-memory cache, it returns the computed response and removes the UUID/response pair from the cache/map. -> If the client receives the response 'InProgress' then again after some interval it will query the server with the same UUID. -> after the threshold no of retries the client exits with the error message to the user.