We maintain an API that as part of its purpose makes a call to an external API. This external API takes a few seconds to fulfil the request we make to it. With our current architecture the request is made synchronously, meaning that the http response we return to the user request is blocked until our service get the response from the external API.
I am considering changing our architecture to be able to deal with the request asynchronously... By this I mean accept the user request into our API and put a message on a queue so that we return an http response a lot quicker. The response would contain the address of where the full/complete result can be found. A background task would then pick messages up from the queue and make the call to the external API, then store the result at the address provided in our response. The address could then be polled by the user/client until the desired state of the respource is reached (i.e. when the background task has finished calling the external api and has stored the result).
This architecture I have mainly lifted from the REST in Practice book. The crux however is that our external API only takes 2-3 seconds to return the response. The example in the book describes an ordering process that might take minutes or hours. Is this suggested solution worth the increase in complexity for such a short response time from our external dependency? i.e. will the application still scale with the existing synchronous architecture?