Top Microservices Interview Questions and Answers 2021


Here is the exhaustive list of Microservices interview questions commonly asked for developer and architect roles. According to the Nginx App Dev Survey, 40% of companies have switched to Microservices architecture. Developers play a critical role in microservice development and decision making.

The list also covers Java Spring Boot Microservice interview questions and answers.

Microservices Interview Questions and Answer

1) What is Monolithic Architecture?

Monolithic architecture, also known as Multi-layered architecture, is a Single unified model for the software design program. In a monolithic application, all the functionalities exist in a single code base.

Monolithic Architecture

2) Explain Microservices Architecture?

Microservices (or microservices architecture) is a cloud-native architectural approach in which a single application is composed of many loosely coupled and independently deployable smaller components or services.

Microservices architecture allows individual services to quickly scale or update without disrupting other services in the Application.

Microservices Architecture

3) What are the Advantages of Microservices Architecture?

  • Scalability
  • Parallel and Faster development
  • Fault tolerance and Increased Resiliency
  • Programming Language and Technology Agnostic
  • High-Quality Development and Higher Security
  • Greater Business Agility and Support for DevOps
  • Faster Time to Market

4) What are the main features of Microservices Architecture?

  • Autonomy and Single Responsibility Principle
  • Componentization via Services
  • Organized around Business Capabilities
  • Decentralized Governance
  • Decentralized Data Management
  • Infrastructure Automation
  • Design for failure
  • Smart endpoints and dumb pipes

5) What are the key elements or components of Microservices?

  • Service Discovery and Communications
  • Containers, Clustering, and Orchestration
  • API Gateway
  • Service Mesh
  • Messaging Formats
  • Centralized Monitoring, Distributed Tracing, and Aggregated Logging

6) Difference between Monolithic vs. SOA vs. Microservices


  • Simpler development and deployment
  • Fewer cross-cutting concerns
  • Better performance
  • Codebase gets cumbersome over time
  • Challenging to adopt new technologies
  • Limited agility


  • Reusability of services
  • Better maintainability
  • Higher reliability
  • Parallel development
  • Complex management
  • High investment costs


  • Easy to develop, test, and deploy
  • Increased agility
  • Ability to scale horizontally
  • Complexity
  • Security implications. 
  • Pre-planning is essential. 

7) What are the different design patterns used in Microservices Development?

  • Aggregator Pattern – The aggregator design pattern is a service that receives a request, subsequently makes requests of multiple services, combines the results, and responds to the initiating request.
  • API Gateway Design Pattern – The API gateway pattern is sometimes known as “Backend for frontends” (BFF) because you need to develop thinking about the Client Application’s needs. The API Gateway sits between the frontend application and the collection of backend Microservices.
  • Chained or Chain of Responsibility Pattern -In object-oriented design, the chain-of-responsibility pattern is a behavioural design pattern consisting of a source of command objects and a series of processing objects. This pattern promotes the idea of loose coupling.
  • Asynchronous Messaging Design Pattern – Asynchronous messaging is a communication method where the sending party can send a message and continue with unrelated tasks without waiting for an immediate response from the other party. This eliminates the need for both communicating parties to be up and running at the time of communication.
  • Database or Shared Data Pattern – Databases must sometimes be replicated and sharded in order to scale. For some services, a relational database is the best choice. Other services might need a NoSQL database such as MongoDB, which is good at storing complex, unstructured data, or Neo4J, designed to store and query graph data efficiently.
  •  Event Sourcing Design Pattern – Event sourcing is a powerful architectural pattern that records all changes made to an application’s state in the sequence in which the changes are .applied initially.
  • Branch Pattern – Branch microservice pattern is a mix of Aggregator and Chain design patterns and allows simultaneous request/response processing from two or more microservices. Branch patterns can also be used to invoke different chains of microservices, or a single chain, based on your business needs.
  • Command Query Responsibility Segregator (CQRS) Design Pattern – Command Query Responsibility Segregation (CQRS) is an architectural pattern that separates reading and writing into two different models. This means that every method should either be a command that performs an action or a query that returns data. A Command cannot return data, and a Query cannot change the data.
  • Circuit Breaker Pattern – The Circuit Breaker design pattern is the solution for any catastrophic cascading failure across multiple services. It prevents an application from performing an operation that is going to fail. The circuit breakers build a fault tolerance and resilient system that can survive gracefully when services are unavailable or have higher latency issues.
  • Decomposition Design Pattern – Microservices are developed with an idea on the developer’s mind to create small services, each having its functionality. Nevertheless, breaking an application into small autonomous units has to be done logically. So, to decompose a small or big application into small services, you can use the Decomposition patterns.
  • Strangler Pattern – Strangler Pattern is a way of migrating a legacy system incrementally by replacing existing functionalities with new applications and services in a phased approach. After replacing the entire functionality, the new application system eventually replaces all the old legacy system’s features.

