Microservices Interview Questions and Answers (2023)

The main components for a Microservice Architecture are:

• Containers, Clustering, and Orchestration
• IaC [Infrastructure as Code Conception]
• Cloud Infrastructure
• API Gateway
• Enterprise Service Bus
• Service Delivery

• Wiremock
• Docker
• Hysrix

Monolithic architecture is like a big container in which all the software components of an application are clubbed inside a single package.

Under a microservice architecture, an application is simplified into multiple modules that independently perform the single precise standalone task:

Are fragmented into loosely coupled various modules, each of which performs a distinct function. It can be or are distributed across clouds and data centers. Implement each module as an independent service/process which can be replaced, updated, or deleted without disrupting the rest of the application. Under microservice architecture, an application can grow along with its requirements.

Microservices have the following main features:

• Multiple Individually Deployable Components.
• Service Distribution based on Business Capabilities.
• Decentralized Data Management.
• DevOps Implementation.
• Technical Independence.
• Hidden Component Complexity to avoid unnecessary microservices dependencies.

Advantages:

• Improved Scalability
• Fault Isolation
• Localized Complexity
• Increased Agility
• Simplified Debugging & Maintenance
• Better correspondence of developers with business users.
• Smaller development teams
• Better scope for technology upgradation.

Disadvantages:

• Complicated as a whole.
• Requires accurate pre-planning
• Modular dependencies are hard to calculate.
• Less control over third party applications
• Modular Interdependencies are challenging to track.
• More opportunities for malicious intrusions.
• Complete end-to-end testing is difficult.
• Deployment Challenges.

Spring cloud is an Integration software that integrates with external systems. It allows microservices framework to build applications which perform restricted amounts of data processing.

Reports and dashboards are mainly used to monitor and upkeep microservices. There are multiple tools that help to serve this purpose. Reports and dashboards can be used to:

find out which microservices expose what resources. find out the services which are impacted whenever changes in a component occur. provide an easy point which can be accessed whenever documentation is required. Versions of the components which are deployed. To obtain a sense of maturity and compliance from the components.

The challenges in Microservice can be both technical as well as functional.

From the point of business, the main challenges are:

• Require heavy investment
• Heavy Infrastructure Setup
• Excessive Planning for managing operations overhead
• Staff Selection and maintenance.

From a technical standpoint –

• Communication between different microservices in the application.
• Component automation
• Application maintenance
• Configuration Management
• Heavy Operations Overhead
• Deployment Challenges
• Testing and Debugging Challenges

Microservice architecture is best suited for desktop, web, mobile devices, Smart TVs, Wearable, etc.

• Services split up and organized around business functionality.
• Separate modules handled and owned by different development teams.
• Decentralized Framework.
• Maintenance of respective modules by respective development teams.
• Separate modules may be maintained by different databases.
• Modules in a Microservice Architecture are separately deployable. They can be updated, enhanced, or deleted without disrupting the entire architecture.
• Real-time monitoring of the application.

• Multiple Service Instance per Host: Run single or multiple service instances of the application on single/multiple physical/virtual hosts.
• Service Instance per Host: Run a service instance per host.
• Service Instance per Container: Run each service instance in its respective container.
• Serverless Deployment: Package the service as a ZIP file and upload it to the Lambda function. The Lambda function is a stateless service that automatically runs enough micro-services to handle all requests.

Representational State Transfer (REST)/RESTful web services is an architectural style that helps computer systems to communicate over the internet. These web services make microservices easier to understand and implement.

In Microservice architecture tests are divided into three broad categories:

• At the bottom level test, we can perform a general test like performance and unit tests. These kinds of tests are entirely automated.
• At the middle level, we can perform exploratory tests like the stress tests and usability tests.
• At the top level, we can conduct acceptance tests which are mostly fewer in numbers. It also helps stakeholders to know about different software features.

Client certificates is a digital certificate used to make authenticated requests to a remote server. It is termed as a client certificate.

It is an open source tool which allows testing interactions between service providers and consumers. However, it is separated from the contract made. This increases the reliability of the Microservices applications.

OAuth means open authorization protocol. This protocol allows you to access the client applications on HTTP for third-party providers GitHub, Facebook, etc. It helps you to share resources stored on one site with another site without the need for their credentials.

End-to-end testing validates every process in the workflow is functioning correctly. It also ensures that the system works together as a whole and satisfies all requirements.

