what is the use case of vertx multi verticle in single microservice?

Question

In most of the web the applications built in the vertx, I have seen that in a single microservice people create two verticles.

• One is rest verticle to handle HTTP requests.
• Another is to dao verticle to communicate to the database.

Whenever there is any api request, the HTTP verticle communicates with dao verticle via event bus.

But given that vertex is single-threaded, what is the benefit of creating two different verticles here. There would be unnecessary overhead of communication over the event bus, whereas I can create only one verticle which handles both rest and i/o.

I can understand the case of having a separate worker verticle in case of blocking calls. But in the case of non-blocking, i/o calls what is the use case of it?

Answer 1

Vert.x is not single-threaded. It uses a multi-reactor pattern:

In a standard reactor implementation there is a single event loop thread which runs around in a loop delivering all events to all handlers as they arrive.

The trouble with a single thread is it can only run on a single core at any one time, so if you want your single threaded reactor application (e.g. your Node.js application) to scale over your multi-core server you have to start up and manage many different processes.

Vert.x works differently here. Instead of a single event loop, each Vertx instance maintains several event loops. By default we choose the number based on the number of available cores on the machine, but this can be overridden.

This means a single Vertx process can scale across your server, unlike Node.js.

So by running multiple Verticles, you can have your services spread across multiple threads/CPU cores.