8) How do Microservices communicate with each other?

Client and services can communicate through many different types of communication, each one targeting a different scenario and goals. Initially, those types of communications can be classified into two axes.

The first axis defines if the protocol is synchronous or asynchronous:

  • Synchronous protocol. HTTP is a synchronous protocol. The client sends a request and waits for a response from the service. That is independent of the client code execution that could be synchronous (thread is blocked) or asynchronous (thread is not blocked, and the response will reach a callback eventually). The important point here is that the protocol (HTTP/HTTPS) is synchronous, and the client code can only continue its task when it receives the HTTP server response.
  • Asynchronous protocol. Other protocols like AMQP (a protocol supported by many operating systems and cloud environments) use asynchronous messages. The client code or message sender usually does not wait for a response. It sends the message as when sending a message to a RabbitMQ queue or any other message broker.

The second axis defines if the communication has a single receiver or multiple receivers:

  • Single receiver. Each request must be processed by exactly one receiver or service. An example of this communication is the Command pattern.
  • Multiple receivers. Each request can be processed by zero to multiple receivers. This type of communication must be asynchronous. An example is the publish/subscribe mechanism used in patterns like Event-driven architecture. This is based on an event-bus interface or message broker when propagating data updates between multiple microservices through events; it is usually implemented through a service bus or similar artifact like Azure Service Bus by using topics and subscriptions.

9) What are some of the famous companies that have adopted Microservices-based architecture?

  • Amazon
  • Netflix
  • Uber
  • Etsy
  • Airbnb

10) How do you make Microservices more secure?

  • Make your microservices architecture secure by design
  • Scan for dependencies
  • Use HTTPS everywhere
  • Use access and identity tokens
  • Encrypt and protect secrets
  • Scan container images for vulnerabilities and bugs
  • Implement authentication and authorization features
  • Employ TLS everywhere
  • Rotate your encryption keys to mitigate vulnerabilities
  • Use network policies to limit traffic between pods

11) Can a monolithic system / WebAPI’s talk to Microservices?

Yes. Monolithic apps can talk with microservices if their endpoints are reachable within the infrastructure or securely using a public endpoint. Microservices and their data can either be consumed synchronously via their endpoints or asynchronously through messaging like the Event Bus.

12) How do I break Monolith into Microservices?

  1. Warm Up with a Simple and Fairly Decoupled Capability.
  2. Minimize Dependency Back to the Monolith.
  3. Split Sticky Capabilities Early.
  4. Decouple Vertically and Release the Data Early.
  5. Decouple What is Important to the Business and Changes Frequently.
  6. Apply Bounded context and split into Domain-Driven Design
  7. Decouple Capability and not Code.
  8. Go Macro First, then Micro.
  9. Migrate in Atomic Evolutionary Steps

13) Can Microservices be deployed without using Containers?

A microservices architecture does not dictate the use of containers. Netflix, for example, runs its entire microservices-based offering on Amazon Web Services, using AWS instances. But most organizations that move to microservices architectures will find containers a more congenial way to implement their applications.

14) What do you mean by Bounded Context?