Containers are easiest and effective method to manage the microservice based application. It also helps you to develop and deploy individually. Docker also allows you to encapsulate your microservice in a container image along with its dependencies. Microservice can use these elements without additional efforts.

Semantic Monitoring or Synthetic Monitoring is running a subset of the application’s automated tests against the live production system. These results are monitored, and alerts are generated in case of failures. Semantic Monitoring approaches microservice monitoring from the business transaction perspective. Instead of monitoring each component, its semantic monitoring ascertains how well the transaction performs for business and the users. It also detects the faulty service layer and the corresponding microservice instance, all at the same flow. This approach allows for faster triaging and reduces the meantime to repair.

CDC is Consumer-Driven Contract. It is a pattern for developing Microservices so that external systems can use them.

Docker offers a container environment which can be used to host any application. This software application and the dependencies that support it which are tightly-packaged together.

Reactive Extensions is also called Rx. It is a design pattern which allows collecting results by calling multiple services and then compile a combined response. Rx is a popular tool in distributed systems which works exactly opposite to legacy flows.

Continuous monitoring is a method which is used for searching compliance and risk issues associated with a company’s operational and financial environment. It contains human, processes, and working systems which support efficient and actual operations.

It depends upon your project needs. However, in most cases, developers use HTTP/REST with JSON or Binary protocol. However, they can use any communication protocol.

• Monolithic Architecture: In this type of architecture, different components of an application like UI, business logic, data access layer are combined into a single platform or program.
• SOA (Service Oriented Architecture): In this architecture, individual components are loosely coupled and perform a discrete function. There are two main roles – service provider and service consumer. In SOA type, modules can be integrated and reused, making it flexible and reliable.
• Microservices Architecture: It is a type of SOA in which a series of autonomous components are built and combined to make an app. These components are integrated using APIs. This approach focuses on business priorities and capabilities and offers high agility, i.e. each component of the app can be built independently of the other.

Coupling: it is the relationship between module A and another module B. Any module can be highly coupled (highly dependent), loosely coupled and uncoupled with other modules. The best coupling is loose coupling achieved through interfaces.

Cohesion: it is the relationship between 2 or more parts within a module. If a module has high cohesion, it means the module can perform a certain task with utmost efficiency on its own, without communication with other modules. High cohesion enhances the functional strength of a module.

Spring cloud can solve the following problems:

• Network issues, latency overhead, bandwidth issues, security issues and other issues with distributed systems
• Redundancy issues that occur in distributed systems.
• Balancing the distribution of load between resources like network links, CPU, clusters etc.
• Performance issues because of operational overheads.
• Service discovery issues to ensure smooth communication between services in a cluster.

Distribution transaction has two or more network hosts that are engaged. Transactions are handled by a transaction manager that takes care of developing and handling transactions. If the transaction involves more than one peer, transaction managers of each peer communicate with each other using subordinate or superior relationships.

Same way, resources are handled by the resource manager that also coordinates with the distributed transaction coordinator for transaction atomicity and isolation.

It is a testing technique used to test the entire flow of an application using a business transaction. Since several components are involved in microservices architecture, these tests can cover the gaps during a unit or integration testing. It also gives end to end confidence, ensures that the network parameters are appropriately configured and helps microservices to evolve.

The pyramid helps maximize automation at all levels of testing, i.e. unit testing, service level testing, UI testing. The pyramid indicates that while unit tests are faster and more isolated, UI tests, which are at the highest level, take time and focus on integration.

Add spring-boot-starter-security in the file pom.xml. Create a Spring config class that will override the required method while extending the WebSecurityConfigurerAdapter to achieve security in the application.

Spring Boot Application Login can be configured by specifying the logging.level in the application. Properties file. It is usually pre-configured as console output.

While building a distributed system, there are a few problems that are encountered. They are Configuration Management, Service Discovery, Circuit breakers, and distributed sessions. Spring Boot is a collection of tools that provides solutions to such commonly encountered problems.

The actuator brings in production-ready features into an application. It is mainly used to expose operational information about the running application’s health, metrics, info, dump, env, etc. It uses HTTP endpoints or JMX beans to interact with it.

Contract Testing ensures that the explicit and implicit contracts of a microservice architecture work as expected. There are two perspectives to contract to test – Consumer and Provider. The consumer is the [application] entity using the microservice, and the provider is the [application] entity providing the service. Such services work under predefined specifications, and contract testing ensures so.

