Sunday, September 8, 2019

Spring Boot Tutorial

Prerequisite: Basic knowledge of Spring boot application

I am working on a series of implementing frameworks with Spring boot application but not getting enough time to blog it and post it here or on my LinkedIn profile.

So, I have started uploading my work on my GitHub repository from where it can be downloaded easily. I tried my best to add short notes for each annotation/configuration/properties in README and even I have uploaded a few screenshots to understand in a more better way.

Try it out and Please do let me know in case of any confusion.
  1. Spring Boot Actuator
  2. Spring Boot Ehcache
  3. Spring Boot Swagger
  4. Spring Boot JPA

Will keep uploading with others framework as well.

Feedback is also most welcome.

Thank you.
Happy Learning!

Thursday, August 29, 2019

MicroServices: Spring cloud ribbon with Discovery Server

In this article, I am going to share my knowledge on Spring Cloud Ribbon and how can we use Ribbon with RestTemplate as well as with Feign Client. We will also see how Enabling discovery Sever will improve the scalability of Microservice.

Before jumping into Spring Cloud, I am assuming you must be having knowledge of Eureka Server, Feign Client, and Client-Side load balancer. If not then read my below blog before jumping to Spring Cloud ribbon. Also, I am going to use my existing code to implement Ribbon.

In my previous blog, I have already talked about the Eureka Server and how other applications are taking advantages of Eureka Server to fetch the host/port of client application.

We have seen that three microservices application are up and running i.e.
  • Discovery Server
  • Product Service
  • Price Service
Where Product and Price service will register themselves to Discovery Server and Product-service will always communicate to Discovery Server to get the exact location of Price-service and then only it will talk to the price-service application.

Imagine there is a high load on the price-service application and to handle it, we have started two more instances of price-service.

  • How will you make sure your product-service should talk to all three instances of price-service and divides the load equally to each server?
  • How will you manage the heartbeat of the application so that product-service should not hit INACTIVE instance of price-service which just got shut down because of some internal reason?
  • How will you get to know how many instances are up and running of price-service?
For all the question, there is only answer which is Netflix Cloud Ribbon. It's a Spring cloud library which primarily provides client-side load balancing algorithms.

let's implement it and see how it can solve our problem.

Add below dependency to product-server pom.xml file as it is the one which is going to consume price-service API.


Case 1: Ribbon + Eureka Server + RestTemplate

As our application is already acting as Eureka Client and using RestTemplate to fetch price record. Let's just add @LoadBalanced annotation to RestTemplate to enables Ribbon functionality.

It will allow the product-service application to use price-service as the address of price-service application and will discover the host/port of all instances of price-service from discovery-server.


@EnableCircuitBreaker <-> Used to enable Netflix Hystrix
@EnableHystrixDashboard <-> Used to check circuit state on Dashboard.
@EnableFeignClients <-> To enable feign client (Needed for case 2 scenario)

Start discovery-server, product-service and start two instances of price-service. You can do it easily by just overriding port number under Eclipse Run As Configuration.

Let's confirm it, whether all the instances are up and running or not by hitting discovery-server URL (http://localhost:8761/)

Now hit product-service URL multiple times from the browser and then go and check both the price-service logs. you will observe that few requests are coming to one instance and others on second one.

Great! Netflix Cloud Ribbon is successfully implemented and working absolutely fine.

If you start another price-service instance and hit the product-service URL again then you will find the request logs in the third instance too without doing any modification/configuration to any files.

Case 2: Ribbon + Eureka Server + Feign Client

If you are not aware of the feign client then you can read my blog here.

I'll just talk about Ribbon Integration with existing FeignClient application assuming you are already aware of Feign Client and implemented it.

In product-service application, I have already exposed another Endpoint (http://localhost:7001/products/feign/1) which consume price-service API using Feign Client.

To enable Netflix Ribbon, Add @RibbonClient annotation to the feighClient interface and pass your consuming service name (price-service).

Now restart your application and hit new endpoint. you will observe that the requests are distributed to all the instances of price-service.

Case 3: Ribbon + (RestTemaple/FeignClient) + NO Eureka Server

Can we use Netflix ribbon without integrating Eureka Server, The answer is YES but it would not be a good design. So, I would not recommend it.

When your application is not integrated with Eureka Server, in that case you have to list down all the address manually to properties file.

Remove @RibbonClients annotation.
Add below entry to your file under 

#Enable this property if you are not using Eureka Server

Imagine there are 1000 instances of price-services are up and running so we have to add all the instances manually. It could be a nightmare if we have to do it. :)

