Building microservices with Netflix OSS, Apache Kafka and Spring Boot – Part 3: Email service

Building microservices with Netflix OSS, Apache Kafka and Spring Boot – Part 3: Email service

November 21, 2017
Dreamix, frontpage, Java

After Part 1 and Part 2 of ‘Building microservices with Netflix OSS, Apache Kafka and Spring Boot’, here is what comes next:

Email Service

Next step with building our system is the email service. It will be a microservice configured to listen for the USER_CREATED_TOPIC that comes from the user service. Here we will build an UserDto and will configure the Kafka consumer to transform the incoming payload to it. Similarly to the user microservice here we will have EmailService where the business logic will be executed. This EmailService will be using the UserDto from the payload, will transform it to Mail entity, will save it in the database and will send the mail.

In addition to Eureka Discovery; JPA; H2; Kafka; Config Client; to the new Spring Boot project(ms-mail) in SPRING INITIALIZR it is necessary to add Mail dependency as well. So the pom.xml looks like:


Sending mails is configured to use gmail. It is necessary to replace username and password with real values. This is the mail which will be used as a sender of the confirmation.


To be able to read the messages from Kafka, we need to configure ConsumerFactory and wrap KafkaListenerContainerFactory. As well as the ProducerFactory it needs some configuration properties to be set. @EnableKafka is needed to enable detection of @KafkaListener annotations on any Spring-managed beans.


Then in the method annotated with @KafkaListener we add the logic we want to be invoked when a message is received.


As mentioned above EmailService is the place where we transform the incoming payload, send the email and save it for future reference.


To test if everything is fine, build and run the project:

  • 1. Verify Service registry (Eureka) is running (http://localhost:8761)
  • 2. Config server (Spring Cloud Config) is running and ms-user and ms-email configuration is available (http://localhost:8888/ms-user/default)
  • 3. Build the project: mvn clean install
  • 4. run java-jar ms-mail-0.0.1-SNAPSHOT.jar
  • 5. Create new user with the following:

  • 6. Verify user was created: check if an email was received on

Gateway (Zuul)

As you can see from the previous example, to register an user you should know the details about its service (server ip/port) to query it. Imagine a really complex system with dozens of microservices working together. To solve this we will create a new service(Zuul) that will be the front door for all other microservices. Clients will call this microservice and it will delegate the requests to the appropriate one.

Building Zuul service with Spring Boot is as easy as for the previous microservices. With SPRING INITIALIZR create new (ms-gateway) project and Eureka Discovery; Config Client and Zuul dependencies


We configure the microservice Cloud config client


Add also @EnableEurekaClient to enable EurekaClient configuration as well for the other microservices. The Zuul functionality is enabled with @EnableZuulProxy annotation in the file.

Some routing configuration is necessary to be added, for the Zuul to know which request to which service should be redirected. We do this in git config file.


With this configuration any request to 8765:/api/user will be redirected to the ms-user microservice. And Zuul will take its address and port from Eureka.

To test if everything is fine, build and run the project:

  • 1. Create new user

  • 2. Verify an user was created

We saw how to easily build microservice system which sends emails on registration with Netflix OSS, Apache Kafka and Spring Boot. The full implementation of these 3 parts can be found in the GitHub. Feel free to give your comments and give suggestions based on your experience.

Iskren Ivanov

Java Expert at Dreamix

More Posts

Do you want more great blogs like this?

Subscribe for Dreamix Blog now!

  • cblin

    Your article is great, thank you !

    The only thing I disagree with is the ms-mail : one ms should not be responsible to listen to the bus AND to deal with the mail protocol.

    That is ms-mail should simply provide a REST API to send mail

    Then, ms-user-welcome_email should simply listen to the bus and call the REST API via discovery

    That way, for example, you can completely outsource the email delivery to a third party provider

    I know this project is only an example but this can lead to confusion if you dont talk about that (which directly relates to

    What do you think ?

  • Dmitrii Rodionov

    Great article, thanks! Could you please add one more article and setup authorization for the services?

    • cblin

      I would also like that, especially with JWT and explaining how it works with Zuul