End-To-End testing of a microservice application ensures that every process in the form is running properly. This validates that the system as a whole is working properly. As the microservices application is built with multiple modules orchestrated dynamically, an end to end testing covers all the gaps between the services.

The steps to an end-to-end microservices testing are:

• Define what you expect from an e2e testing.
• Define the scope of the system to be tested.
• Perform authentication in a test environment.
• Choose a testing framework that addresses most of the issues.
• Test Asynchronous flows.
• Automate testing.

A Mock is generally a dummy object where certain features are set into it initially. Its behavior mainly depends on these features, which are then tested.

A Stub is an object that helps in running the test. It functions in a fixed manner under certain conditions. This hard-coded behavior helps the stub to run the test.

Canary releasing is a technique by which new software versions are introduced by rolling out the updated version to a small subset of users before rolling it out to the entire infrastructure and making it available to everybody. This technique is so-called because it is based on canary releases in coal mines to alert miners when the toxic gases reach dangerous levels.

Two-factor authentication calls for a second round of authentication to an account login process. Entering a username – password is a one-factor authentication. Username – Password authentication and then say mobile number or a secret key authentication can be considered as a two - factor authentication.

The different types of credentials for two-factor authentication can be:

• Something you know - A PIN, password or a pattern
• Something you have – ID, ATM No., Phone No, or an OTP
• Something you are – Your Biometrics.

A Client Certificate is a digital certificate that is used by client systems to make authenticated requests to a remote server. It plays a key role in many mutual authentication designs, providing strong assurances of a requester’s identity.

NDT or Non-Deterministic are unreliable tests. Such tests sometimes pass and sometimes fail. When these tests fail, they are re-run to give. Non-Determinism from tests can be eliminated in the following ways:

• Quarantine
• Asynchronous
• Remote Services
• Isolation
• Time
• Resource Leaks

Reactive Extensions is a design approach through which results are collected by calling multiple services in order to compile a combined response. Also known as Rx, these calls can be synchronous or asynchronous.

Eureka is alternatively known as the Netflix Service Discovery Server. It uses Spring Cloud and is not heavy on the application development process.

The server-side load balancing can be done by using Netflix Zuul. It is also known as a JVM based router.

Hystrix is an error tolerance and latency library. Hystrix mainly isolates the access points. It also makes sure that all 3rd Party libraries and services are restricted. Thus, we can use Hystrix to ensure that an application runs efficiently and avoids the kind of failures that occur in distributed systems.

Spring Batch is an open-source framework for batch processing – execution of a series of jobs. Spring Batch provides classes and APIs to read/write resources, transaction management, job processing statistics, job restart, and partitioning techniques to process high volume data.

The Tasklet is a simple interface with one method to execute. A tasklet can be used to perform single tasks like running queries, deleting files, etc. In Spring Batch, the tasklet is an interface that can be used to perform unique tasks like clean or set up resources before or after any step execution.

Spring Batch uses a ‘Chunk Oriented’ processing style within its most common implementation. Chunk Oriented Processing refers to reading the data one at a time and creating chunks that will be written out, within a transaction boundary.

If an exception occurs while processing an HTTP request, you need to catch the exception in your controller or service and return an appropriate ResponseEntity manually. Here are some thumb rules for exception handling.

• Add @ResponseStatus for exceptions that you write.
• For all other exceptions, implement an @ExceptionHandler method on a @ControllerAdvice class or use an instance of SimpleMappingExceptionResolver.
• For Controller specific exceptions, add @ExceptionHandler methods to your controller.
• Point to be noted is that @ExceptionHandler methods on the controller are always selected before those on any @ControllerAdvice instance. It is undefined in what order ControllerAdvices are processed.

Considering the microservice architecture concept, each microservice needs to have an interface. Based on the principles of open networking of the Web, RESTful APIs provide the most logical model for building interfaces between the various components of the microservices architecture.

Microservices can communicate with each other through:

• HTTP for traditional Request-Response.
• Websockets for streaming.
• Brokers or Server Programs running Advanced Routing Algorithms.
• For message brokers, RabbitMQ, Nats, Kafka, etc., can be used, each built for a particular message semantic. Another way is to use Backend As A Service like Space Cloud, which automates the entire backend.

