I need suggestion / recommendation on the design approaches mentioned below.

UseCase: I have a usecase where a client uses my system to generate some recommendations. Now, these recommendations are generated in 2 phases. In the first phase, client sends some payload and I make a DB call and a service call to generate an intermediate recommendation. This process takes around 30-40 seconds. In the second phase, cliend sends some additional data and I filter the intermediate recommendations with that additional data. In the second phase I make a DB call and a smaller LLM model (so the average latency would be 3-5 seconds. Following are my questions.

For the first phase, there are three approaches.

1. I ask the client to push a message to FIFO Queue, and a poller within my service polls the message.
2. I could be to create a standard API, accept the request and start the task execution on a separate thread.
3. The third approach is same as above, just that instead of processing in background pushing a message to a queue, and a consumer will poll for messages.

3rd one is ruled out as it doesn’t offer much value and I will always have 1 client, Amongst 1 and 2, I am more aligned on #2, because using a queue looks like an overkill here. Does anyone have any thoughts on this?

For the second phase, there are 2 approaches

1. Implementing a blocking API where I wait for the smaller model call to complete.
2. Implement a status message based API where on first call I accept and process the smaller llm call on a separate thread, and then let the client poll and i could return with either in-progress or success call.

I am preferring approach 1 here, since it keeps things simple (as the max latency I would want for this API would be 2-3 seconds). However, the downside is that the system resources would be held (threads). Does anyone have any thoughts on this?