Microservices Interview Questions Preparation Course
- 3.5 hours on-demand video
- 4 articles
- Full lifetime access
- Access on mobile and TV
- Certificate of Completion
Get your team access to 4,000+ top Udemy courses anytime, anywhere.Try Udemy for Business
- Understand Microservices Architecture
- Learn important concepts of Microservices
- Understand benefits of Microservices
- Answer questions on Microservices development
- Best practices of Microservices
- Understand Software Architecture level concepts
- Demand higher salary or promotion based on the knowledge gained
How to master Microservices interview questions?
This course contains most popular Microservices interview questions. We have provided answers to these questions in our videos. Some videos contain more than one question.
Steps to be followed to master Microservices interview questions are as follows:
- First watch the video to learn the sample answer for interview question.
- Attempt the Quiz at the end of section.
- Go through the questions in the section and try to recall the answer.
- There are some questions for which you have to watch the video multiple times.
- At the end of the course, there is Test Your Knowledge section. Use this to ensure that you have fully mastered the information in this course.
Microservices provide many benefits. Some of the key benefits are:
- Scaling: Since there are multiple Microservices instead of one monolith, it is easier to scale up the service that is being used more. Eg. Let say, you have a Product Lookup service and Product Buy service. The frequency of Product Lookup is much higher than Product Buy service. In this case, you can just scale up the Product Lookup service to run on powerful hardware with multiple servers. Meanwhile, Product Buy service can remain on less powerful hardware.
- Resilience: In Microservice architecture, if your one service goes down, it may not affect the rest of the system. The other parts can keep functioning, business as usual (BAU). Eg. Let say, you have Product Recommendation service and Product Buy service. If Product Recommendation service goes down, the Product Buy service can still keep running.
- Technology Mix: With so many changes in technology everyday, you can keep using the latest technology for your new Microservices. You can adopt new technologies with less risk compared to Monolithic architecture. This is one of the best benefits of Microservices architecture.
- Reuse: Microservices help you in reusing the lessons learnt from one service to another. Easy Deployment: Microservices architecture, if done correctly, helps in making the deployment process smooth. If anything goes wrong, it can be rolled back easily and quickly in Microservices.
Microservices is a newly growing domain, so there is no fixed list of principles of Microservices. Some of the major principles are:
- I. Business Domain Model: A Microservice implements the functional requirements in a specific business domain that is characterized by a bounded context. It does one specific thing and does it very well.
- II. Automation: Often there are multiple Microservices in a system, so it is essential to use automation in deployment, testing and building of software. The more we automate, the more time we save in introducing more Microservices.
- III. Information hiding: Microservices hide their internal implementation details. This ensures that no assumptions are made within the system about the technology stack used by a service. This information hiding also helps in changing the implementation details at any time.
- IV. Choreography: Most of the Microservice systems adopt choreography pattern in which there is no central command. Each Microservice behaves like a state machine and it knows how to behave in different events.
- V. Deployment: Microservices are small parts of software that can be independently deployed. They do not require much downtime like Monolith software.
- VI. Isolation: Any failure in Microservices architecture can be easily isolated to the specific service that causes it. It can also help in isolating the impact of failure on related services. This can ensure that one failure does not cause complete shutdown.
Architects, in Microservices architecture, play the role of Town planners. They decide in broad strokes about the layout of the overall software system.
They help in deciding the zoning of the components. They make sure components are mutually cohesive but not tightly coupled. They need not worry about what is inside each zone.
Since they have to remain up to date with the new developments and problems, they have to code with developers to learn the challenges faced in day-to-day life.
They can make recommendations for certain tools and technologies, but the team developing a micro service is ultimately empowered to create and design the service. Remember, a micro service implementation can change with time.
They have to provide technical governance so that the teams in their technical development follow principles of Microservice. At times they work as custodians of overall Microservices architecture.
Q. What is the advantage of Microservices architecture over Service Oriented Architecture (SOA)?
Service Oriented Architecture (SOA) is an approach to develop software by creating multiple services. It creates small parts of services and promotes reusability of software. But SOA development can be slow due to use of things like communication protocols SOAP, middleware and lack of principles.
On the other hand, Microservices are agnostic to most of these things. You can use any technology stack, any hardware/middleware, any protocol etc. as long as you follow the principles of Microservices.
Microservices architecture also provides more flexibility, stability and speed of development over SOA architecture.
Q. What are the disadvantages of using Shared libraries approach to decompose a monolith application?
You can create shared libraries to increase reuse and sharing of features among teams. But there are some downsides to it.
Since shared libraries are implemented in same language, it constrains you from using multiple types of technologies.
It does not help you with scaling the parts of system that need better performance.
Deployment of shared libraries is same as deployment of Monolith application, so it comes with same deployment issues. Shared libraries introduce shared code that can increase coupling in software.
Q. What are the characteristics of a Good Microservice?
Good Microservices have these characteristics:
a. Loose coupling: A Microservice knows little about any other service. It is as much independent as possible. The change made in one Microservice does not require changes in other Microservices.
b. Highly cohesive: Microservices are highly cohesive so that each one of them can provide one set of behavior independently.
c. Bounded Context: A Microservice serves a bounded context in a domain and communicates with rest of the domain by using an interface for that Bounded context.
d. Business Capability: Microservices individually add business capability that is part of big picture in organization.
Q. What is Bounded Context?
A bounded context is like a specific responsibility that is developed within a boundary. In a domain there can be multiple bounded contexts that are internally implemented. Eg. A hospital system can have bounded contexts like- Emergency Ward handling, Regular vaccination, Out patient treatment etc. Within each bounded context, each sub-system can be independently designed and implemented.
Q. Is it a good idea for Microservices to share a common database?
Sharing a common database between multiple Microservices increases coupling between them. One service can start accessing data tables of another service. This can defeat the purpose of bounded context. So it is not a good idea to share a common database between Microservices.
Q. What is the difference between Orchestration and Choreography in Microservices architecture?
In Orchestration, we rely on a central system to control and call various Microservices to complete a task. In Choreography, each Microservice works like a State Machine and reacts based on the input from other parts.
Orchestration is a tightly coupled approach for integrating Microservices. But Choreography introduces loose coupling. Also, Choreography based systems are more flexible and easy to change than Orchestration based systems.
Orchestration is often done by synchronous calls. But choreography is done by asynchronous calls. The synchronous calls are much simpler compared to asynchronous communication.
Q. What are the issues in using REST over HTTP for Microservices?
In REST over HTTP, it is difficult to generate a client stub.
Some Web-Servers also do not support all the HTTP verbs like- GET, PUT, POST, DELETE etc.
Due to JSON or plain text in response, performance of REST over HTTP is better than SOAP. But it is not as good as plain binary communication.
There is an overhead of HTTP in each request for communication.
HTTP is not well suited for low-latency communications. There is more work in consumption of payload. There may be overhead of serialization, deserialization in HTTP.
Q. Can we create Microservices as State Machines?
Yes, Microservices are independent entities that serve a specific context. For that context, the Microservice can work as a State Machine. In a State Machine, there are lifecycle events that cause change in the state of the system.
Eg. In a Library service, there is a book that changes state based on different events like- issue a book, return a book, lose a book, late return of a book, add a new book to catalog etc. These events and book can form a state machine for Library Microservice.
Q. What is Reactive Extensions?
Reactive Extensions is a design approach in which we collect results by calling multiple services and then compile a combined response.
These calls can be synchronous or asynchronous, blocking or non-blocking.
It is also known as Rx.
Rx works opposite to legacy flows. It is very popular in distributed systems. You just react to the response received from another Microservice.
Q. What is DRY?
DRY stands for Don’t Repeat Yourself. It promotes concept of code reusability. Due to which people develop libraries and share these libraries. This sharing can result in tight coupling. DRY should be a concern within a Microservice implementation. But across 2-3 Microservices, you can ignore the DRY.
Q. What is Semantic Versioning?
Semantic Versioning is a type of software versioning that is easy to understand by the users of that software. In this specification, each software version is specified in the format of Major.Minor.Patch.
Major version increment means that the changes to software are not backward compatible.
Minor version increment means that new functionality is added but changes are still backward compatible.
Patch version increment means that a fix to bug is provided in this version.
It is very well described on site http://semver.org
Semantic Versioning is the recommended versioning scheme for Microservices development and release.
It also helps in managing dependencies across multiple Microservices.
Q. Is it a good idea to build a Microservice or buy a commercial off the shelf software?
If an organization’s core work is related to the software to be developed then a Microservice should be built. Eg. A hospital management company can build Microservice for Doctor/Patient checkin etc. But it can buy off the shelf software for managing parking lot.
Investment in building and maintaining a Microservice in house is worthwhile, if it becomes an asset over time for the organization.
Q. What is Continuous Integration?
Continuous Integration (CI) is a software development approach in which developers merge their code into a common repositories several times in a day. To merge the code, every check in should run build and run a set of tests that ensures that common repository is always ready for deployment.
CI provides the benefit of early feedback for any code that is developed and merged into common repository.
There are many tools for CI that help in running build, running tests and providing feedback back to developer checking in code.
Q. What is Continuous Delivery?
Continuous Delivery (CD) is an approach in which we treat every check in to common repository as a release candidate. CD helps us in getting code ready for deployment with every check in.
CD involves compiling code, running unit tests, doing UAT and performance tests so that code is of such a good quality that it can be deployed with confidence.
CD also reduces time between releases, as well as it increases agile nature of overall software development process.
Q. What is Ubiquitous language?
Ubiquitous language (UL) is a term used by Eric Evans for Domain Driven Design. UL is a common language used by developers and users for common specification for the domain that they are working on. It is a rigorous language in which domain can be explained easily.
UL brings all the team members on the same page. UL has to be a crystal clear language so that it can be translated into software that a machine can understand.
Q. What is the benefit of Single Service per Host model in Microservices?
When we deploy Single Service on a Host, then we get the benefit of avoiding single point of failure. A failure on one host will only impact one service at a time.
It also makes monitoring and security easier than multiple services on one host.
Single Service per Host is also easier to scale in case we want a specific service to be scaled up.
Q. What are different types of Tests for Microservices?
In Microservices approach there are multiple Microservices, so testing can become quite complex. In such a scenario it is better to divide tests into different levels.
At the bottom level are Technology facing tests like- unit tests and performance tests. Often, these are completely automated.
In the middle level we have tests for exploratory testing like- how to break the system. Running stress tests and usability tests.
At the top level are acceptance tests that are fewer in number. These acceptance tests help stakeholders in understanding and verifying software features. Some of these tests can be manual tests.
Q. How can we eradicate non-determinism in tests?
Non-Deterministic Tests (NDT) are unreliable tests. Some times they pass and some times they fail. When they fail, you re-run them and then they pass. Therefore, their results are not consistent. There are some suggestions from Martin Fowler to remove non-determinism from tests.
Q. What is PACT?
PACT is an open source tool to allow testing interactions between service providers and consumers in isolation against a contract.
It is a tool to implement Consumer Driven Contract in Microservices.
By using PACT you can test the consumer driven contracts between consumer and provider of a Microservice. It is an automated suite to test this interaction that increases the reliability of Microservices integration.
Q. How can we separate Deployment from Release of Microservices?
Deployment and Release are two separate events for Microservices. One way of doing this is blue/green deployment. In this case, there are two versions of a Microservice deployed at a time. But only one version is taking real requests. Once the other version is tested well, then we switch the versions.
We can run a smoke test suite to verify that the functionality is running correctly in newly deployed version. Based on results of smoke test, newer version can be released to become the live version.
In this way, we just separated deployment from release.
Q. What is Canary Releasing?
Canary Releasing is a technique to direct a small set of users to newly deployed version to verify that release is working as expected. Once we are satisfied, then we can gradually increase traffic to new version. Finally the old version is phased out.
In Canary Releasing two versions coexist for a longer period of time than blue/green deployment.
Q. What is the difference between Mean Time to Repair (MTTR) and Mean Time between failures (MTBF)?
If a release goes bad, we need to repair it. The average time taken to repair a release is Mean time to repair (MTTR). On the other hand, we can choose an approach in which we just discard the new release and replace it with the old release. So there will be a time period in which new release failed. But the old one quickly replaced it. This is known as mean time between failures (MTBF).
In Microservices architecture, instead of spending too much effort in making the service so robust with enormous amount of test cases, we focus on MTBF. i.e. If one version of a service doing well and the newer version fails, then we just replace it with the previous one quickly and later on fix the newer version.
Q. How can we do cross-functional testing?
Cross-functional testing is verification of non-functional requirements. These requirements are such characteristics of system that cannot be implemented like a normal feature. Eg. Number of concurrent users supported by system, usability of site etc.
Cross-functional testing is related to cross-functional requirements. Often business users do not specify cross-functional requirements in the beginning. But they expect these when software is complete and deployed to production. It is always a good idea to ask business users about such cross-functional expectations in initial phase of the project itself.
Q. What is a good tool for monitoring multiple services at a time?
Graphite is an open source database that captures metrics from services in a time series database. By using Graphite we can capture essential metrics of multiple Microservices simultaneously. And we can use a dashboard like- Grafana to monitor these metrics in almost real time.
Graphite is also great at handling large amount of data. It can also show the trends from few hours to few months within a few seconds. Many organizations like- Facebook etc use Graphite for monitoring.
Q. What is Semantic Monitoring?
At times after the deployment we want to make sure that complete end to end system is working fine. To achieve this we can create a Synthetic Transaction that is hidden from outside world, but it can test actual functionality of the system.
This synthetic transaction moves across multiple services, and each services processes it. Finally, we get complete end result for this Synthetic Transaction. Based on the end result received after processing of this transaction we can confirm that system is working as expected. This technique of verifying semantic correctness of the system is known as Sematic Monitoring.
Q. Why do we use Correlation IDs in Microservices architecture?
In Microservices architecture, if there is a failure in one Microservice, then we may have to go to upstream Microservice to find the source of failure. Or we may have to go to downstream Microservices to find the impact of the failure. Since each Microservice is independent, we need some relation between the error in a service as well as the error in its upstream/downstream services.
To resolve this issue, we can use Correlation IDs. These are unique IDs like GUID that are passed from one service to another service during an API call. By using a GUID and failure associated with it we can find the source of failure as well as the impact of failure.
Q. What is the difference between Authentication and Authorization?
Authentication is the process of verifying credentials of a user. It checks whether a user is genuine or not by checking identity of a user. Most common way of Authentication is a User/Password check.
Authorization is the process of checking whether a user has access to resources or not. There can be different levels of authorization in a Microservice. Eg. Some users may just have read access. Some user may have write access to certain parts.
The correct mix of Authorization and Authentication is important for implementing security features in a Microservice.
Q. How does HTTPS authentication works in Microservices?
HTTPS is also known as HTTP Secure. This protocol ensures that all communication between Microservices is secure and encrypted. It is used for handling confidential information between Microservices.
In HTTPS, client is assured that the Server it is talking to is a genuine server. To do so, HTTPS uses SSL certificates.
Also encrypting the request and response helps in avoiding eavesdropping. SSL ensures that all communication is encrypted and decrypted in a secure way. The drawback for encryption is that it cannot be used in proxy caching.
Q. What are Client certificates?
Client certificate is another form of security that is implemented at Transport Layer instead of Application layer. Each client installs a X.509 certificate locally. This ensures that server can rely on the validity of client, if it has right certificate.
It is more complex than SSL, since it has to manage certificates at all clients.
Q. Why some big companies use API keys for providing access to public APIs?
Many big companies like- Google, Amazon etc provide public APIs to developers. These APIs come with an API key. This API key is used for various purposes:
I. An API key can authenticate a client
II. An API key can impose limits of number of calls to API
III. An API key can limit the access of a client to certain APIs only
IV. An API key can introduce security in Service call between client and provider
Q. What is Confused Deputy Problem in security context?
In Microservices world, Confused Deputy is a computer security problem. In this case one service acts as deputy and accepts authenticated requests from other clients to perform an action. Sometimes, one malicious client can hack the system and send a falsely authenticated request. Since the request is authenticated, deputy will do the same action for malicious client. This can breach the security of the system.
Eg. Let say a service depends on barcode to get the price. If a client provides incorrect barcode, the service will provide incorrect price, since it relies on the authenticity of barcode.
Q. What are the different points to consider for security in Microservices architecture?
Implementing security in Microservices architecture has its own challenges. Since there are multiple Microservices and many interfaces between them it is important to consider following aspects for implementing correct security in Microservices architecture:
- I. Data in Motion
- II. Data at Rest
- III. Firewalls
- IV. Operating system
- V. Logging
- VI. Intrusion Monitoring
- VII. Network segregation
- Software Development Experience
- Familiar with Programming
Microservices Architecture is one of the fastest growing software in technology world. Big companies like Amazon, Netflix, Google etc use Microservices based architecture. This course is designed to help you achieve your goals in Microservices field. Software Engineers with Microservices knowledge may get more salary than others with similar qualifications without Microservices knowledge.
In this course, you will learn how to handle interview questions on Microservices technology in Software Design and Development. I will explain you the important concepts of Microservices architecture.
You will also learn the benefits and use cases of Microservices in this course.
What is the biggest benefit of this course to me?
Finally, the biggest benefit of this course is that you will be able to demand higher salary in your next job interview.
It is good to learn Microservices for theoretical benefits. But if you do not know how to handle interview questions on Microservices, you can not convert your Microservices knowledge into higher salary.
What are the topics covered in this course?
We cover a wide range of topics in this course. We have questions on Microservices best practices, Security, Pact, Bulkhead Design Pattern etc.
How will this course help me?
By attending this course, you do not have to spend time searching the Internet for Microservices interview questions. We have already compiled the list of the most popular and the latest Microservices Interview questions.
Are there answers in this course?
Yes, in this course each question is followed by an answer. So you can save time in interview preparation.
What is the best way of viewing this course?
You have to just watch the course from beginning to end. Once you go through all the videos, try to answer the questions in your own words. Also mark the questions that you could not answer by yourself. Then, in second pass go through only the difficult questions. After going through this course 2-3 times, you will be well prepared to face a technical interview in Microservices architecture.
What is the level of questions in this course?
This course contains questions that are good for a Fresher to an Architect level. The difficulty level of question varies in the course from a Fresher to an Experienced professional.
What happens if Microservices technology changes in future?
From time to time, we keep adding more questions to this course. Our aim is to keep you always updated with the latest interview questions on Microservices.
What are the sample questions covered in this course?
Sample questions covered in this course are as follows:
- What is a Microservice?
- What are the benefits of Microservices architecture?
- What is the role of architect in Microservices architecture?
- What is the advantage of Microservices architecture over Service Oriented Architecture (SOA)?
- Is it a good idea to provide a Tailored Service Template for Microservices development in an organization?
- What are the disadvantages of using Shared libraries approach to decompose a monolith application?
- What are the characteristics of a Good Microservice?
- What is Bounded Context?
- What are the points to remember during integration of Microservices?
- Is it a good idea for Microservices to share a common database?
- What is the preferred type of communication between Microservices? Synchronous or Asynchronous?
- What is the difference between Orchestration and Choreography in Microservices architecture?
- What are the issues in using REST over HTTP for Microservices?
- Can we create Microservices as State Machines?
- What is Reactive Extensions?
- What is DRY?
- What is Semantic Versioning?
- Is it a good idea to build a Microservice or buy a commercial off the shelf software?
- Why do we break the Monolith software into Microservices?
- What is Continuous Integration?
- What is Continuous Delivery?
- What is Ubiquitous language?
- What is the benefit of Single Service per Host model in Microservices?
- What are different types of Tests for Microservices?
- What is Mike Cohn’s Test Pyramid?
- What is the difference between Mock or Stub for Microservice tests?
- How can we eradicate non-determinism in tests?
- What is a Consumer Driven Contract (CDC)?
- What is PACT?
- How can we separate Deployment from Release of Microservices?
- What is Canary Releasing?
- What is the difference between Mean Time to Repair (MTTR) and Mean Time between failures (MTBF)?
- How can we do cross-functional testing?
- What is a good tool for monitoring multiple services at a time?
- What is Semantic Monitoring?
- Why do we use Correlation IDs in Microservices architecture?
- What is the difference between Authentication and Authorization?
- How does HTTPS authentication works in Microservices?
- What are Client certificates?
- Why some big companies use API keys for providing access to public APIs?
- What is Confused Deputy Problem in security context?
- How can we secure Data at Rest in an organization?
- What are the different points to consider for security in Microservices architecture?
- What is Conway’s law?
- What are the important Cross-Functional Requirements to consider during the design of a Microservice?
- What is a Circuit Breaker pattern in the context of Microservice?
- What is Bulkhead design pattern?
- What is Idempotency of a Microservice operation?
- How can you scale a Database?
- What is Command Query Responsibility Segregation (CQRS) design pattern?
- How will you implement Caching in Microservice?
- What is CAP theorem?
- How will you implement Service Discovery in Microservices architecture?
- What is a good tool for documenting the Microservices?
- In which scenarios, implementing Microservices architecture is not a good idea?
- What are the major principles of Microservices?
- Software Engineer, Sr. Software Engineer, Member Technical Staff, Expert
- Software Architect, Development Manager, Director
- Anyone who wants to learn Microservices architecture
- People interested in going up in career!!