Microservices Application is a collection of smaller, independent, functional modules that may be developed in different programming languages, have different data sources, and run on different operating systems. This makes testing of the microservices as a whole a very tough task. The different pieces/modules need to be tested independently. There are three common procedures for this.

• Code Scanning: In order to ensure that every line of code is bug-free and can be replicated.
• Flexibility: The security protocols should be flexible as per the requirements of the system.
• Adaptability: The security protocols should be adaptable to the malicious intrusions.

Idempotence refers to the repeated performing of a task even though the end result remains the same. It is used mostly as a data source or a remote service in a way that when it receives the instruction more than once, it processes the instruction only once.

Reports and Dashboards are generally used to monitor a system. For microservices Reports and Dashboards help to:

• Find which microservice support which resource.
• Find out the services that are impacted whenever changes in components are made/occur.
• Provide an easy point of access for documentation purposes.
• Review versions of the deployed components.
• Obtain compliance from the components.

The main tools that can be used to build/manage a microservice architecture are:

• MongoDB: It is a document-based open-source distributed database. Here data is stored in JSON format with a different structure for different documents. It also supports a lot of programming languages like C, C++, C#, PERL, PHP, Python, Java, Ruby, Scala, etc.
• Elasticsearch: It is a full-text search engine.
• KAFKA: It is an event queue system. All transactions are processed via the event queue, thus avoiding the web like random interactions between different services. Kafka renders a microservice architecture robust and clean.
• JENKINS: It is an automation tool that enables Continuous Integration and Continuous Development. It supports many plugins and easily integrates with almost every tool.
• DOCKER: The application development environment and application deployment environment are bound to vary in many aspects. This gives rise to deployment issues. Docker provides a static background for the application to run, thus avoiding deployment issues.
• KUBERNETES: With thousands of services running in an application, Kubernetes, as an engine orchestrates the entire process.
• JAEGER: It is an open-source end to end distributed tracing tool. Jaeger monitors distributed transactions, helps in performance optimization, and finds the dependencies between services. It also gives the root cause analysis.
• FLUENT: In a multiservice architecture, where all the different systems are managed via different programming languages, different databases, and run in different operating systems, logging in, and keeping track of it is a significant issue. Fluentd provides a single logging layer and simplifies this issue. Logs can be also be collected and aggregated onto a data source.
• PROMETHEUS: It is a monitoring tool, which helps to check if all services are working fine when the application is deployed. It is a time-series data store. It collects metrics from an application and displays it in a graphical format.
• Grafana: Grafana provides analytics and monitoring into different visualization formats like graphs, charts, tables, etc.
• NGINX: It acts as a reverse proxy. It acts as a single point entry through which all the API calls are made.

Each microservice owning its database is an independently deployable program. This enables the creation of State Machines by which we can specify different states and events for a particular microservice.

• Failure to outline the main challenges.
• I am rewriting already existing programs.
• Vague definitions of responsibilities, timeline, and boundaries.
• Failure to identify and implement automation.

WebMvcTest Annotation is used for unit testing Spring MVC Applications, where the test objective is to focus on Spring MVC Components.

Ex: @WebMvcTest(value = ToTestController.class, secure = false)

In the above example, the intention is to launch the ToTestController. All other controllers and mappings will not be launched when this unit test is executed.

Netflix, Paypal, Amazon, eBay, Twitter, and many other large-scale websites have started as monolithic and evolved into a microservices architecture.

Spring boot is a major topic under the umbrella of microservices interview questions. With the new functionalities that have been added, Spring got more complex. Whenever you are starting a new project it is mandatory to add a new build path or Maven dependencies. In short, you will need to do everything from scratch. Spring Boot is the solution that will help you to avoid all the code configurations. Explaining by a real time example is better while answering this common microservices interview question. If you are cooking a dish, the ingredients can be considered to be Spring. While Spring Boot is the completely cooked recipe.

Whenever you are creating a Java Application, deployment can be done by 2 methods:

By using an application container that is external You can also embed the container inside your jar file. Spring Boot contains Jetty, Tomcat and undertow servers, all of which are embedded.

Jetty – Used in a wide number of projects, Eclipse Jetty can be embedded in frameworks and application servers, tools as well as clusters.

Tomcat – Apache Tomcat is an open source JavaServer pages implementation which works well with embedded systems.

Undertow – A flexible and prominent web server that uses small single handlers to develop a web server.

