Microservices Interview Questions

Prepare for your interviews with these top Microservices interview questions if you are keen on becoming a Java professional well-versed in Microservices. These interview questions on Microservices compiled by our experts will help you ace your Microservices interview and let you work as a core Java and Microservices Developer. Get prepared to answer questions on the basics of Microservices, automation in Microservices-based architecture, how Docker works in microservice, etc. Prove yourself as a Microservices expert in your next interview!

  • 4.6 Rating
  • 20 Question(s)
  • 22 Mins of Read
  • 7536 Reader(s)


Microservices is an architectural style which structures and application as a collection of loosely coupled, independently maintainable, testable and deployable services which are organized around business capabilities. 

If you have a business focus and you want to solve a use case or a problem efficiently without the boundaries of technology, want to scale an independent service infinitely, highly available stateless services which are easy to maintainable and managed as well as independently testable then we would go ahead and implement Microservices architecture.

There are two cases.

i) If you already have a monolith application and it grows to an extent where there are problems in scaling or we are not able to reutilize the components/modules/services across different projects/platforms and there is a need to do so. As well as at the same time implementing new features is painful and more error-prone and it is difficult to scale further.

ii) For new applications where implementation has not started yet started, we can think of a business case to be efficiently implemented, which can be easily maintainable, testable and scalable in the future and might be used across other projects/products/platforms at the same time.

One should have unit and integration tests where all the functionality of a microservice can be tested. One should also have component based testing.

One should have contract tests to assert that the expectations by the client is not breaking. End-to-end test for the microservices, however, should only test the critical flows as these can be time-consuming. The tests can be from two sides, consumer-driven contract test and consumer-side contract test.

You can also leverage Command Query Responsibility Segregation to query multiple databases and get a combined view of persisted data.

In a cloud environment where docker images are dynamically deployed on any machine or IP + Port combination, it becomes difficult for dependent services to update at runtime. Service discovery is created due to that purpose only.

Service discovery is one of the services running under microservices architecture, which registers entries of all of the services running under the service mesh. All of the actions are available through the REST API. So whenever the services are up and running, the individual services registers themselves to service discovery service and service discovery services maintains heartbeat to make sure that those services are alive. That also serves the purpose of monitoring services as well. Service discovery also helps in distributing requests across services deployed in a fair manner.

Instead of clients directly connecting to load balancer, in this architectural pattern the client connects to the service registry and tries to fetch data or services from it.

Once it gets all data, it does load balancing on its own and directly reaches out to the services it needs to talk to.

This can have a benefit where there are multiple proxy layers and delays are happening due to the multilayer communication.

In server-side discovery, the proxy layer or API Gateway later tries to connect to the service registry and makes a call to appropriate service afterward. Over here client connects to that proxy layer or API Gateway layer.

Assuming that the majority of providers using microservices architecture,

A. One can scale the system by increasing the number of instances of service by bringing up more containers.

B. One can also apply to cache at microservice layer which can be easy to manage as an invalidation of the cache can be done very easily as the microservice will be the single source of truth.

C. Caching can also be introduced at the API Gateway layer where one can define caching rules like when to invalidate the cache.

D. One can also shut down some containers when the requirement is less. That is, scale down.


When you are implementing microservices architecture, there are some challenges that you need to deal with every single microservices. Moreover, when you think about the interaction with each other, it can create a lot of challenges. As well as if you pre-plan to overcome some of them and standardize them across all microservices, then it happens that it also becomes easy for developers to maintain services.

Some of the most challenging things are testing, debugging, security, version management, communication ( sync or async ), state maintenance etc. Some of the cross-cutting concerns which should be standardized are monitoring, logging, performance improvement, deployment, security etc.

It is a very subjective question, but with the best of my knowledge I can say that it should be based on the following criteria.

i) Business functionalities that change together in bounded context

ii) Service should be testable independently.

iii) Changes can be done without affecting clients as well as dependent services.

iv) It should be small enough that can be maintained by 2-5 developers.

v) Reusability of a service

In real time, it happens that a particular service is causing a downtime, but the other services are functioning as per mandate. So, under such conditions, the particular service and its dependent services get affected due to the downtime.

In order to solve this issue, there is a concept in the microservices architecture pattern, called the circuit breaker. Any service calling remote service can call a proxy layer which acts as an electric circuit breaker. If the remote service is slow or down for ‘n’ attempts then proxy layer should fail fast and keep checking the remote service for its availability again. As well as the calling services should handle the errors and provide retry logic. Once the remote service resumes then the services starts working again and the circuit becomes complete.