A bounded context is the boundary of a model that represents those concepts, their relationships, and their rules. Since a bounded context is a boundary for a model, it could include concepts from multiple subdomains.

bounded context

15) How do you determine Bounded Context?

To identify bounded contexts, you can use a DDD pattern called the Context Mapping pattern. With Context Mapping, you identify the various contexts in the Application and their boundaries. It’s common to have a different context and boundary for each small subsystem, for instance

16) What is ubiquitous Language in Domain-Driven Design (DDD)?

Ubiquitous Language is a model that acts as a universal language to help communication between software developers and domain experts. Ubiquitous Language is the term Eric Evans uses in Domain Driven Design for the practice of building up a common, rigorous language between developers and users. This Language should be based on the Domain Model used in the software – hence the need for it to be rigorous since the software doesn’t cope well with ambiguity.

17) What is an anti-corruption layer?

The anti-corruption layer contains all of the logic necessary to translate between the two systems. The layer can be implemented as a component within the Application or as an independent service

18) What is DDD in Microservices?

DDD is a collection of patterns and principles that aid in your efforts to build applications that reflect an understanding of and meet the requirements of your business.

Domain-driven design (DDD) advocates modeling based on business reality as relevant to your use cases. In the context of building applications, DDD talks about problems as domains. It describes independent problem areas as Bounded Contexts (each Bounded Context correlates to a microservice) and emphasizes a common language to talk about these problems. It also suggests many technical concepts and patterns, like domain entities with rich models (no anemic-domain model), value objects, aggregates, and aggregate root (or root entity) rules to support the internal implementation. This section introduces the design and implementation of those internal patterns.

19) What are the major challenges involved in Microservices development?

  • The complexity of the Architecture
  • Preparing a Failure Strategy
  • More Complicated Security System
  • Testing Is Not Always Easy
  • Risk of Slow Performance
  • Issues With Consistency
  • Challenges With Standardization
  • Higher Maintenance Costs
  • Broad Range of Skills Needed
  • Aggregated Logging, Distributed tracing, and Monitoring of the services

20) What is Docker, and how does it work?

Docker is an open platform for developing, shipping, and running applications. Docker enables you to separate your applications from your infrastructure so you can deliver software quickly. With Docker, you can manage your infrastructure in the same ways you manage your applications.

21) What is Kubernetes, and why is it used?

Kubernetes is a portable, extensible, open-source platform for managing containerized workloads and services that facilitate declarative configuration and automation. It has a large, rapidly growing ecosystem. Kubernetes services, support, and tools are widely available.


22) What’s the difference between Kubernetes and Docker?

While it’s common to compare Kubernetes with Docker, a more apt comparison is Kubernetes vs. Docker Swarm. Docker Swarm is Docker’s orchestration technology that focuses on clustering for Docker containers—tightly integrated into the Docker ecosystem and using its API.

A fundamental difference between Kubernetes and Docker is that Kubernetes is meant to run across a cluster while Docker runs on a single node. Kubernetes is more extensive than Docker Swarm and is meant to coordinate clusters of nodes at scale in production in an efficient manner. Kubernetes pods—scheduling units that can contain one or more containers in the Kubernetes ecosystem—are distributed among nodes to provide high availability.

23) Why is there a need for Domain-Driven Design (DDD)?

Domain Driven Design

24) What is PACT, and how does it help in Microservices architecture?

A pact is a code-first tool for testing HTTP and message integrations using contract testsPACT allows testing interactions between service providers and consumers in isolation against the contract made so that the reliability of Microservices integration increases.

25) What is the difference between REST API and Microservices?

The terms RESTful API and Microservices go hand-in-hand when building a microservices-based application. Nevertheless, they refer to very different things. The easiest way to understand the difference between RESTful APIs and microservices is like this:

  • Microservices: The individual services and functions – or building blocks – that form a larger microservices-based application.
  • RESTful APIs: The rules, routines, commands, and protocols – or the glue – that integrate the individual microservices, so they function as a single application.