That's all for Netflix Ribbon now and do let me know if you have any confusion/query or you think I am not right somewhere. Please feel free to comment. Thank you!

As usual, you can download the spring-boot-microservices from GITHUB.

Sunday, August 18, 2019

Declarative REST Client: Feign

We already know that how microservices communicate with each other using RestTemplate. In this blog, we will see that how this can happen using Feign Client as well. 

What is a Feign Client?

Feign is an abstraction over REST based call. It makes writing web service clients easier. It Is as easy as creating interface and then annotate it. It has pluggable annotation support including Feign annotations and JAX-RS annotations. It also supports pluggable encoders and decoders and has supports for Spring MVC annotation.

Using Feign, microservices can easily communicate with each other and developers don't have to bother about REST internal details and can only concentrate on business logic.

I am going to use my previous applications to demonstrate the working of Feign Client. So before starting feign-client application. Make sure all the below three applications are already up and running. 

Feign Client Implementation

  • Create a spring boot application and add Feign starter dependency to our pom.xml file.

  • Add @EnableFeignClients annotation. With this annotation, we enable component scanning for interfaces that declare they are Feign clients. 

  • Declare a Feign client using the @FeignClient annotation.

  • Either name or url must be passed under @FeignClient annotation. If name attribute present then it will fetch the service location from service registry and then hit product-service and in case of url, it will directly hit the application to get the data from product-service. In case of both present then it will always first check for the name attribute. 
  • Use Spring Web annotations to declare the APIs that we want to reach out to.
Note: If your application is not registered with service registry then directly use url attribute to get the data but I would recommend to use name attribute and to use name attribute, make sure your application is connecting to Eureka server to get the service location. 

Read my blog to understand on how to add support for Eureka Client to your application.

Now start your application and you should be able to fetch product-service from feign-client. 

You can download the source code from here. 

Custom Configuration

Feign Client also support for Custom configuration changes like telling Feign to use OkHttpClient instead of the default one in order to support HTTP/2. 

Let’s go deep down to check how can we customize Feign Client.

There are two ways to configure it i.e. using properties file or override them using a @Configuration class, which we then need to add to the FeignClient annotation. 

Properties file:

Using @Configuration


By default, a logger gets created for each Feign Client and to enable it, we have to declare it in the file using the package name of the client interface.

There are four logging levels to choose from:

NONE – no logging, which is the default
BASIC – log only the request method, URL, and response status
HEADERS – log the basic information together with request and response headers
FULL – log the body, headers, and metadata for both request and response

Handling Errors with Feign

By default, Feign’s default error handler, ErrorDecoder.default, always throws a FeignException.

To customize the Exception thrown, we can override it by writing our own Custom Error class and implements ErrorDecoder and declare this bean under @Configuration as we did earlier.

Spring-boot microservices can be downloaded from GITHUB

Happy Coding...!!!

Microservices: Service Registry and Discovery

In my previous blog, I have already talked about Netflix Hystrix Circuit Breaker Microservices and explained it by creating two applications i.e. Product Service and Price Service.
In this post, I’ll use both applications to explain what is the Service Registry and Discovery Server.

What is Service Registry and Discovery and why do we need it in the first place?

In our monolithic application, mostly service invoke one another through language methods or procedure calls and even in traditional distributed system deployment, services run at fixed, well-known locations (hosts and ports) and so can easily call one another using HTTP/REST. Over here the network locations of service instances are relatively static.

With the microservice architecture system, this is a much more difficult problem as service instances have dynamically assigned network locations. Service instances change dynamically because of auto-scaling, failure or upgrade. So, you can see that it’s not possible to hard code the locations (hosts and ports) of service instances in our application.

Apart from that, most of the time we have to deploy the same instance on multiple hosts (E.g. During Big billions day sale where 1000’s of instances is running to support high demand) which will be again a tedious task for the load balancer to register and deregister itself for all these services.