This way, all other functionalities work as expected. Only one or the dependent services get affected.

This is related to the automation for cross-cutting concerns. We can standardize some of the concerns like monitoring strategy, deployment strategy, review and commit strategy, branching and merging strategy, testing strategy, code structure strategies etc.

For standards, we can follow the 12-factor application guidelines. If we follow them, we can definitely achieve great productivity from day one. We can also containerize our application to utilize the latest DevOps themes like dockerization. We can use mesos, marathon or kubernetes for orchestrating docker images. Once we have dockerized source code, we can use CI/CD pipeline to deploy our newly created codebase. Within that, we can add mechanisms to test the applications and make sure we measure the required metrics in order to deploy the code. We can use strategies like blue-green deployment or canary deployment to deploy our code so that we know the impact of code which might go live on all of the servers at the same time. We can do AB testing and make sure that things are not broken when live. In order to reduce a burden on the IT team, we can use AWS / Google cloud to deploy our solutions and keep them on autoscale to make sure that we have enough resources available to serve the traffic we are receiving.

This is a very interesting question. In monolith where HTTP Request waits for a response, the processing happens in memory and it makes sure that the transaction from all such modules work at its best and ensures that everything is done according to expectation. But it becomes challenging in the case of microservices because all services are running independently, their datastores can be independent, REST Apis can be deployed on different endpoints. Each service is doing a  bit without knowing the context of other microservices.

In this case, we can use the following measures to make sure we are able to trace the errors easily.

  1. Services should log and aggregators push logs to centralized logging servers. For example, use ELK Stack to analyze.
  2. Unique value per client request(correlation-id) which should be logged in all the microservices so that errors can be traced on a central logging server.
  3. One should have good monitoring in place for each and every microservice in the ecosystem, which can record application metrics and health checks of the services, traffic pattern and service failures.

It is an important design decision. The communication between services might or might not be necessary. It can happen synchronously or asynchronously. It can happen sequentially or it can happen in parallel. So, once we have decided what should be our communication mechanism, we can decide the technology which suits the best.

Here are some of the examples which you can consider.

A. Communication can be done by using some queuing service like rabbitmq, activemq and kafka. This is called asynchronous communication.

B. Direct API calls can also be made to microservice. With this approach, interservice dependency increases. This is called synchronous communication.

C. Webhooks to push data to connected clients/services.

There are mainly two ways to achieve authentication in microservices architecture.

A. Centralized sessions

All the microservices can use a central session store and user authentication can be achieved. This approach works but has many drawbacks as well. Also, the centralized session store should be protected and services should connect securely. The application needs to manage the state of the user, so it is called stateful session.

B. Token-based authentication/authorization

In this approach, unlike the traditional way, information in the form of token is held by the clients and the token is passed along with each request. A server can check the token and verify the validity of the token like expiry, etc. Once the token is validated, the identity of the user can be obtained from the token. However, encryption is required for security reasons. JWT(JSON web token) is the new open standard for this, which is widely used. Mainly used in stateless applications. Or, you can use OAuth based authentication mechanisms as well.

Logging is a very important aspect of any application. If we have done proper logging in an application, it becomes easy to support other aspects of the application as well. Like in order to debug the issues / in order to understand what business logic might have been executed, it becomes very critical to log important details.

Ideally, you should follow the following practices for logging.

A. In a microservice architecture, each request should have a unique value (correlationid) and this value should be passed to each and every microservice so the correlationid can be logged across the services. Thus the requests can be traced.

B. Logs generated by all the services should be aggregated in a single location so that while searching becomes easier. Generally, people use ELK stack for the same. So that it becomes easy for support persons to debug the issue.

Docker helps in many ways for microservices architecture.

A. In a microservice architecture, there can be many different services written in different languages. So a developer might have to setup few services along with its dependency and platform requirements. This becomes difficult with the growing number of services in an ecosystem. However, this becomes very easy if these services run inside a Docker container.

B. Running services inside a container also give a similar setup across all the environments, i.e development, staging and production.

C. Docker also helps in scaling along with container orchestration.

D. Docker helps to upgrade the underlying language very easily. We can save many man-hours.

E. Docker helps to onboard the engineers fast.

F. Docker also helps to reduce the dependencies on IT Teams to set up and manage the different kind of environment required.

As container based deployment involves a single image per microservice, it is a bad idea to bundle the configuration along with the image.

