Build a micro service application with Vertx: a complete tutorial (part 1/5)

In this series of posts, I would explain you, how to create a complete reactive micro service application with Vert.x and Java, connect it with your data source, test and deploy on Heroku platform.

Table of contents

Click to accept cookies and enable this content


Before we would move to actual code, let talk about a microservice architecture in-depth. During this tutorial series, we would build a bike sharing application (although, not whole app, but only one service). To achieve this goal, we should follow Endpoint-Service-DAO paradigm, which is in general a microservice architecture, but a bit modified.

Please consider the graph below, which represents an architecture of the application, we would build:

Graph 1. An architecture of the example application

You can note, that the application consists of 3 major elements:

  1. Endpoint
  2. Service
  3. DAO + database

Let explore them in depth. Endpoint is responsible for exposing RESTful API, that could be consumed by clients (web and mobile). Service is an individual unit computation, decomposed by subdomain. DAO stands for a data access object, and this is a classical Java web programming pattern, where we encapsulate all data source specific logic and exclude this dependency from core service business logic.

The main purpose of using micro service pattern, is to decompose an existing monolith product into a system of interconnected independent units. Such units are represented as services, and as it was mentioned before, they are usually decomposed by business subdomain.


In the aforesaid graph, you can note that services have their own data access object and data sources. This corresponds to a “database per service” approach. Please note, that this a quite tricky definition. We can talk for a separate database per each service (for instance, we can put messages into MySql database and connections into a graph database), or just for a separate DB table per each service.

In the application, we would build, we would use later approach. We would stick to a single MySQL database and have a separate table per service. Again, this pattern is important, because it helps to ensure that the units are loosely coupled.


If you consider our graph, you can see, that services are connected with the endpoint. This is an another important component of micro services – messaging.

A micro service architecture relies on asynchronous communication between its components. There are several patterns to implement such communication, we would start from classical point-to-point communication.

In point-to-point communication, a channel ensures that only one receiver consumes any given message. If the channel has multiple receivers, only one of them can successfully consume a particular message.

Source: Enterprise Integration Patterns

Because we use Vertx, let see, how point-to-point messaging is implemented there:

  1. Sender sends a message to the specific Address (in Vertx, it can be any String name, although I encourage you to invent some type of naming convention in your projects).
  2. Consumer receives a message and process it.
  3. Optionally, Consumer can reply back. This is a two-way communication, or request-response pattern.


In this first part of a series of tutorial, we observed an architecture of the example app, we would build during this course. We also focused on some specific components: endpoints, services and DAO, that are integral parts of micro service architecture. Finally, we talked about data management in micro service apps and communication.

You can find a full source code for this tutorial on my github. Feel free to clone it:

git clone