26) What are the different strategies of Microservices Deployment?

  • Multiple Service Instance per Host: Run single or multiple service instances of the Application on single/multiple physical/virtual hosts.
  • Service Instance per Host: Run a service instance per host.
  • Service Instance per Container: Run each service instance in its respective container.
  • Serverless Deployment: Package the service as a ZIP file and upload it to the Lambda function. The Lambda function is a stateless service that automatically runs enough micro-services to handle all requests.

27) Difference between Cohesion and Coupling?

Coupling: it is the relationship between module A and another module B. Any module can be highly coupled (highly dependent), loosely coupled, and uncoupled with other modules. The best coupling is loose coupling achieved through interfaces.

Cohesion: it is the relationship between 2 or more parts within a module. If a module has high cohesion, it means the module can perform a certain task with utmost efficiency on its own, without communication with other modules. High cohesion enhances the functional strength of a module.

28) What is Distributed Transaction in Microservices?

A transaction is distributed to multiple services that are called sequentially or parallelly to complete the entire transaction. With a microservices architecture, the most common pattern is database per microservice, so transactions also need to span across different databases.

29) What are the tools that can be considered for managing a microservice architecture?

  1. MongoDB: It is a document-based open-source distributed database. Here data is stored in JSON format with a different structure for different documents. It also supports a lot of programming languages like C, C++, C#, PERL, PHP, Python, Java, Ruby, Scala, etc.
  2. Elasticsearch: It is a full-text search engine.
  3. KAFKA: It is an event queue system. All transactions are processed via the event queue, thus avoiding the web-like random interactions between different services. Kafka renders a microservice architecture robust and clean.
  4. JENKINS: It is an automation tool that enables Continuous Integration and Continuous Development. It supports many plugins and easily integrates with almost every tool.
  5. DOCKER: The application development environment and application deployment environment are bound to vary in many aspects. This gives rise to deployment issues. Docker provides a static background for the Application to run, thus avoiding deployment issues.
  6. KUBERNETES: With thousands of services running in an application, Kubernetes, as an engine, orchestrates the entire process.
  7. JAEGER: It is an open-source end-to-end distributed tracing tool. Jaeger monitors distributed transactions, helps in performance optimization, and finds the dependencies between services. It also gives the root cause analysis.
  8. FLUENT: In a multiservice architecture, where all the different systems are managed via different programming languages, different databases, and run in different operating systems, logging in and keeping track of it is a significant issue. Fluentd provides a single logging layer and simplifies this issue. Logs can be also be collected and aggregated onto a data source.
  9. PROMETHEUS: It is a monitoring tool, which helps to check if all services are working fine when the application is deployed. It is a time-series data store. It collects metrics from an application and displays them in a graphical format.
  10. grafana: Grafana provides analytics and monitoring into different visualization formats like graphs, charts, tables, etc.
  11. NGINX: It acts as a reverse proxy. It acts as a single point entry through which all the API calls are made.

30) What is messaging queue in microservices?

A message queue is a form of asynchronous service-to-service communication used in serverless and microservices architectures. Messages are stored on the queue until they are processed and deleted. Each message is processed only once by a single consumer. Message queues can be used to decouple heavyweight processing, buffer, or batch work and to smooth spiky workloads.

31) What is the 12-factor app methodology?

  1. Codebase – One codebase tracked in revision control, many deploys
  2. Dependencies – Explicitly declare and isolate dependencies
  3. Config – Store config in the environment
  4. Backing services – Treat backing services as attached resources
  5. Build, release, run – Strictly separate build and run stages
  6. Processes – Execute the app as one or more stateless processes
  7. Port binding – Export services via port binding
  8. Concurrency – Scale out via the process model
  9. Disposability – Maximize robustness with fast startup and graceful shutdown
  10. Dev/prod parity – Keep development, staging, and production as similar as possible
  11. Logs – Treat logs as event streams
  12. Admin processes – Run admin/management tasks as one-off processes

