Microservice Interview @ Sapient - Part-1

Hi Friends,

In this article, I'm sharing interview questions asked on microservices and it's patterns.

Question 1:

What principles microservice architectures has been built upon?

Answer:

• Scalability

• Availability

• Resiliency

• Flexibility

• Independent, autonomous

• Decentralized governance

• Failure Isolation

• Auto-Provisioning

• Continuous delivery through DevOps

Adhering to the above principles brings several challenges and issues while bring our system to live.

These challenges can be overcome by using correct and matching design pattern.

 

Question 2:

What types of design patterns are there for microservices?

Answer:

Question 3:

Explain in detail Decomposition patterns.

Answer:

• Decompose by Business capability: This pattern is all about making services loosely coupled  and applying the single responsibility principle. It decomposes by business capabilities. Means define services corresponding to business capability. It is something that a business does in order to generate values. A business capability often corresponds to a business object, e.g.:

• Order management is responsible for orders
• Customer management is responsible for customers

            

• Decompose by Subdomain: This pattern is all about defining services corresponding to Domain-Driven-Design [DDD] subdomains.  DDD refers to the application's problem space - the business - as the domain. A domain consists of multiple subdomains. Each subdomain corresponds to a different part of the business.  Subdomains can be classified as follows:
• Core
• Supporting
• Generic

The subdomains of Order management consists of:

• product catalog service

• Inventory management service

• Order management services

• Delivery management services

• Decompose by transactions/Two-Phase commit pattern : This pattern can decompose services over transactions. There will be multiple transactions in a system. One of the important participants in a distributed transaction is the transaction coordinator. The distributed transaction consists of two steps:
• Prepare phase
• Commit phase

• Sidecar Pattern: This pattern deploys components of an application into a separate processor container to provide isolation and encapsulation. This pattern can also enable applications to be composed of heterogeneous components and technologies. It is called sidecar as it resembles to a sidecar of a bike. In this pattern, a sidecar is attached to an application and provides supporting features for the application.  

Question 4:

Explain in detail Integration patterns.

Answer:

• API Gateway Pattern: When an application is broken down into multiple microservices, there are a few concerns that need to be considered:
• There are multiple calls for different microservices from different channels

• There is a need for handling different type of protocols

• Different consumer might need a different format of the responses.

An API gateway helps to address many of the concerns raised by the microservice implementation, not limited to the ones above.

• An API gateway is the single point of entry for any microservice calls.

• It can work as a proxy service to route a request to the concerned microservice.

• It can aggregate results to send back to the user.

• This solution can create a fine-grained API for each specific type of client.

• It can also offload the authentication/authorization responsibility of the microservice.

• Aggregator Pattern:  This pattern helps aggregate the data from different services and then send the final response to the client. This can be done in two ways:
• A composite microservice will make calls to all the required microservices, consolidate the data and transform the data before sending back.

• An API gateway can also partition the request  to multiple microservices and aggregate the data before sending it to the consumer. An API gateway can have different modules:
• Mobile API
• Browser API
• Public API

Question 5:

Explain in detail the database patterns, you have worked upon.

Answer:

To define the database architecture for microservices, we need to consider the below points:

• Services must be loosely coupled.They can be developed, deployed and scaled independently.

• Business transactions may enforce invariants that span multiple services.

• Some business transactions need to query data that is owned by multiple services.

• Databases must be sometimes replicated and shared in order to scale.

• Different services have different data storage requirements.

• Database per service: To solve the above concerns, one database per service must be designed. It must be private to that service only. It should be accessed by the microservice API only. It cannot be accessed by other services directly. e.g.: for relational database, we can use private-tables-per-service, schema-per-service or database-server-per-service.

• Shared database per service: This pattern is useful when we have an application which is monolith and we try to break it into microservices. 

• Command Query Responsibility Segregation [CQRS]: Once we implement database per service, there is a requirement to query, which requires joint data from multiple services, it's not possible. CQRS suggests splitting the application into two parts: the command side and the query side.    
• The command side handles the create, update and delete requests.
• The query side handles the query part by using the materialized views. 

The event sourcing pattern is generally used along with it to create events for any data change.

Materialized views are kept updated by subscribing to the stream of events 

• Event Sourcing Pattern:  This pattern defines an approach to handling operations on data that is driven by a sequence of events , each of which is recorded in an append-only store. Application code sends a series of events that imperatively describe each action that has occurred on the data to the event store, where they're persisted. Each event represents a  set of changes to the data.

• Saga Pattern: When each service has it's own database and a business transaction spans multiple services, how do we ensure data consistency across services? Each request has a compensating request that is executed when the request fails. It can be implemented in two ways:
• Choreography: In microservice choreography, each microservice performs their actions independently. It does not require any instructions. It is like the decentralized way of broadcasting data known as events. The service which are interested in those events , will use it and perform actions. It is like an asynchronous approach.

• Orchestration:  In the microservice orchestration, the orchestration handles all the microservice interactions. It transmits events and responds to it.  The microservice orchestration is more like a centralized service. It calls one service and waits for the response before calling the next service. This follows a request/response type paradigm.

That's all for this post.

Thanks for reading!!