Microservices Interview Questions Preparation Course

A Microservice is a small and autonomous piece of code that does one thing very well. It is focused on doing well one specific task in a big system. 

Microservices provide many benefits. Some of the key benefits are:

1. 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.
2. 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.
3. 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.
4. 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

Q.   What are the important Cross-Functional Requirements to consider during the design of a Microservice?

Some of the important cross-functional requirements for design consideration are:

• I.     Availability
• II.     Latency
• III.     Durability of data

Q.   What is Idempotency of a Microservice operation?

Idempotency refers to getting same result even after doing same operation multiple times in a Microservice. Eg. Let say, we have to send a reminder email to a customer for upcoming payment on due date.

Our Microservice provides an idempotent Reminder operation, so that even if we call this operation multiple times on the due date, it sends only one email per day. This will give better experience to customer instead of sending multiple reminders for same payment on same day.

Q.   What is Command Query Responsibility Segregation (CQRS) design pattern?

Command Query Responsibility Segregation (CQRS) is a design pattern for storing and querying information in which storing of information can be done in a system separate from the system used for querying the information. It can help us in scaling a system and providing better performance for both reads and writes.

In this, Commands are the requests to modify data in the system. Once commands are validated, data is updated.

Query can work on updated data set and provide results to clients.

Command and Query logic can be implemented in different services that can live on different servers.

In case there is high load on Query service, then you just scale the Query service. Also you can support multiple formats for the response from a Query service to satisfy requirements of multiple clients.

Q.   What is CAP theorem?

Eric Brewer published CAP theorem in a paper that states that it is impossible for a distributed computing system to simultaneously provide all three guarantees:

• I.         Consistency (all nodes see the same data at the same time)
• II.         Availability (every request receives a response about whether it succeeded or failed)
• III.         Partition tolerance (the system continues to operate despite arbitrary partitioning due to network failures)

Most of the systems have CP or AP. For a system to run on a network, it needs P i.e. Partition Tolerance. So CA is often ruled out.

Between CP and AP, AP systems are easier to scale. They do not have to worry about Consistency in distributed environment.

Q.   What is a good tool for documenting the Microservices?

Swagger is a good tool to document the APIs provided by Microservices. It is an open source tool that is very easy to use. It provides interactive documentation.

You can use Swagger annotation to add documentation in REST APIs and then use Swagger to generate a web interface. By using that Web Interface you can see to list of APIs, their inputs and even invoke these APIs to get results from these APIs.

Swagger UI is a very helpful tool for a newcomer to understand different APIs provided by a Microservice.

Q.   In which scenarios, implementing Microservices architecture is not a good idea?

Microservices architecture is a great architecture if it is done correctly. To do it correct, you need to think in terms of bounded contexts and create services for each context. If you are new to a domain then you may not have expert level knowledge in that domain to create a bounded context. This can lead to poor choice of bounded context and corresponding Microservices. So you should not try Microservices architecture in a completely new domain.

At times it is a good idea to start with Monolith software and then gradually decompose it into Microservices. If your organization is new and does not have support for growing number of Microservices, then it is better to go with Monolith software. With time and increased maturity of the organization, you can pick up the Microservices architecture.