This approach is not at all scalable because we might have multiple environments and also we might have to take care of geographically distributed deployments where we might have different configurations as well.

Also, when there are application and cron application as part of the same codebase, it might need to take additional care on production as it might have repercussions how the crons are architected.

To solve this, we can put all our configuration in a centralized config service which can be queried by the application for all its configurations at the runtime. Spring cloud is one of the example services which provides this facility.

It also helps to secure the information, as the configuration might have passwords or access to reports or database access controls. Only trusted parties should be allowed to access these details for security reasons.

In a production environment, you don’t just deal with the application code/application server. You need to deal with API Gateway, Proxy Servers, SSL terminators, Application Servers, Database Servers, Caching Services, and other dependent services.

As in modern microservice architecture where each microservice runs in a separate container, deploying and managing these containers is very challenging and might be error-prone.

Container orchestration solves this problem by managing the life cycle of a container and allows us to automate the container deployments.

It also helps in scaling the application where it can easily bring up a few containers. Whenever there is a high load on the application and once the load goes down. it can scale down as well by bringing down the containers. It is helpful to adjust cost based on requirements.

Also in some cases, it takes care of internal networking between services so that you need not make any extra effort to do so. It also helps us to replicate or deploy the docker images at runtime without worrying about the resources. If you need more resources, you can configure that in orchestration services and it will be available/deployed on production servers within minutes.

An API Gateway is a service which sits in front of the exposed APIs and acts as an entry point for a group of microservices. Gateway also can hold the minimum logic of routing calls to microservices and also an aggregation of the response.

A. A gateway can also authenticate requests by verifying the identity of a user by routing each and every request to authentication service before routing it to the microservice with authorization details in the token.

B. Gateways are also responsible to load balance the requests.

C. API Gateways are responsible to rate limit a certain type of request to save itself from blocking several kinds of attacks etc.

D. API Gateways can whitelist or blacklist the source IP Addresses or given domains which can initiate the call.

E. API Gateways can also provide plugins to cache certain type of API responses to boost the performance of the application.

One should avoid sharing database between microservices, instead APIs should be exposed to perform the change.

If there is any dependency between microservices then the service holding the data should publish messages for any change in the data for which other services can consume and update the local state.

If consistency is required then microservices should not maintain local state and instead can pull the data whenever required from the source of truth by making an API call.

In the microservices architecture, it is possible that due to service boundaries, a lot of times you need to update one or more entities on the state change of one of the entities. In that case, one needs to publish a message and new event gets created and appended to already executed events. In case of failure, one can replay all events in the same sequence and you will get the desired state as required. You can think of event sourcing as your bank account statement.

You will start your account with initial money. Then all of the credit and debit events happen and the latest state is generated by calculating all of the events one by one. In a case where events are too many, the application can create a periodic snapshot of events so that there isn’t any  need to replay all of the events again and again.


Microservices which is also called Microservice Architecture, is an architectural style that structures an application as a collection of small autonomous services, modeled around a business domain. According to the  survey conducted by Nginx in the year 2019, 36% of the large organizations are currently using microservices, while 50% of the medium companies, and 44% of companies are using Microservices in development or production. So, this is a good time to get in to the Microservices companies. The increasing popularity of Microservices is creating many job opportunities for the developer who is skilled in Microservices technology. You can get a job in the top companies like Comcast Cable, Uber, Netflix, Amazon, Ebay, PayPal, etc.

According to  Neuvoo, the average Java Microservices Developer salary in USA is $120,900 per year or $62 per hour. Entry level positions start at $74,531 per year while most experienced workers make up to $160,875 per year.

These Microservices interview questions are specially designed for you after lots of detailed research to help you in your interview. These Microservices interview questions and answers for experienced and freshers alone will help you excel the Microservices job interview and provide you an edge over your competitors. Therefore, in order to succeed in the interview, you need to go through these questions and practice these Microservices interview questions as much as possible.

Microservices interview questions and answers given here covers almost all the basic and advanced level questions. Every candidate faces jitters when it comes to face an interview. If you are planning to build a career as a Microservices programmer and are facing troubles in cracking the Microservices interview, then practice these Interview questions on Microservices.

If you want to make your career in Microservices, then you need not to worry as the set of Microservices interview questions designed by experts will guide you to get through the Microservices interviews. Stay in-tune with the following interview questions and prepare beforehand to become familiar with the interview questions that you may come across while searching for a dream job. Hope these Microservices Interview Questions will help you to freshen up your Microservices knowledge and acquire your dream career as Microservices pro.

All the best!

Read More