Message broker architecture - getting data back

I seem to fail to understand how to switch form the usual rest-api pattern for handling requests in a microservice architecture to a system where we use messages to return immediately 'promises' of the task beeing executed.

My understanding of the general idea:
-got request GET of something
-data retrival is long, so my gateway does this:

1. published to a queue the message that rappresents the tasks
2. return to the client immediately a 'ticket' that claims the task is being processed
3. stop.

-another ms does this:

1. picks up the task from the queue
2. does its lengthy thing
3. claims its over, he's done and result is ready

My question:
I understand well the merits of this, but how does the client get the result? in the end the client does need the result, not the promise that he'll get it.

Option 1:
the second ms publishes another message on another queue when result is ready, gateway picks it up and PUSHES to the client to notify that result is ready.
(having the need to hardwire the flow of messages in both directions, effectively doubling the complexity, and needing the gateway to initiate communication with client... sounds very spooky)

Option 2:
the end client periodically asks the gateway again if the task he submitted is now ready
(doesent this defeat the whole pourpose by sending a lot of unnecessary requests all the time flooding the system with requests? and i still need to hardwire more stuff in the gateway)

Please enlighten my obfuscated reasoning.