There are multiple ways to set up service discovery. For this answer let's choose Eureka by Netflix. It is a hassle-free procedure that does not weigh much on the application. Plus, it supports numerous types of web applications.

Eureka configuration involves 2 steps – Client configuration and server configuration. Client configuration can be done easily by using the property files. In the classpath, Eureka searches for eureka-client.properties. It also searches for overrides caused by the environment in property files that are environment-specific.

For server configuration, you have to configure the client first. Once that is done, the server fires up a client which is used to find other servers. The Eureka server, by default, uses the Client configuration to find the peer server.

Not only on development, but mistakes also lies on the process side often. And any experienced interviewer will have this under the queue for microservices interview questions. Some of the common mistakes are

Often the developer fails to outline the current challenges. Rewriting the programs that are already existing. Responsibilities, timeline, and boundaries not clearly defined. Failing to implement and figure out the scope of automation from the very beginning.

A central pattern usually seen in domain driven design, Bounded Context is the main focus of the strategic design section of DDD. It is all about a deal with large teams and models.. DDD works with large models by disintegrating them into multiple bounded context. While it does that, it also explains the relationship between them explicitly.

Assuming that the majority of providers using microservices architecture,

One can scale the system by increasing the number of instances of service by bringing up more containers. One can also apply to cache at microservice layer which can be easy to manage as an invalidation of the cache can be done very easily as the microservice will be the single source of truth. Caching can also be introduced at the API Gateway layer where one can define caching rules like when to invalidate the cache. One can also shut down some containers when the requirement is less. That is, scale down.

The Twelve-Factor App is a recent methodology (and/or a manifesto) for writing web applications which run as a service.

Codebase - One codebase, multiple deploys. This means that we should only have one codebase for different versions of a microservices. Branches are ok, but different repositories are not.

Dependencies- Explicitly declare and isolate dependencies. The manifesto advises against relying on software or libraries on the host machine. Every dependency should be put into pom.xml or build.gradle file.

Config- Store config in the environment. Do never commit your environment-specific configuration (most importantly: password) in the source code repo. Spring Cloud Config provides server and client-side support for externalized configuration in a distributed system. Using Spring Cloud Config Server you have a central place to manage external properties for applications across all environments.

Backing services - Treat backing services as attached resources. A microservice should treat external services equally, regardless of whether you manage them or some other team. For example, never hard code the absolute url for dependent service in your application code, even if the dependent microservice is developed by your own team. For example, instead of hard coding url for another service in your RestTemplate, use Ribbon (with or without Eureka) to define the url:

Release & Run - Strictly separate build and run stages. In other words, you should be able to build or compile the code, then combine that with specific configuration information to create a specific release, then deliberately run that release. It should be impossible to make code changes at runtime, for e.g. changing the class files in tomcat directly. There should always be a unique id for each version of release, mostly a timestamp. Release information should be immutable, any changes should lead to a new release.

Processes - Execute the app as one or more stateless processes. This means that our microservices should be stateless in nature, and should not rely on any state being present in memory or in the filesystem. Indeed the state does not belong in the code. So no sticky sessions, no in-memory cache, no local filesystem storage, etc. Distributed cache like memcache, ehcache or Redis should be used instead

Port Binding - Export services via port binding. This is about having your application as standalone, instead of relying on a running instance of an application server, where you deploy. Spring boot provides a mechanism to create a self-executable uber jar that contains all dependencies and embedded servlet container (jetty or tomcat).

Concurrency - Scale-out via the process model. In the twelve-factor app, processes are a first-class citizen. This does not exclude individual processes from handling their own internal multiplexing, via threads inside the runtime VM, or the async/evented model found in tools such as EventMachine, Twisted, or Node.js. But an individual VM can only grow so large (vertical scale), so the application must also be able to span multiple processes running on multiple physical machines. Twelve-factor app processes should never write PID files, rather it should rely on operating system process manager such as systemd - a distributed process manager on a cloud platform.

Disposability - The twelve-factor app’s processes are disposable, meaning they can be started or stopped at a moment’s notice. This facilitates fast elastic scaling, rapid deployment of code or config changes, and robustness of production deploys. Processes should strive to minimize startup time. Ideally, a process takes a few seconds from the time the launch command is executed until the process is up and ready to receive requests or jobs. Short startup time provides more agility for the release process and scaling up; and it aids robustness because the process manager can more easily move processes to new physical machines when warranted.