32) What are the popular monitoring tools for Microservices?

  • Logstash
  • Reimann
  • Prometheus
  • Elastic Stack
  • Kibana
  • Glowroot
  • AWS Cloudwatch
  • Datadog
  • Azure Monitor
  • LightStep
  • Graylog

32) What is a service mesh in microservices?

A service mesh is a platform layer on top of the infrastructure layer that enables managed, observable, and secure communication between individual services. This platform layer enables companies or individuals to create robust enterprise applications made up of many microservices on a chosen infrastructure.

33) Which is the best service mesh widely used in Microservices?

  1. Consul Connect – the Consul is a full-feature service management framework, and the addition of Connect in v1.2 gives it service discovery capabilities which make it a full-Service Mesh. Consul is part of HashiCorp’s suite of infrastructure management products; it started as a way to manage services running on Nomad and has grown to support multiple other data center and container management platforms, including Kubernetes.
  2. Istio – Istio is a Kubernetes-native solution that was initially released by Lyft, and a large number of major technology companies have chosen to back it as their service mesh of choice. Google, IBM, and Microsoft rely on Istio as the default service mesh that is offered in their respective Kubernetes cloud services. A fully managed service of Istio for hybrid environments will soon be available from Platform9 Managed Kubernetes service.
  3. Linkerd – Linkerd is arguably the second most popular service mesh on Kubernetes and, due to its rewrite in v2, its architecture mirrors Istio’s closely, with an initial focus on simplicity instead of flexibility. This fact, along with it being a Kubernetes-only solution, results in fewer moving pieces, which means that Linkerd has less complexity overall. While Linkerd v1.x is still supported and supports more container platforms than Kubernetes, new features (like blue/green deployments) are focused on v2. Primarily.

34) Why do we need service mesh in Kubernetes?

A service mesh decouples traffic management from Kubernetes, eliminating the need for a Kube-proxy component to support traffic within service mesh; and managing inter-service traffic, security, and observability by providing an abstraction closer to the microservice application layer

35) What is a sidecar design pattern?

The sidecar pattern is used to promote the separation of concerns in a microservices architecture. This pattern allows us to offload processing of some kind to a separate module that gets deployed along with the main service component. The sidecar pattern is sometimes referred to as a decomposition pattern.

36) What are the cross-cutting concerns in Microservices?

Cross-cutting concerns in microservices are externalized configuration, logging, health checks, metrics, service registration, and discovery, circuit breakers. There are also cross-cutting concerns that are specific to the technologies that the microservices use.

37) What Is Spring Cloud?

Spring Cloud provides tools for developers to quickly build some of the common patterns in distributed systems (e.g., configuration management, service discovery, circuit breakers, intelligent routing, micro-proxy, control bus, one-time tokens, global locks, leadership election, distributed sessions, cluster state).

For typical use cases, Spring cloud provides some out of the box experience and a set of extensive features mentioned below:

  • Versioned and distributed configuration
  • Discovery of the service registration
  • Service to service calls
  • Routing
  • Circuit breakers and load balancing
  • Cluster state and leadership election
  • Global locks and distributed messaging

38) What is Sprint Boot?

Spring Boot makes it easy to create stand-alone, production-grade Spring-based Applications that you can “just run.”

Features of Spring Boot

  • Create stand-alone Spring applications
  • Embed Tomcat, Jetty, or Undertow directly (no need to deploy WAR files)
  • Provide opinionated ‘starter’ dependencies to simplify your build configuration
  • Automatically configure Spring and third party libraries whenever possible
  • Provide production-ready features such as metrics, health checks, and externalized configuration
  • Absolutely no code generation and no requirement for XML configuration