What is Service Registry and Discovery?

Service Registry is the server instance where all the service provider register itself when it starts up and deregisters itself when it leaves the system. The service instance’s registration is typically refreshed periodically using a heartbeat mechanism.

Whenever a client has to communicate with other service instances, it has to first query to Service registry to get the network location and then uses a load-balancing algorithm to select one of the available service instances and invoke a request. 

The above instance discovery pattern is called a Client-Side discovery pattern and this can be easily implemented using Netflix Eureka as a Service Registry. It provides a REST API for managing service‑instance registration and for querying available instances.

Netflix also provides Netflix Ribbon which is an IPC client that works with Eureka to load balance requests across the available service instances.


As we already have two microservices product-service and price-service and we know product-service is internally invoking price-service to get the price detail of the products. We will do minor changes with these two applications to support service registry.

Discovery Server Implementation

  • Create a spring boot application and Eureka Server starter dependency to your pom.xml file 

  • Add @EnableEurekaServer annotation to Enable Eureka Server.
  • By default, Each Eureka Server is also a Eureka Client which needs at least one service URL to locate service registry. We have to disable this feature as we are creating single node Eureka Server. 
  • Add below properties to file.

  • Now start the discovery-server application and access http://localhost:8761 which will display the UI similar to below screenshot. 

  • As of now, no application is registered with the Eureka Server. 

2. Registering product-service and price-service to Eureka Clients

  • Let’s make out product-service and price-service as Eureka Client which should register to Eureka Server itself on starts up.
  • Add Eureka Client dependency on both pom.xml files.

  • Configure eureka.client.service-url.defaultZone property in to automatically register with the Eureka Server. 

  • Now start product-service and price service application and hit http://localhost:8761. We will see product-service and price-service is registered with SERVICE ID as PRODUCT-SERVICE and PRICE-SERVICE respectively. We can also notice the status as UP(1) which means the services are up and running and only one instance of product and price-service are running. 

3. Update hard code URL with application name in product-service and restart the application. 

4. Now open browser and hit product URL and you will get the below response.

Congratulation!!! Our application is perfectly working with Discovery Service. 

Spring-boot microservices can be downloaded from GITHUB

Happy Coding...!!!

Sunday, June 16, 2019

Netflix Hystrix Circuit Breaker

Netflix Hystrix Circuit Breaker

In one of my previous blogs, I have already discussed the Circuit breaker pattern and its usage, Today, we will see how can we implement it in our application using Spring Cloud Netflix Hystrix.

In this document, I’ll walk you through the process of applying circuit breakers to potentially-failing method calls using the Netflix Hystrix fault tolerance library.

Hystrix is watching methods for failing calls to related services. If there is such a failure, it will open the circuit and forward the call to a fallback method.

To understand it in a better way, I’ll take the same problem statement that I have already discussed in my previous blog i.e. E-commerce Portal. 

I am assuming you must be aware of Spring boot framework as this implementation is completely based on it.

As per problem statement, we need two applications i.e. Product Service & Price Service but in this tutorial, I’ll talk about just Product Service as Price Service is simple web application exposing a single API and you can clone it from GitHub.

I’ll talk about Product Service in which we will integrate Circuit breaker pattern and Cache Service implementation and internally, it will invoke Price Service to get the Price Detail.

Optional: You can download the below project from GitHub or you can try it by creating a new one. I would recommend you to try it from scratch.

Product Service:

Create Spring boot application and add below dependency to your pom.xml file.

<!-- Optional. Application health monitor check -->





<!-- Compulsory for circuit breaker implementation -->





<!-- Optional. Dashboard in case you want to see the circuit state UI -->





To enable Circuit Breaker in spring boot application, add @EnableCircuitBreaker annotation on product-service entry-point class. 

Now use @HystrixCommand annotation on themethod we want to apply timeout and fallback method.

I have annotated @HystrixCommand(fallbackMethod = “getProductDetailFromCache”) on getProduct(String Id) so that if it doesn’t receive the response within the certain time limit or request get failed while calling price service API then fallback() should get called over here and fetch the price value from Cache Service. 

Make sure, the fallback method should be defined in the same class and should have the same signature.

We can customize the @HystrixCommand default behavior by configuring properties using @HystrixProperty annotations. Will check in depth in another blog. 

Add RestController class and other required class as per source code present in GitHub.

Add server.port to the file.

Start both applications and try to fetch the product Detail. In our case, our product-service app URL is:


Now try to fetch product which does not exist

You will observe that over here circuit breaker is still in the closed state even after the exception. 

Why? The reason is that we have added  ignoreExceptions = { ProductNotFoundException.class } to @HystrixCommand so that it should not trip circuit if the product is not present.

Now, Stop the price-service application and hit the product URL again:

Check the log:

Congratulations! Our application is working as expected.

Monitoring Circuit Breakers using Hystrix Dashboard

Hystrix comes with a decent dashboard where we can monitor the status of Hystrix commands

To enable it, Add Hystrix dashboard dependency to the pom.xml file 

<!-- Optional. Application health monitor check -->
<!-- Optional. Dashboard in case you want to see the circuit state UI -->

Add @EnableHystrixDashboard annotation on the entry point class

Add to file.

Start the product-service application and then go to http://localhost:port/hystrix to view the dashboard. 

In Hystrix Dashboard home page enter http://localhost:7001/actuator/ as stream URL and give Product Service as Title and click on Monitor Stream button. 

Now, we can see that the Circuit status along with how many calls succeed and how many failures occurred, etc. 

Spring-boot microservices can be downloaded from GITHUB

Happy Coding...!!!

Saturday, June 15, 2019

Circuit Breaker and Microservices Architecture

Circuit Breaker and Microservices Architecture 

In this article, I’ll talk about the Circuit Breaker pattern which is widely used in Microservices but before jumping to Circuit breaker design pattern or microservices. Let’s first understand the requirement so that you should know where we can use it in our application and Of Couse, How 😊

Let’s understand it with the real scenario as It’s already June month and we know there are so many online summer sales is going to start where they will offer you a various type of deals on their products.

And as we know most of the online portal has upgraded their application arch from Monolithic design to Microservices like Amazon, Flipkart, Snapdeal and so on and with that their each service will be running as an independent micro-services in the cloud like Authentication Service using which a user can be logged in to the application, Product Detail Service, Billing Service, Price Service, Card Services, etc.

Now just imagine the scenario where millions of users are doing online shopping on some online portal and because of load or some other technical issue, their price services goes down for some time. So, what will happen over here if a customer can’t order anything?

From a business point of view: it will give the bad impact of the sales as well as it will also decrease sales. Right?

From a technical point of view: All the request going to Price Service will fail eventually and failure in one part of the system might lead to cascading failures and all the future request will be blocked until the timeout expires and there are high chances that these blocked requests might hold critical system resources such as memory, threads, database connections and so on. Consequently, these resources could become exhausted, causing the failure of other possibly unrelated parts of the system that need to use the same resources.

How to solve it?
One simple approach is to return the cached price if the price service goes down and the original price once the price system available.

How can we achieve the above solution?
We can achieve this approach easily by implementing a circuit breaker pattern that allows a fallback when one of the applications goes down.

The concept of Circuit breaker is very similar to automatically operated electrical panel switches of our home which goes down after the fault detected (either an electrical storm or power surge) and can be reset (either manually or automatically) to resume normal operation after the fault is involved.

The Circuit breaker pattern helps to prevent such a catastrophic cascading failure across multiple systems. It allows us to build a fault-tolerant and resilient system that can survive gracefully when key services are either unavailable or have high latency.

The concept of circuit breaker is straightforward and has three distinct states:
  1. Closed: When everything is normal, the circuit breaker remains in the closed state and all calls pass through to the services according to its lifecycle until it encounters a failure and when the number of failures exceeds a predetermined threshold the breaker trips and the circuit breaker will change the state to the Open state.
  2. Open: When the breaker in its open state then the request will not go the service but will acts as a backup plan like throwing error directly or in our case, get the response from the Cache service.
  3. Half-Open: A limited number of requests from the application are allowed to pass through and invoke the operation. If these requests are successful, it's assumed that the fault that was previously causing the failure has been fixed and the circuit breaker switches to the Closed state (the failure counter is reset). If any request fails, the circuit breaker assumes that the fault is still present so it reverts back to the Open state and restarts the timeout timer to give the system a further period of time to recover from the failure.

  1. Helps to add logic for a fault tolerant system like try to get the data from some other source or from the cache.
  2. Handle downtime and slowness of services gracefully
  3. It will switch back to the main service once the service is again available automatically.