Dev/Prod parity - Keep development, staging, and production as similar as possible. Your development environment should almost identical to a production one (for example, to avoid some “works on my machine” issues). That doesn’t mean your OS has to be the OS running in production, though. Docker can be used for creating logical separation for your microservices.

Logs - Treat logs as event streams, sending all logs only to stdout. Most Java Developers would not agree to this advice, though.

Admin processes - Run admin/management tasks as one-off processes. For example, a database migration should be run using a separate process altogether.

A good, albeit non-specific, rule of thumb is as small as possible but as big as necessary to represent the domain concept they own said by Martin Fowler

Size should not be a determining factor in microservices, instead bounded context principle and single responsibility principle should be used to isolate a business capability into a single microservice boundary.

Microservices are usually small but not all small services are microservices. If any service is not following the Bounded Context Principle, Single Responsibility Principle, etc. then it is not a microservice irrespective of its size. So the size is not the only eligibility criteria for a service to become microservice.

In fact, size of a microservice is largely dependent on the language (Java, Scala, PHP) you choose, as few languages are more verbose than others.

In Orchestration, we rely on a central system to control and call other Microservices in a certain fashion to complete a given task. The central system maintains the state of each step and sequence of the overall workflow. In Choreography, each Microservice works like a State Machine and reacts based on the input from other parts. Each service knows how to react to different events from other systems. There is no central command in this case.

Orchestration is a tightly coupled approach and is an anti-pattern in a microservices architecture. Whereas, Choreography’s loose coupling approach should be adopted where-ever possible.

Spring Boot along with Spring Cloud is a very good option to start building microservices using Java language. There are a lot of modules available in Spring Cloud that can provide boiler plate code for different design patterns of microservices, so Spring Cloud can really speed up the development process. Also, Spring boot provides out of the box support to embed a servlet container (tomcat/jetty/undertow) inside an executable jar (uber jar), so that these jars can be run directly from the command line, eliminating the need of deploying war files into a servlet container.

You can also use Docker container to ship and deploy the entire executable package onto a cloud environment. Docker can also help eliminate "works on my machine" problem by providing logical separation for the runtime environment during the development phase. That way you can gain portability across on-premises and cloud environment.

ACID is an acronym for four primary attributes namely atomicity, consistency, isolation, and durability ensured by the database transaction manager.

Atomicity- In a transaction involving two or more entities, either all of the records are committed or none are.

Consistency- A database transaction must change affected data only in allowed ways following specific rules including constraints/triggers etc.

Isolation- Any transaction in progress (not yet committed) must remain isolated from any other transaction.

Durability- Committed records are saved by a database such that even in case of a failure or database restart, the data is available in its correct state.

In a distributed system involving multiple databases, we have two options to achieve ACID compliance:

• One way to achieve ACID compliance is to use a two-phase commit (a.k.a 2PC), which ensures that all involved services must commit to transaction completion or all the transactions are rolled back.
• Use eventual consistency, where multiple databases owned by different microservices become eventually consistent using asynchronous messaging using messaging protocol. Eventual consistency is a specific form of weak consistency.

2 Phase Commit should ideally be discouraged in microservices architecture due to its fragile and complex nature. We can achieve some level of ACID compliance in distributed systems through eventual consistency and that should be the right approach to do it.

When you are implementing microservices architecture, there are some challenges that you need to deal with every single microservices. Moreover, when you think about the interaction with each other, it can create a lot of challenges. As well as if you pre-plan to overcome some of them and standardize them across all microservices, then it happens that it also becomes easy for developers to maintain services.

Some of the most challenging things are testing, debugging, security, version management, communication ( sync or async ), state maintenance etc. Some of the cross-cutting concerns which should be standardized are monitoring, logging, performance improvement, deployment, security etc.

An API Gateway is a service which sits in front of the exposed APIs and acts as an entry point for a group of microservices. Gateway also can hold the minimum logic of routing calls to microservices and also an aggregation of the response.

• A gateway can also authenticate requests by verifying the identity of a user by routing each and every request to authentication service before routing it to the microservice with authorization details in the token.
• Gateways are also responsible to load balance the requests.
• API Gateways are responsible to rate limit a certain type of request to save itself from blocking several kinds of attacks etc.
• API Gateways can whitelist or blacklist the source IP Addresses or given domains which can initiate the call.
• API Gateways can also provide plugins to cache certain type of API responses to boost the performance of the application.