39) Difference Between Spring Cloud and Spring Boot

  • Spring Boot and Spring Cloud are part of the Spring framework. They both have different requirements for work for microservices.
  • Microservice needs both technologies to make it easy to develop and maintain Applications. Spring Cloud is used for a cloud application. Spring boot used for production-ready Applications.
  • Spring Cloud is to collect the deployment configuration and manages itself. At the same time, Spring boot makes microservices to improve productivity.
  • Spring Cloud must use many dependencies. Comparatively, Spring Boot Apply less Dependency. Spring Boot is a lightweight framework.
  • Spring Cloud is Configuration server technology and communicates with many services and collects in one Application. Spring boot is a java based framework to work con auto-configuration in Web Applications.
  • Spring cloud is part of Spring boot, where Spring boot is Stand Alone, App – Centric Application framework.
  • The main purpose of Spring Cloud maintains the traffic of the network. Another Main side purpose of Spring Boot is to reduce time and more productivity.

40) What is Actuator in Spring Boot?

An actuator is a manufacturing term that refers to a mechanical device for moving or controlling something. Actuators can generate a large amount of motion from a small change.

Actuator endpoints let you monitor and interact with your application. Spring Boot includes several built-in endpoints and lets you add your own. Some of the key features are Monitoring, Metrics, Auditing, and more.

41) What is Spring Cloud Gateway, and Why do we need spring cloud gateway??

Spring Cloud Gateway provides a library for building API gateways on top of Spring and Java. It provides a flexible way of routing requests based on several criteria and focuses on cross-cutting concerns such as security, resiliency, and monitoring.

42) What is Zuul?

Zuul Server is an API Gateway application. It handles all the requests and performs the dynamic routing of microservice applications. Zuul is built to enable dynamic routing, monitoring, resiliency, and security. It can also route the requests to multiple Amazon Auto Scaling Groups.

43) How does service Registration and Discovery happens in Spring Cloud?

You will set up a Netflix Eureka service registry and then build a client that registers itself with the registry and uses it to resolve its host. A service registry is useful because it enables client-side load-balancing and decouples service providers from consumers without DNS.

44) How Do You Override a Spring Boot Project’s Default Properties?

This can be done by specifying the properties in the application properties file.

For example, in Spring MVC applications, you have to specify the suffix and prefix. This can be done by entering the properties mentioned below in the application properties file.

  • For suffix – spring.mvc.view.suffix: .jsp
  • For prefix – spring.mvc.view.prefix: /WEB-INF/

45) What are the different systems usually used in Spring Boot Microservices development?

  1. Eureka: Probably the first microservice to be UP. Eureka is a service registry, which means it knows whichever microservices are running and in which port. Eureka is deploying as a separate application, and we can use @EnableEurekaServer annotation and @SpringBootAPplication to make that app a eureka server. So our Eureka service registry is UP and running. From now on, all microservices will be registered in this eureka server by using @EnableDiscoveryClient annotation along with @SpringBootAPplication in all deployed microservices.
  2. Zuul: ZUUL is a load balancer, routing Application, and reverse proxy server as well. That is before we were using apache for reverse proxy things. Now for microservices, we can use ZUUL. The advantage is, in ZUUL, we can programmatically set configurations, like if /customer/* comes to go to this microservice like that. ZUUL can also act as a load balancer, which will pick the appropriate microservice in a round-robin fashion. SO how does the ZUUL knows the details of microservices? The answer is eureka. It will work along with eureka to get microservice details. And in fact, this ZUUL is also a Eureka client where we should mark using @EnableDiscoveryClient; that’s how these two apps(Eureka and zuul) are linked.
  3. Ribbon: Ribbon use for load balancing. This is already available inside ZUUL, in which zuul is using Ribbon for load balancing stuff. Microservices are identified by service name in the properties file. Let’s run two instances of one microservices in a different port. Eureka will identify this, and along with Ribbon(Inside zuul), requests will be redirected in a balanced way.
  4. Aws ALB, NGINX, AWS API gateway, etc.: There are alternatives for all the things mentioned earlier. Aws is having own load balancer, service discovery, API gateway, etc. Not only AWS, all cloud platforms, like Azure, have these. It depends on which one to use.

46) How to log SQL statements in Spring Boot?

Add these properties in your application config

Leave a Reply

Your email address will not be published.