Also vert.x never runs one verticle in more than one thread, so one has to scale a verticle for another instance to be used on antoher thread, and a request is 'sticky' in the sense that it'll only ever get handled by the same instance. That avoid concurrency problems in the scope of the verticle.. but people using an orchestrator like docker swarm or kubernetes, are not scaling microservices using vert.x, so it might be reasonable to confine one ktor instance to one thread, add have a possibility of using worker threads w/ coroutines, then, if scaling is done, each docker container running on the server will mainly be using one core But that's how I see things, that ktor is nicely eligable to eventually inherit the 'reactive' badge, but we still need async db, file access etc...