In the microservices architecture, it is possible that due to service boundaries, a lot of times you need to update one or more entities on the state change of one of the entities. In that case, one needs to publish a message and new event gets created and appended to already executed events. In case of failure, one can replay all events in the same sequence and you will get the desired state as required. You can think of event sourcing as your bank account statement.

You will start your account with initial money. Then all of the credit and debit events happen and the latest state is generated by calculating all of the events one by one. In a case where events are too many, the application can create a periodic snapshot of events so that there isn’t any need to replay all of the events again and again.

There are many useful scenarios for leveraging the power of JWT-

Authentication- Authentication is one of the most common scenarios for using JWT, specifically in microservices architecture (but not limited to it). In microservices, the oauth2 server generates a JWT at the time of login and all subsequent requests can include the JWT AccessToken as the means for authentication. Implementing Single Sign-On by sharing JWT b/w different applications hosted in different domains.

Information Exchange - JWT can be signed, using public/private key pairs, you can be sure that the senders are who they say they are. Hence JWT is a good way of sharing information between two parties. An example use case could be -

Generating Single Click Action Emails e.g. Activate your account, delete this comment, add this item to favorites, Reset your password, etc. All required information for the action can be put into JWT.

Timed sharing of a file download using a JWT link. Timestamp can be part of the claim, so when the server time is past the time-coded in JWT, the link will automatically expire.

Continuous Integration (CI) is a development practice that requires developers to integrate code into a shared repository several times a day. Each check-in is then verified by an automated build, allowing teams to detect problems early.

Blue-green deployment is a technique that reduces downtime and risk by running two identical production environments called Blue and Green. At any time, only one of the environments is live, with the live environment serving all production traffic. For this example, Blue is currently live and Green is idle.

As you prepare a new version of your software, deployment and the final stage of testing takes place in the environment that is not live: in this example, Green. Once you have deployed and fully tested the software in Green, you switch the router so all incoming requests now go to Green instead of Blue. Green is now live, and Blue is idle.

This technique can eliminate downtime due to application deployment. In addition, blue-green deployment reduces risk: if something unexpected happens with your new version on Green, you can immediately roll back to the last version by switching back to Blue.

Smart endpoints just meaning actual business rules and any other validations happens behind those endpoints which are not visible to anyone to the consumers of those endpoints think of it as a place where actual Magic happens.

Dumb pipelines means any communication means where no further actions e.g validations are taken place, it simply carries the data across that particular channel and it may also be replaceable if need be. The infrastructure chosen is typically dumb (dumb as in acts as a message router only). It just means that routing is the only function the pipes should be doing.

• Developers practicing continuous integration merge their changes back to the main branch as often as possible. By doing so, you avoid the integration hell that usually happens when people wait for release day to merge their changes into the release branch.
• Continuous delivery is an extension of continuous integration to make sure that you can release new changes to your customers quickly in a sustainable way. This means that on top of having automated your testing, you also have automated your release process and you can deploy your application at any point of time by clicking on a button.
• Continuous deployment goes one step further than continuous delivery. With this practice, every change that passes all stages of your production pipeline is released to your customers. There's no human intervention, and only a failed test will prevent a new change to be deployed to production.

Serverless refers to a model where the existence of servers is hidden from developers. It means you no longer have to deal with capacity, deployments, scaling and fault tolerance and OS. It will essentially reducing maintenance efforts and allow developers to quickly focus on developing codes.

Examples are:

Amazon AWS Lambda, Azure Functions

GraphQL and microservices are a perfect fit, because GraphQL hides the fact that you have a microservice architecture from the clients. From a backend perspective, you want to split everything into microservices, but from a frontend perspective, you would like all your data to come from a single API. Using GraphQL is the best way I know of that lets you do both. It lets you split up your backend into microservices, while still providing a single API to all your application, and allowing joins across data from different services.

You should always note that YAML is also known as an individual legible language. Many experts also call it a language that can result in the sterilization of data. Hence, basically, it denotes that it can be used to cleanse data. This has a great advantage on the Microservices network. As compared to the other files of various properties, the YAML file is said to be more organized in manner. On the other hand, it is also less confusing and hence it provides easy accessibility to a variety of web developers. However, it is also vital to note that YAML possesses the hierarchical form of data that has played an essential role in the swift development of various applications.