Hacker Newsnew | past | comments | ask | show | jobs | submitlogin

pretty much the same way a push load balancer does https://github.com/jackdoe/back-to-back/blob/master/broker/b...

    for {
      select {
      case reply := <-replyChannel:
       if reply.Uuid == r.message.Uuid {
        return reply
       }
      case <-timeout:
       return makeError(r.message, MessageType_ERROR_CONSUMER_TIMEOUT, "consumer timed out")
      }
     }
not much different than what you do with normal http timeouts, you send a request, sometimes a response comes sometimes it doesnt, up to the load balancer to decide if it wants to retry or error out

also, queue does not mean async model, it means a queue, there are many queues in http requests responses (e.g. the listen(2) backlog queue itself) and it does not make it async :)



> queue does not mean async model

“Message queues implement an asynchronous communication pattern between two or more processes/threads whereby the sending and receiving party do not need to interact with the message queue at the same time.”

https://en.m.wikipedia.org/wiki/Message_queue


if you read what i wrote, you will see that it is not asynchronous communication.

and it is not a message queue in the sense you mean, it is a request response queue, it just happens to be using messages

when people think of message queue they are thinking of async event driven communication, and this is not it


And what happens if your request modifies state but the response is not received?


exactly the same as push load balancing when it doesnt receive the instance's response due to network failure, but the state is modified




Consider applying for YC's Winter 2027 batch! Applications are open till November 2.

Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: