Be aware about a couple of issues in the implementation: - The Warp handlers are blocked by the use of thread-blocking synchronization primitives (locks, chann

Be aware about a couple of issues in the implementation: - The Warp handlers are blocked by the use of thread-blocking synchronization primitives (locks, channels) - which might harm performance and can even lead to deadlocks. - The architecture with "passing work off to a threadpool via a chnanel and waiting for it to complete" is not very resilient, and prone to behave badly under high load. The reason is basically the inifinite queuing - if new requests come in faster than previous ones can be processed the queue length (and thereby the memory footprint of the app) will grow and grow. At some point the application will just be busy serving old queued up requests, which might already have timed out on the client side and potentially even being retried. That's a vicious circle, and you can only get out ot it by shutting down the app. One way to fix this is to limit the queue/channel size and perform load-shedding on requests which can not be enqueued.