Reflection for async api

We have 2 services, lets call then S and G. S has a series of steps say a,b,c,d,e,f and at step d it makes a call to service G. G often takes a lot of time (spanning over minutes) to process the call leading to lots of timeout issues. To solve this we are planning to make G's APIs asynchronous. G has almost 20 APIs which need to made as async. I have 2 questions while designing this:

1. the ideal way to make these async would be to use SQS or SNS topic and make S listen on them. But this is an intrusive change and would require lots of refactoring of code, in this case splitting the steps a,b,c,d,e,f. We are looking for something fast. Hence we are planning to store the request id in some key value store and let G's API return a success after basic sanity checks and in the background keep processing the request. As soon as it is done, the result is updated in the key-value store and meanwhile G keeps polling the store at regular intervals. Does this look like a correct approach?

2. To make G's APIs asynchronous we would have to change/write whole lot of code for all 20 APIs. I was thinking of exposing one single API which uses reflection to identify which method to call at runtime. I know about problems associated with reflection such as no compile-time error detection, hard to refactor, slower performance and since we are introducing reflection in API facing outside clients there would be a lot of problem doing sanity checks of the method name being passed. The only pro is it makes my code a lot cleaner with minimal interference.

I would like to know what should be my way ahead to solve the above problem.

Thanks