In my next blog, I'll talk about how can we implement circuit pattern using Spring Boot.

Wednesday, May 22, 2019

Installing Apache Kafka and Zookeeper on Windows

In this article, I’ll talk about how to Install, configure and start Apache Zookeeper and Apache Kafka Server on Windows OS.


  • JRE running on your machine and path must set to Environment Variable
  • Any Zip tool like 7-zip, WinZip or WinRAR.
  • Download and Extract Apache Zookeeper using 7-zip.
  • Download and Extract Apache Kafka using 7-zip

ZooKeeper Installation Instructions:

  • Go to the conf directory of your Zookeeper. For me its under D:\Softwares\apache-zookeeper-3.5.5
  • Copy and rename zoo_sample.cfg to zoo.cfg file.
  • Open and Edit dataDIr=/tmp/zookeeper to dataDir=D:\Softwares\apache-zookeeper-3.5.5

  • Add entries in System Environment Variables
  • ZOOKEEPER_HOME=D:\Softwares\apache-zookeeper-3.5.5
  • Append D:\Softwares\apache-zookeeper-3.5.5\bin to PATH system variable.
  • Open command prompt and type zkserver to start the Zookeeper application.
  • You can easily edit the default port ( 2181) in zoo.cfg file.

Congratulations, ZooKeeper is up and running on port 2181.

Installing Apache Kafka Instructions
  • Please make sure that the Zookeeper instance is up and running before starting any kafka server.
  • Go to the Kafka Installation directory (D:\Softwares\apache-tomcat-8.5.37) and run below command.
  • .\bin\windows\kafka-server-start.bat .\config\

Congratulations, Apache kafka is up and running on port 9092

Create Topic
To create a topic, we need to run the kafka-topics script

  • Go to Apache kafka installation directory and navigate to bin\windows folder (D:\Softwares\kafka_2.11-2.2.0\bin\windows).
  • Execute below command to create topic where <TOPIC_NAME> should be name of your topic
  • kafka-topics.bat --create --zookeeper localhost:2181 --replication-factor 1 --partitions 1 --topic <TOPIC_NAME>

Create Producer

Now the topic has been created, Lets start a producer so that we can published some message against sales topic.

·       Go to Apache kafka installation directory and navigate to bin\windows folder (D:\Softwares\kafka_2.11-2.2.0\bin\windows).
·       Execute: kafka-console-producer.bat --broker-list localhost:9092 --topic sales

Create Consumer
Let’s create a consumer which should subscribe to sales topic to get all the messages.

·       Go to Apache kafka installation directory and navigate to bin\windows folder (D:\Softwares\kafka_2.11-2.2.0\bin\windows).
·       Execute: kafka-console-consumer.bat --bootstrap-server localhost:2181 --topic sales

By running all four components (zookeeper, kafka, producer, and consumer) in different terminals, we will be able to enter messages from the producer’s terminal and can see them appearing in the consumer’s terminal and If everything works fine, you will be able to push and see messages.

Bonus Installation:

There are multiple UI applications which can be use for monitoring apache kafka. It will display the information like total brokers, topics, partition and even lets you view messages as well.
One of the tools is Kafdrop which we will install right now and see all those details on UI.

  • Java 8
  • Kafka (0.8.1 or 0.8.2 is known to work)
  • Zookeeper (3.4.5 or later)
  • Download and Extract Kafdrop using 7-zip.
·       Go to the Kafdrop directory and run mvn clean package which will generate an executable JAR in target directory.
·       Go to target directory and run
o   java -jar ./target/kafdrop-<version>.jar --zookeeper.connect=localhost:2181
·       Open a browser and navigate to http://localhost:9000 to view the Kafdrop UI.  

How TOPT Works: Generating OTPs Without Internet Connection

Introduction Have you ever wondered how authentication apps like RSA Authenticator generate One-Time Passwords (OTPs) without requiring an i...