Microservices Interview Questions- Part 5

Microservices Interview Questions- Part 5

In many system design interviews, you’ll be expected to explain how microservices work—and how they compare to monolithic systems. These questions test your understanding of software architecture, scalability, reliability, and communication between services. If you’re preparing for such interviews, this guide is for you.

We’ve compiled the most common microservices interview questions along with clear and practical answers. You’ll review topics like inter-service communication, circuit breakers, API management, load balancing, and database strategies for distributed systems. The goal is to help you explain your thinking confidently during interviews and stand out as a strong candidate.

Whether you’re applying for a software engineer, DevOps, or cloud architect role, these questions will sharpen your technical and communication skills. With the help of this guide, you’ll be ready to answer with clarity and confidence.

Answer:

  1. CD or Continuous Delivery refers to an approach where we treat each code check-in to a common repository as a release candidate. It helps us in getting code ready for deployment with every check-in.CD includes running unit tests, compiling code, doing performance tests & UAT with every check-in. The objective is to produce good quality code that can be deployed with confidence. Continuous Delivery reduces the time between releases & increases the agile nature of the overall software development process. It leads to predictable deployments without any testing, integration, or UAT phases. CD offers several benefits like; lower deployment costs, lower risk of release failure, faster time to market, high-quality code, efficient teams.
  2. Continuous Delivery (CD) is an ability to get changes of all types, including new features, bug fixes, configuration, and experiments into the production or in the hands of users in a sustainable manner.

Answer:

  1. Bulkhead means a software design pattern to create stable fault-tolerant systems. In the Bulkhead pattern, if a system’s part fails, then other parts keep on functioning normally rather than bringing down the entire system. When designing the system, we create separate components in the watertight compartment way. So, if a component fails, we close the access to that component & try to fix it. The rest of the system continues to work business as usual (BAU).
    Netflix’s Hysterix library provides two main ways to implement Bulkhead design patterns.

    1. Thread Isolation: In this case, if calls to a component failure, then these are directed to the thread pool with a fixed no. of threads.
    2. Semaphore Isolation:  In this case, all callers obtain a permit before making a request. If the caller doesn’t get a permit, it means the component is down.

    Hysterix library is in maintenance mode at present. Another open-source library, resilience4j, provides fault-tolerance functionality just like Hysterix.

  2. The term bulkhead is named after the naval ship design. In a ship, a bulkhead is a barrier between other compartments. As a pattern in Microservice Architecture, Bulkhead manifests itself as some form of network segmentation, firewall, or gateway. The key benefit of a bulkhead is that it helps to contain attacks, failures, or performance degradations from spreading to the other system portions as they are partitioned essentially.

Answer:

  1. CAP theorem was published by Eric Brewer. It states that a distributed computing system cannot provide all these three guarantees simultaneously:
    1. Consistency: All nodes view the same data at the same time.
    2. Availability: Each request gets a response of whether the operation is a failure or a success.
    3. Partition tolerance: The system operates regardless of arbitrary partitioning because of network failures.
    Most systems either have CP or AP. A system to run on the network needs P (Partition Tolerance) so, CA (Consistency & Availability) is often ruled out. Between AP & CP, AP systems are easier to scale up as they don’t need to worry about C (Consistency) in the distributed environment.
  2.  The CAP theorem states that it is impossible for a distributed data system to simultaneously provide all the below three guarantees:
    • Consistency: Each read receives an error or the most recent write;
    • Availability: Each request receives a response (non-error), without a guarantee that it contains the most recent write;
    • Partition tolerance: The computing system continues to operate despite an arbitrary no. of messages being delayed or dropped by the network between the nodes.

Answer:

  1. Some major principles of Microservices are as follows:
    1. Business Domain Model: A Microservice implements the functional needs in a particular business domain characterized by the bounded context.
    2. Automation: Microservices has an automation principle that automates the building, deployment, & testing of software. Automation saves time and resources in building & maintaining multiple Microservices.
    3. Information hiding: Microservice hides the internal details of implementation. It ensures that no assumptions are made within a system about the technology stack. The information hiding helps in changing the details of implementation at any time.
    4. Choreography: Most Microservice systems adopt choreography patterns wherein there is no central command. Each Microservice behaves like a state machine & knows how to behave in different events.
    5. Deployment: Microservices are small parts of software deployed independently. They don’t need much downtime like Monolith software.
    6. Isolation: Any failure in a Microservices architecture can be isolated easily to a specific service that causes it. It also helps isolate the impact of failure on the related services & ensure a failure does not cause a complete shutdown.
  2. The following are key principles to remember while designing a microservices-based enterprise application:
    1. Domain-Driven Design– Microservices provide the ability to separate system capability into different domains with DDD (Domain Driven Design) principles. Its main focus is on the associated logic & core domain. DDD minimizes an application’s possibilities of getting out of hand. Besides, it also nurtures creative collaboration between the development & DevOps teams as both must understand the domain for scaling up.
    2. Hide Implementation Details- Microservices are smaller services with independent lifecycles that work jointly as a part of the entire application. However, each service can be independent that needs to be a part of the bigger structure. It is essential to hide details of each service implementation to enhance a service’s ability to scale independently. We could utilize REST protocol over HTTP & ensure services communicate with one another using lightweight communication. Details can be achieved through the segregation of external & internal implementation.
    3. Failure Isolation- A Microservice-based structure is more resistant in contrast to a monolithic structure. For instance, a malfunctioning Microservice with an unclosed database connection or memory leak will only affect that service while others continue to handle the requests.
    4. Continuous Delivery through DevOps Culture– In a Microservice architecture, the no. of deployment units increases; thus, an automated solution is required. It can be achieved through automating the build & deploy process through tools such as Jenkins or CHEF by having a DevOps team. Microservices help to lessen the no. of Jenkins jobs to one job for each release artifact, which can build, deploy, & release the application Microservice.