Does start_link returning mean the cache is warm?

Maybe the service doesn't have to hold anything. If clients already understand Warming, report it through readiness and let each one retry under its own limit. That's one less queue to explain, and this one would only exist to get through startup. If some client really can't retry, fine, add the wait. Give it a capacity and write down what a full queue tells the next caller.

The waiting option has two events to order, the caller's timeout and the removal of its pending request. The caller times out. Warming finishes. The server goes through its waiting entries and replies to this one before it gets to the withdrawal message. What happens then has to be defined.

With a process alias as the reply route, deactivating it drops anything sent through it afterwards, before it reaches the caller's queue. A reply sent just before deactivation is another story. It's already sitting in the queue, so the caller still has to recognize it as belonging to a request it gave up on. And the alias says nothing to the server. The waiting entry stays until something removes it, so the waiting set needs its own bound and its own way out.

A ready channel covers both of vadimk's cases. The warm-up goroutine closes it when it finishes. A readiness check does a non-blocking receive, a select with a default branch, and anyone who really wants to wait just receives. A closed channel releases every receiver at once. The waiting set is then just blocked goroutines, which is fine until request handlers pile up behind it, and then you're back at the capacity question.