1. It's a trade-off so real-world implementations are likely to suck at both ends of the spectrum. (eg. Old Ruby servers are neither responsive nor they have la

1. It's a trade-off so real-world implementations are likely to suck at both ends of the spectrum. (eg. Old Ruby servers are neither responsive nor they have large throughput) 2. The trade-off is more about computation in general. In typical "service" scenarios you almost always want to prioritize latency over throughput, while in most "batch processing" scenarios which you want to optimize overall processing time you want to prioritize throughput. Examples: 1. Erlang server: Great preemptive scheduling thus the theoretical overall computation throughput is relatively lower. But in practice, Erlang servers are extremely fast and responsive. (Prioritize latency over throughput, great for "services") 2. Traditional C/Java blocking (non-async) server spawns threads: Theoretical computation throughput is greater but in reality, it's very easy to DDoS it. (Great for batch processing but suck at "services")