[0:07]Hi everyone, this is Arvind from Mind Majix, and today I welcome you all to this amazing video on micro services interview questions. So guys, in this particular video we will be covering roughly around 30 questions, and all those 30 questions are divided into three categories. So like, the first 10 questions will be the freshers or the beginner level questions. The second category will be for the intermediate folks, or like those people who have at least a couple of years of experience with micro services. And then we have the advanced category, like the last 10 questions, and in those 10 questions, like we will be covering advanced concepts. Like it will be specifically for those people who have at least four to five years of experience with micro services. Okay, I hope the agenda is pretty much clear and easy to understand. And before moving ahead, I want you guys to subscribe to Mind Majix's YouTube channel and also hit that bell icon so that you never miss an update from us. So, without any further ado, let's get started with our first question. So the first question over here is, like obviously, a very basic question, what are Microservices? So, in this particular question, you have to just explain the definition of microservices. So, like microservices are an architectural style where an application is built as a collection of small, independent, and loosely coupled services. So, each service in this microservice is designed to handle a specific business capability with its own logic and database. And this was a quick definition of microservices, and over here, you can also give an example, like let's suppose in an e-commerce platform, the product catalog, user management, and order processing, and payment services are designed. Like, all of these components or like all of these modules are designed separately, and each one of them is a separate microservice. So, what is the advantage of building these modules as separate entities? So, this enables each service to be developed, deployed, and scaled independently. So, this was an example of microservice. The next very important question over here is how do microservices differ from monolithic architecture? Like, before microservices, we had the monolithic architecture. So, over here, you have to just explain the difference, and in this particular question, we will be comparing microservices and monolithic architecture based on some parameters. So, those parameters are, as you can see on the screen, architecture, scalability, technology stack, deployment, and use case. So, let's discuss these points one by one. If you talk about architecture, so for monolithic architecture, you have a single code base that contains all of the modules tightly coupled into one executable. Whereas if you talk about microservices, so here they are basically decoupled, like all of the modules are separate entities, and they provide modular services, and each one of them is designed for a specific business function, and the communication happens through APIs. Now, if you talk about scalability, so for monolithic architecture, it primarily relies on vertical scaling, like adding more resources, like the CPU or memory, to a single server. Whereas, if you talk about the scalability for microservices, so here the focus is on horizontal scaling, like adding more instances of individual services as and when required. If you talk about the third point, which is the technology stack, so basically for monolithic architecture, it requires a uniform stack for the entire application, limiting the flexibility. So, the flexibility aspect is very limited for a monolithic architecture. Whereas if you talk about microservices, so this allows a diverse stack, and this lets team choose the best technology for each services.
[4:16]Then the fourth point over here is deployment. So for monolithic architecture, everything is deployed as a single unit, requiring the entire application to be redeployed for changes. So, if if at all you have to make any changes in the monolithic architecture, so you have to again redeploy, like you have to make the changes first and then redeploy the entire application. Whereas, if you talk about deployment for a microservices architecture, so here you can independently deploy a particular microservice. So, what is the benefit over here? So this allows updates for one services without redeploying the others.
[5:00]So, only that particular microservice, where you need update, that you have to redeploy, you do not have to redeploy the all of the microservices. And the last point over here is the use case. So, for a monolithic architecture, it is very much suitable for smaller applications or system with fewer updates and minimal scaling needs. Whereas, if you talk about microservices, so here it is very much suitable for large, complex, and rapidly evolving systems, requiring scalability and flexibility.
[5:37]The next question over here is what are the key features of microservices? So guys, there are basically three important features of microservices, as you can see on the screen, the first one is independent deployment. So basically in microservice, each service operates independently, and this allows for seamless deployment, updates and maintenance without impacting the functionality of other services. And now if you talk about fault isolation, so basically a failure in one service does not cause the entire application to fail. So this ensures a greater resilience and minimizes the downtime. For example, if Netflix payment gateway service experiences some problem or glitches, so it does not disrupt the streaming service as they are isolated or like they are the separate components. And the third point over here is the scalability. So, each service can be scaled independently based on its specific load and demand, and thereby optimizing the resource usage and improving the performance. For example, during peak time, Netflix can scale its streaming service while keeping other services like account management at baseline levels. So, these features collectively make microservices highly adaptable, resilient, and efficient for modern applications, especially for those requiring dynamic scalability and high availability. The next question over here is name the main components of microservices. So guys, in this particular question, you have to mention in detail the components and the characteristics of microservices architecture. So, first, if you talk about the characteristics, so over here, as you can see on the screen, these are the important characteristics or some important principles on which entire microservices concept has been derived. So, if you talk about core characteristics, so here you have service independence, domain driven design or the DDD, then you have the API communication, and then you have the technology diversity. And if you talk about the main components, so basically, as you can see on the screen, these are the important components of microservices architecture. Let's just describe them one by one. So, if you talk about service registry and discovery, so basically this is a centralized system that helps the services locate each other dynamically. For example, Netflix Eureka, Console, or Kubernetes. Then if you talk about API gateway, so this acts as a single entry point for clients, routing requests to appropriate services, and handling concerns like authentication, logging, and rate limiting.
[8:31]Then the next important concept or the component over here is the load balancer. So, load balancer basically distributes the incoming traffic across the instances of a service to ensure high availability. Then you have the data management. So, basically each service typically manages its own database, like database per service pattern, and this ensures the loose coupling among different services. Then you also have the monitor and logging.
[9:02]Over here, you have tools like Prometheus, Grafana, and ELK stack, and these tools ensure real-time monitoring and debugging. And last but not the least, you have the CICD pipeline. So, basically CICD pipeline automates testing, deployment and scaling, and it ensures faster iterations and minimized downtime. So, these were some of the important components of microservices architecture. The next question is, explain the role of an API Gateway in microservices. So guys, just in the previous question, we have seen that API Gateway is one of the crucial or you can say a very important component of microservices architecture. So, in this particular question, you have to explain in detail what is an API Gateway, or what is the role of API Gateway in microservices. So, an API Gateway serves as a centralized entry point for managing client interactions with microservices. Basically, it simplifies communication by routing incoming requests to the appropriate microservices and handling various operational responsibilities as well. So, if you talk about the responsibilities of an API Gateway, so there are three primary responsibilities of API Gateway. The first one is request routing. So, the API Gateway directs incoming client requests to the microservices based on the operation that is being performed. The second responsibility is load balancing. So, basically, an API Gateway distributes requests evenly across the multiple instances of a service to ensure optimal resource usage and high availability. And the third point over here is authentication and authorization. So, the gateway verifies user credentials and enforces security policies to ensure that only authorized users can access specific services.
[11:03]So, let's suppose, let's consider an example over here. So, if you have a travel app, so over here, the API Gateway acts as a mediator between the clients and the services. So, whenever a user interacts with the app, so what is the role of an API Gateway over here? So, with the help of API Gateway, routes booking related requests to the booking services. So, basically you have a request from a user for booking a particular travel mode, like maybe it can be a flight or a train or a bus. So, those requests are directed or diverted to the booking services. So, apart from that, you can also have users who want to do the payments for a particular service that they are using. Like, for example, they have booked a ticket, so they want to now do the payment. So, an API Gateway will direct this kind of request to the payment operations or the payment Gateway service. And then after this, you can have itinerary queries, like user can request or they want some information regarding the itinerary of a destination. So, these kind of queries are directed to the itinerary manager service. So, by centralizing these operations, the API Gateway streamlines the client experience while ensuring efficient and secure communication with the microservices. The next question over here is, what is service discovery in microservices? Service Discovery is basically a mechanism that enables microservices to dynamically locate and communicate with each other within a distributed system. Now, what is the advantage or benefit of service discovery in microservices? So, basically it ensures that the services can find and connect to other services without hard-coded configurations, promoting flexibility and scalability. So guys, there are basically two types of service discoveries in microservices. The first one is the client side discovery. In this particular approach, each service is responsible for keeping track of and managing its own service registry. So, the client queries the registry to locate the available service instances and then chooses the one to interact with. And the second type is the server side discovery. So, centralized registry such as the Eureka or a console maintains the locations and the statuses of all services. So, when a client makes a request, the server side load balancer queries the registry and routes the request to an appropriate service instance. So, this was all about service discovery in microservices. The next question is, what is a container, and why is it used in microservices? So, basically, a container is a lightweight, standalone unit that bundles an application along with its dependencies, including libraries, configurations, and runtime, to ensure consistency across different environments. So, this was a simple and a light and a crisp definition of a container. Now, why do you use container in microservices? So, basically there are two important benefits of using containers in microservices. So, the first benefit is the consistent deployment. So, containers ensure that the application run the same way in development, testing and production environment, and this minimizes the compatibility issues. And the second advantage is faster startup time. So, containers are more lightweight and have faster initialization times compared to traditional virtual machines, thereby enabling quicker deployments and scalability. For example, by using Docker, a payment microservice can be packaged with all of its dependencies to guarantee that it performs identically on a developer's machine, a test server, or a production server, providing reliability and efficiency throughout the development life cycle. The next question is, how do microservices communicate with each other? In a microservices architecture, communication between services is crucial for achieving coordination and collaboration. Since microservices are designed to be independent and loosely coupled, they rely on well-defined communication protocols and mechanisms. If you talk about the methods of communication that is used in microservices, so the first technique is the RESTful APIs. So, RESTful APIs means, like if you talk about the REST, so REST basically means representational state transfer. So, this is a lightweight and a widely used communication protocol, and it uses HTTP methods like GET, POST, PUT, DELETE to facilitate synchronous communication between services. The second technique is through message queues. So, message queues enables asynchronous communication between services, thereby allowing messages to be sent and received without requiring the services to be active simultaneously. So, now if you talk about the popular tools over here is, so here you have Apache Kafka, AWS SQS, and RabbitMQ. And the third technique by which microservices communicate with each other is the GRPC or the G Remote Procedure Call. So, basically this is a high performance framework developed by Google. So, it uses HTTP 2 for communication and the protocol buffers for data serialization, and thereby this makes it more efficient than the rest for some use cases. So, these are the three techniques through which microservices communicate with each other. The next question is, how would you handle a microservice failure? So, basically in a microservices architecture, failures are inevitable, but the goal over here is to minimize their impact on the overall system. So, since microservices often communicate with each other, one failure can trigger a chain reaction, leading to cascading failures that affect the entire application.
[17:38]So, to mitigate such issues, there are several techniques and the best practices for handling the microservices. So, the first technique over here is the circuit breakers. So, a circuit breaker is basically a design pattern that helps prevent cascading failures by stopping the flow of requests to a service that is likely to fail. So, if a microservice detects that another service is not responding or is behaving in a weird way, so the circuit breaker opens, preventing further requests to the failing service, and this allows it for the time to recover.
[18:16]The second technique is retries and fallbacks. So, when a service fails to respond, a retry mechanism can automatically attempt to resend the request after a short delay. So, this is particularly useful in scenarios where the failure is due to temporary issues such as network congestion or brief outages. And the third technique is centralized logging. So, in a microservices environment, troubleshooting and identifying the root cause of failures can be difficult due to distributed nature of the system. So, over here, centralized logging aggregates the logs from all of the services into one location, and this makes it easier to monitor the system and quickly identify and resolve failures. The next question is, how can you ensure backward compatibility in microservices? So, backward compatibility is critical when deploying updates to microservices to avoid breaking client applications. Using versioning in APIs and following semantic versioning principles can ensure smooth transitions.
[19:29]So, just to give you an example, Microsoft maintains backward compatibility in its Azure services by following strict API versioning practices, providing a smooth experience for developers and the application. With this, we have covered the beginner level questions or the questions that were meant for the freshers. And now question number 11 onwards, like 11 to 20, we will be covering the questions that are meant for the intermediate folks, or the intermediate people who have at least two to three years of experience with microservices. So, the next question over here is, what is the meaning of OAuth, and why is it used? So, basically OAuth stands for Open Authorization. It is an open standard protocol that allows third-party applications to access a user's resources without exposing their credentials, such as usernames and passwords. So, OAuth provides a secure and a user friendly way to grant access to certain parts of an application or a service without directly sharing the sensitive information. The next question is, what is CQRS pattern in microservices? What problem does it solve? So, basically CQRS stands for Command and Query System in which data operations are separated into two, command which writes data into database and Query system which reads data from database or data store. So, by splitting your application into two components, you can better optimize your applications depending upon whether it is write heavy or a read heavy application. The next question is, compare API Gateway and Load Balancer in microservices.
[21:27]So, load balancer is basically an old concept which is used to distribute load or traffic across multiple instances. So, it can be implemented as a hardware solution or as a software solution, but distributing load is its main function, and it can be just used on microservices, but it can also be used on monolithic and service-oriented architecture. On the other hand, if you talk about the API Gateway, so this is a microservice pattern which not only does load balancing, but it can also be used for lookup and can also simplify the client code. So, instead of remembering hundreds and thousands of microservices, client can only remember API Gateway host and the port details. You can also implement authentication, authorization, security and other cross-cutting concern at API Gateway level instead of implementing them on each microservice. So, basically in short, API Gateway does a lot more than a load balancer. The next question is, what is Canary Deployment in microservices? So, Canary Deployment is a software release strategy where a new version of a service is gradually introduced to a small subset of users before a full rollout to the entire user base is done. So, basically this approach aims to minimize the risks associated with deploying new code by allowing for controlled testing and observation in a live environment. The next question is, how would you monitor microservices? So, basically monitoring is a crucial aspect for ensuring the health, performance and overall stability in a microservices where everything is in a distributed system.
[23:48]So, it provides valuable insights to the behavior of individual services and then particular interactions. So, there are a few steps through which you can monitor the microservices.
[24:01]So, the first step over here is distributed tracing. So, now using distributed tracing, you can track the flow of requests across multiple services in a distributed system. So, this helps identify performance bottlenecks, pinpoint the root cause of errors, and understand the overall request journey. So, if you talk about the tools that can be used for distributed tracing, so here you have the tools such as Jaeger and Zipkin. The second technique or the second step over here is metrics collection. So, basically over here you can collect key performance indicators or KPIs, such as response time, error rates, throughput, and resource utilization, like CPU and memory, for each particular microservice. Over here, you can use tools such as Prometheus. So, Prometheus is a very open source monitoring and alerting system that collects metrics including various sources, such as applications, operating systems, and cloud infrastructure. And the third step is visualization and alerting. So, over here you can visualize collected metrics and tracing data using dashboards and create alerts to notify teams of critical issues. So, the popular tools that are used in this particular step is Grafana and Kibana.
[25:31]The next question over here is, what are DDD principles in microservices? So, basically DDD stands for Domain-Driven Design. So, this is a software development approach that emphasizes on creating software models that align with the business domain. So, when applied to microservices, DDD principles can help structure and organize services effectively. So, if you talk about the DDD principles, so the first point over here is the Bounded Contexts. So, a clearly defined boundary within a specific model and a terminology is applied in microservices. So, each microservices should represent a bounded context, encapsulating a specific business domain or a sub-domain. So, this promotes loose coupling and independent development.
[26:26]The second principle is ubiquitous language. So, over here you have a shared vocabulary between business experts and developers, and this ensures clear communication and understanding of the domain. So, for a microservice application, you have consistent terminology across teams and services, and this prevents ambiguity and improves the collaboration. And the third principle is aggregates. So, basically an aggregate is a cluster of associated objects that are treated as a single unit for data updates. So, for a microservice application, aggregates help maintain data consistency within a bounded context. So, by applying these DDD principles, you can create a more cohesive and maintainable microservices architecture that aligns with the business domain. The next question is, what are sidecars in microservices? So, the sidecar pattern is a design pattern in microservices architecture where a lightweight helper container runs alongside the main application container within the same deployment unit, which is basically a typical Kubernetes pod. So, now what are the responsibilities or the uses of sidecars in microservices?
[27:52]The first use is monitoring and logging. The second use is network traffic management.
[28:03]The third use is security, and the fourth use is the feature delivery. For example, in a payment service, a sidecar container could encrypt sensitive data, collect and forward logs, and handle network traffic.
[28:26]The next question is, what are the best practices for deploying microservices in a production environment?
[28:39]So, deploying microservices effectively in a production environment requires careful planning and a robust approach. And now if you talk about the best practices over here, the first practice is containerization. So, here you package each microservice into its own container, like by using a Docker, and this provides isolation, portability, and consistency across different environments. After that, the second point in containerization is the orchestration. So, here utilizing container orchestration platform like Kubernetes to manage the deployment, scaling, and networking of containers.
[29:20]The second best practice over here is CICD or continuous integration and continuous delivery. So, over here you automate the build, test and deployment process using the CICD pipelines. So, this ensures faster and more frequent releases with reduced manual effort. The third principle is deployment strategies. So, there are a few deployment strategies that you can follow for microservices architecture, like blue green deployments, Canary releases, AB testing and so on. The fourth best practice is monitoring and observability.
[30:03]So, here you implement centralized logging to collect and analyze logs from all of the microservices. So, this helps in troubleshooting issues and identifying the performance bottlenecks. Then you have the service discovery. So, this enables services to dynamically discover and locate each other within the network. So, this enhances the flexibility and simplifies the service interaction. And last but not the least, you have security. So, in security you have concepts like authentication, authorization, data encryption, regular security audits, and so on. So guys, with this we have come to the end of this session on microservices interview questions. I hope you guys have enjoyed this session. If at all you have any doubts or queries related to this session, then you can write them in the comment section, and we will try to resolve them as soon as possible. So guys, thank you so much for being with us and I wish you all the very best.
