Recently, on a short term contract, I had to deal with a lot of PHP code that was running in a similar manner. I ended up using golang, to monitor the queue and spin up Goroutines that executed the PHP code ONCE. Between the concurrency, and php back in "one and done" mode the problem was "solved" and the internal team happily took over finishing the porting to pure Golang. Its a great example of Go "in the small" and it really does shine.

Go "in the large" is a whole other matter. You should read the following (in this order)

http://thenewstack.io/a-survey-of-5-go-web-frameworks/ <<< Im a user of gorilla/mux gorilla/context and alice for middleware chains. Gorilla/context and alice are not mentioned by this article, but the lament a the end about the concept of context being lacking in golang is spot on.

https://blog.golang.org/context <<< but this would be better for context however its does not mix with the current HTTP server (no ones solution does)... its from the go team but there isn't a lot of indication on how to use it and be future proof

https://joeshaw.org/net-context-and-http-handler/ <<< explains the context package well

https://github.com/remind101/pkg <<< has wrappers for getting net/context into gorilla and alice..

The end result is non of the GO web support is what I would call "great" yet. However it isn't stopping me from building with them. Look at the tradeoffs your going to have to make, be smart about how you couple your business logic to your server/framework, as your framework will quickly become a hard dependency. If your careful in that implementation, this http://blog.golang.org/introducing-gofix might be a way to back out one of those dependency if your unhappy.

The tooling to help you root out an issues exists and you should know its there and how to use it: http://blog.golang.org/profiling-go-programs http://saml.rilspace.org/profiling-and-creating-call-graphs-... https://deferpanic.com/blog/compile-time-code-weaving-in-go/