Question: What do you understand by Microservices?

Answer: Microservices is an architectural style of developing a large scale application

in the form of discrete modules which works independently of each other but when
combine together work as whole account for the entire business. Generally they are
divided into business module or we can say module domain.
It is a service oriented architecture pattern where application are built as a collection of
smaller independent units. It divides the application into modules where each module is
independently deployed and loosely coupled.

What are the features of Microservices?

----Raj----

Key Features of Microservices Architecture with Real-World Examples

Microservices architecture is a popular architectural style that breaks down a large application into
smaller, independent services. This approach offers several benefits, including improved scalability,
flexibility, and maintainability.

Here are some key features of microservices architecture:

1. Small, Independent Services:

 Example: In an e-commerce application, you might have separate microservices for product
catalog, user authentication, order processing, and payment processing.

 Benefit: Each service can be developed, deployed, and scaled independently, allowing for faster
development and deployment cycles.

2. Loose Coupling:

 Example: The product catalog service might not need to know the internal implementation
details of the order processing service. They communicate through well-defined APIs.

 Benefit: Changes to one service have minimal impact on others, reducing the risk of cascading
failures.

3. Organized Around Business Capabilities:

 Example: A banking application might have microservices for accounts, loans, and transactions,
each responsible for a specific business domain.

 Benefit: Aligning services with business capabilities improves team autonomy and focus.

4. Distributed Governance:

 Example: Different teams can use different technologies and programming languages for their
microservices.
  Benefit: Teams can choose the best tools for the job, leading to increased innovation and
productivity.

5. Decentralized Data Management:

 Example: Each microservice can have its own database, tailored to its specific needs.

 Benefit: This allows for flexibility in data storage and retrieval, and avoids vendor lock-in.

6. API-First Design:

 Example: Microservices communicate through well-defined APIs, such as REST or gRPC.

 Benefit: This promotes clear boundaries between services and enables easier integration with
other systems.

7. Continuous Delivery:

 Example: Each microservice can be deployed independently, allowing for frequent releases and
faster time to market.

 Benefit: This enables rapid iteration and continuous improvement.

8. Fault Isolation:

 Example: If one microservice fails, it doesn't necessarily bring down the entire application.

 Benefit: This improves the overall system's reliability and resilience.

9. Scalability:

 Example: You can scale individual microservices independently, based on their specific needs.

 Benefit: This allows for efficient resource utilization and cost optimization.

By understanding these key features and applying them effectively, you can build robust, scalable, and
maintainable microservices applications.
  Decoupling – Services within a system are largely decoupled. So the application
as a whole can be easily built, altered, and scaled
 Componentization – Microservices are treated as independent components that
can be easily replaced and upgraded
 Business Capabilities – Microservices are very simple and focus on a single
capability
 Autonomy – Developers and teams can work independently of each other, thus
increasing speed
 Continous Delivery – Allows frequent releases of software, through systematic
automation of software creation, testing, and approval
 Responsibility – Microservices do not focus on applications as projects. Instead,
they treat applications as products for which they are responsible
 Decentralized Governance – The focus is on using the right tool for the right
job. That means there is no standardized pattern or any technology
pattern. Developers have the freedom to choose the best useful tools to solve
their problems
 Agility – Microservices support agile development. Any new feature can be
quickly developed and discarded again

List down the advantages of Microservices Architecture.

 Follow the single responsibility principle
 Failure in one service will not impact other
 Highly demanding services can be deployed on multiple server to enhance performance that will
be difficult with single monolithic service.
 Flexibility of choosing the technology
 Easy to deploy and maintain
 Easy to understand since they represent the small business units.
 Flexible and easy to test

What are the Disadvantages?

 These are less stable then monolithic services because in monolithic services we deploy single
services over sever and check the configuration for that one only, but here we have number of
independent services and each dependent service will have to be check before testing can
occur.
 Here we have separate data store for each service so it would be very difficult to maintain
transactions here.
 These can be less secure compared to monolithic services because services communicate with
each other which gives the chance to hackers to penetrate the system.

What is monolithic architecture?

Monolithic architecture is a big container where all software component are clubbed together as a
single package.

Here we can see that we have clubbed search, payments & Ratings components into a single application
means the code for all these functionalities are on the same server. Now the problem is if we have to
enhance the performance of search module then we can’t deploy it independently on multiple servers,
we have to deploy whole application on each server.
Microservices Monolithic Architecture

Every unit of the entire application should be the A single code base for all business goals
smallest, and it should be able to deliver one
specific business goal.

Service Startup is relatively quick Service startup takes more time

Fault isolation is easy. Even if one service goes Fault isolation is difficult. If any specific feature is
down, other can continue to function. not working, the complete system goes down. In
order to handle this issue, the application needs
to re-built, re-tested and also re-deployed.

All microservices should be loosely coupled so Monolithic architecture is tightly coupled.

that changes made in one does not affect the Changes in one module of code affect the other
other.

Businesses can deploy more resources to Since services are not isolated, individual
services that are generating higher ROI resource allocation not possible

More hardware resources could be allocated to Application scaling is challenging as well as

the service that is frequently used. In the e- wasteful.
commerce example above, more number of users
check the product listing and search compared to
payments. So, more resources could be allocated
to the search and product listing microservice.

Microservices always remains consistent and Development tools get overburdened as the
continuously available. process needs to start from the scratch.

Data is federated. This allows individual Data is centralized.

Microservice to adopt a data model best suited for
its needs.

Small Focused Teams. Parallel and faster Large team and considerable team management
development effort is required

Change in the data model of one Microservice Change in data model affects the entire database
does not affect other Microservices.
 Interacts with other microservices by using well- Not applicable
defined interfaces

Microservices work on the principle that focuses Put emphasize on the entire project
on products, not projects

No cross-dependencies between code bases. One function or program depends on

You can use different technologies for different
Microservices.

What are the main components of Microservices?

 Containers, Clustering, and Orchestration

 Cloud Infrastructure
 API Gateway
 Enterprise Service Bus
 Service Delivery

How does Microservice Architecture work?

Under a microservice architecture, an application is simplified into multiple modules that
independently perform the single precise standalone task: under this architecture an application
can grow along with its requirements

A microservice architecture has the following components:

  Clients – Different users from various devices send requests.
 Identity Providers – Authenticates user or clients identities and issues security
tokens.
 API Gateway – Handles client requests.
 Static Content – Houses all the content of the system.
 Management – Balances services on nodes and identifies failures.
 Service Discovery – A guide to find the route of communication between
microservices.
 Content Delivery Networks – Distributed network of proxy servers and their
data centers.
 Remote Service – Enables the remote access information that resides on a
network of IT devices.

Best Practices of Microservices Architecture

 Separate data store for each Microservice
 Keep code of a similar level of maturity.
 Separate build for each Micro service
 Always treat- sever as stateless.

What are the main challenges in Microservice Deployment?

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

What are the different strategies of Microservices Deployment?

 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: Create serverless functions on Azure.
What is the difference between Monolithic, SOA and Microservices Architecture?

 Monolithic Architecture is similar to a big container wherein all the software

components of an application are assembled together and tightly packaged.
 A Service-Oriented Architecture is a collection of services which communicate
with each other. The communication can involve either simple data passing or it
could involve two or more services coordinating some activity.
 Microservice Architecture is an architectural style that structures an application
as a collection of small autonomous services, modeled around a business
domain.

Microservices Monolithic Architecture

Every unit of the entire application should be the A single code base for all business goals
smallest, and it should be able to deliver one
specific business goal.

Service Startup is relatively quick Service startup takes more time

Fault isolation is easy. Even if one service goes Fault isolation is difficult. If any specific feature is
down, other can continue to function. not working, the complete system goes down. In
order to handle this issue, the application needs
 to re-built, re-tested and also re-deployed.

All microservices should be loosely coupled so Monolithic architecture is tightly coupled.

that changes made in one does not affect the Changes in one module of code affect the other
other.

Businesses can deploy more resources to Since services are not isolated, individual
services that are generating higher ROI resource allocation not possible

More hardware resources could be allocated to Application scaling is challenging as well as

the service that is frequently used. In the e- wasteful.
commerce example above, more number of
users check the product listing and search
compared to payments. So, more resources
could be allocated to the search and product
listing microservice.

Microservices always remains consistent and Development tools get overburdened as the
continuously available. process needs to start from the scratch.

Data is federated. This allows individual Data is centralized.

Microservice to adopt a data model best suited
for its needs.

Small Focused Teams. Parallel and faster Large team and considerable team management
development effort is required

Change in the data model of one Microservice Change in data model affects the entire
does not affect other Microservices. database

Interacts with other microservices by using well- Not applicable

defined interfaces

Microservices work on the principle that focuses Put emphasize on the entire project
on products, not projects

No cross-dependencies between code bases. One function or program depends on

You can use different technologies for different
Microservices.
Parameter SOA Microservices

Design type In SOA, software components are Micro Service is a part of SOA. It is an
exposed to the outer world for usage in implementation of SOA.
the form of services.

Dependency Business units are dependent. They are independent of each other.

Size of the Software size is larger than any The size of the Software is always
Software conventional software small in Microservices

Technology The technology stack is lower compared Microservice technology stack could
Stack to Microservice. be very large

Nature of the Monolithic in nature Full stack in nature

application

Independent and SOA applications are built to perform They are built to perform a single
Focus multiple business tasks. business task.

Deployment The deployment process is time- Deployment is straightforward and

consuming. less time-consuming.

Cost - More cost-effective. Less cost-effective.

effectiveness

Scalability Less compared to Microservices. Highly scalable.

Business logic Business logic components are stored Business logic can live across
inside of single service domain Simple domains enterprise Service Bus like
wire protocols(HTTP with XML JSON) layers between services Middleware
API is driven with SDKs/Clients

What are the challenges you face while working Microservice Architectures?
Developing a number of smaller microservices sounds easy, but the challenges often
faced while developing them are as follows.
  Automate the Components: Difficult to automate because there are a number
of smaller components. So for each component, we have to follow the stages of
Build, Deploy and, Monitor.
 Perceptibility: Maintaining a large number of components together becomes
difficult to deploy, maintain, monitor and identify problems. It requires great
perceptibility around all the components.
 Configuration Management: Maintaining the configurations for the components
across the various environments becomes tough sometimes.
 Debugging: Difficult to find out each and every service for an error. It is essential
to maintain centralized logging and dashboards to debug problems.

How to apply patterns with microservices

There are 3 main decision one must take while deciding to go with microservices architecture pattern.

1. How to decompose application into services

o Decompose by business capability – define services corresponding to business
capabilities
o Decompose by subdomain– define services corresponding to DDD subdomains
2. how to maintain data consistency?
o A key feature of the microservice is the Database per Service pattern. It’s alternative,
the Shared Database pattern is essentially an anti-pattern and best avoided. The
Database per service pattern dramatically changes how you maintain data consistency
and perform queries. You will need to use the Saga pattern.
3 How to perform queries - Another challenge is implementing queries that need to retrieve data
owned by multiple services. The API Composition and Command Query Responsibility
Segregation (CQRS) patterns are used.

When to use monolith instead of microservices?

We should be opting for monolith only or first approach in the following circumstances:

1. Business is not ready to invest in the upfront cost that microservices based applications incur.
2. Inability for business to foresee the value provided by the microservices first approach.
3. Unavailability of suitable manpower to build and run microservices-based applications.
4. Software delivery with tight time constraints: Sometimes monolith helps in entering the market
very quickly.
5. When state of tools and technologies available to support smooth deployment of microservices
application, is a concern.
 When to use microservices instead of monolith?

We should therefore be opting for the microservices first approach when:

1. Modularity and decentralization is an important aspect from the beginning of any project.
2. The application in focus will have high volume transaction or traffic.
3. Preference for long term benefits in comparison to those in the short term.
4. Availability of the right set of people to design, develop and deploy applications quickly in the
initial phase: It has been observed that the initial effort to start a microservices based project is
more in comparison to a monolith one.

What is Domain-Driven Design?

In general terms, Domain is a “sphere of knowledge” around which the application logic revolves. This is
the subject are on which application is intended to apply, A Domain is also called a “problem
space”, so the problem for which we have to design a solution. An application is
developed to apply domain logic of business rules through technology. Here our Domain Driven Design
works which bridge the gap between application developer and domain knowledge experts to create the
same understanding.

DDD focuses on three core principles:

 Focus on the core domain and domain logic.

 Base complex designs on models of the domain.
 Constantly collaborate with domain experts, in order to improve the
application model and resolve any emerging domain-related issues.

What is Ubiquitous language?

it is a common language used by developers and users of a specific domain through which the
domain can be explained easily. Basically here we can say there are some general terms which
domain experts use for each domain , same applies to application developers as well. It is used
to explain the domain to each other.
In DDD, ubiquitous language refers to a language that is shared by all members of a
development team, including developers, domain experts, and stakeholders. This
language is designed to accurately represent concepts, behaviors, and processes
within the specific domain of the software project.
The ubiquitous language has to be crystal clear so that it brings all the team members on the
same page and also translates in such a way that a machine can understand.
What is Coupling and Cohesion?
Coupling – coupling is basically the measurement of dependencies between components. For eg. In
ecommerce it measures how much the Shipping services are dependent on Sales service.

Cohesion – measurement of how the elements inside a module belong to each other.

A good design is always said to have High Cohesion and Low Coupling. When loosely
coupled, a service knows very little about other. This keeps the services intact. In high cohesion,
it becomes possible to keep all the related logic in a service. Otherwise, the services will try to
communicate with each other, impacting the overall performance.

For e.g.

Coupling – a class is dependent on an interface without knowing its actual implementation is the
example of low coupling. Or one microservice can communicate with other without knowing
what exactly happens in that api.

Cohesion – a class for e.g. a shoppingcart class is capable enough to perform all the operations
related to the adding, deleting, updating items in the cart is an example of cohesion. Or A
microservice written for shopping cart should have all the functionalities related to shopping cart
otherwise it will look for other apis to do some of the tasks.

What do you understand by Distributed Transaction?

Distributed Transaction is any situation where a single event results in the updation of two or
more separate sources of data which cannot be committed atomically.

What are Client certificates?

A type of digital certificate that is used by client systems to make authenticated requests to a
remote server is known as the client certificate. Client certificates play a very important role in
many mutual authentication designs, providing strong assurances of a requester’s identity.

What is Conway’s law?

Any organization that designs a system (defined broadly) will produce a design whose
structure is a copy of the organization’s communication structure.” – Mel Conway
What is End to End Microservices Testing?
End-to-end testing validates each and every process in the workflow is functioning
properly. This ensures that the system works together as a whole and satisfies all
requirements.

In layman terms, you can say that end to end testing is a kind of tests where everything
is tested after a particular period.

What is the use of Container in Microservices?

Containers are a good way to manage microservice based application to develop and deploy
them individually. You can encapsulate your microservice in a container image along with its
dependencies, which then can be used to roll on-demand instances of microservice without any
additional efforts required.

How Can You Set Up Service Discovery?

Service Discovery – In microservices we divide our application into multiple modules where each module
in itself can have one or more services. After deployment of all these services we need their network
location to consume them. In traditional approach where our services has an static network location or
ipaddress, which we can keep in any configuration file and calling service can consume the services with
the help of configuration. But now we can auto-scale our application as per their needs, one or more is
instances of application can fail due to any reason, it means our application can have multiple running
instances which have different network location. To send request to any instance of an webapi we need
to discover their network location. This is where services discovery comes to play role.

There are two types of discovery patterns

The Server-Side Discovery Pattern – Here client makes request to the load balancer and then it routes
the request to the available instances. If we have multiple instances of a service then load balancer keep
information of all the running instances and keep them in service registry, as soon as request arrives to
load balancer it sends the request to appropriate instance of service. For eg. Azure load balancer

The Client Side Discovery pattern – the client is responsible for determining the network locations of
available service instances and load balancing requests across them. The client queries a service registry,
which is a database of available service instances. The client then uses a load-balancing algorithm to
select one of the available service instances and makes a request. For eg. We can use eureka or consul
as a service registry database. Whenever a new instance of the application is created, application itself
register to the consul and share it network location to it. Consul store the network location against the
instance. Now client will send request to the consul and it will return any one running instance of the
particular service. Then client sends the request to the same service instance. Consul also keep track of
inactive instances.

Client side discovery pattern is more cost effective as compared to server side pattern, because here we
don’t need to pay for load balancer applied to each service. For e.g. if we have application having 5
different services and each service has 10 running instances, it means we will need atleast 5 load
balancer one for each service. Load balancer is a paid service for which we have to pay to the service
provider, this cost can be waived off if we use client side discovery pattern.

-------------Raj---

Server-Side vs. Client-Side Service Discovery: A Comparative Analysis

In microservices architecture, service discovery is a crucial mechanism that enables services to locate
and communicate with each other. It addresses the dynamic nature of microservices, where services can
be added, removed, or scaled without impacting the overall system.

There are primarily two approaches to service discovery: server-side and client-side. Let's delve into the
key differences and considerations for each:

Server-Side Service Discovery

 Centralized Registry: A central registry maintains information about all services, including their
addresses and health status.

 Load Balancer: A load balancer acts as an intermediary, querying the registry to route incoming
requests to available service instances.
  Client Simplicity: Clients interact with the load balancer, simplifying their implementation and
reducing complexity.

 Centralized Control: The load balancer can implement advanced load-balancing strategies, such
as round-robin, least connections, or weighted load balancing.

 Potential Bottleneck: The load balancer can become a single point of failure, impacting overall
system performance.

Client-Side Service Discovery

 Distributed Registry: Service instances register themselves with a distributed registry, which can
be a centralized service or a distributed system like Consul or ZooKeeper.

 Client Responsibility: Clients query the registry to obtain the addresses of services they need to
communicate with.

 Flexibility: Clients can implement custom load-balancing strategies and fault tolerance
mechanisms.

 Distributed Control: The discovery process is distributed across multiple clients, reducing the
risk of a single point of failure.

 Increased Complexity: Clients need to implement logic for service discovery, which can add
complexity to the application code.

Choosing the Right Approach

The choice between server-side and client-side service discovery depends on several factors:

 Complexity: If you prefer a simpler client implementation, server-side discovery is a good

choice.

 Control: Client-side discovery offers more flexibility and control over load balancing and fault
tolerance.

 Performance: Server-side discovery can potentially improve performance by reducing network

hops, but it can also introduce a single point of failure.

 Scalability: Both approaches can be scaled effectively, but server-side discovery might require
careful configuration of the load balancer.

 Security: Consider the security implications of exposing service registries and load balancers.

-----------------------------------------------------------------

How does Docker help in Microservices?

Answer: Microservices, as we know, are self-contained, individual units that perform
only one business function, so much so that each unit can be considered an application
on its own. 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. It is, in fact, a containerization tool. It reduces overhead and deploys
thousands of microservices on the same server. Docker ensures that an application
microservices will run on their own environments and are entirely separate from their
operating system.

How do independent Microservices communicate with each other?

Answer: 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.

What Are The Fundamentals Of successful Microservices Design?

Some fundamentals to a successful microservice design.

1. The Scope Of Functionality - When we talk about the

scope of a microservice, we are referring to the features of an independent software
module. The ability of microservices to perform as a nearly-stateless system allows it to
be developed independently. It thus becomes imperative to identify functionalities that a
microservice will implement. This helps to understand what a microservice is
responsible for?

2. High Cohesion Combined With Loose

Coupling
The main motive of any microservice is to have services independent of each other.
This means one can edit, update or deploy a new service without hampering any other
services present. This is possible if interdependence is low. A loosely coupled system is
the one where one service knows too less or nothing about others.
When breaking down a monolithic architecture into smaller services or components, it is
important to combine similar functionalities. This combination of related logic into a
single unit is known as cohesion. The higher the cohesion, the better is the microservice
architecture. A low cohesion would indicate too much communication between different
services leading to a poor system performance.

3. Unique Source Of Identification

Following the fundamentals of microservice design, it is important for any service to be
the unique source of identification for the rest of the system. Let us take an example to
understand this scenario.

After an order is placed on an e-commerce website, the user is provided with an order
ID. This order ID once generated contains all the information regarding the order. As a
microservice, the order ID is the only source for any information regarding the order
service. So, if any other service seeks information regarding the order service, the order
ID acts as the source of information rather than its actual attributes.

4. API Integration
Breaking down the monolithic design into multiple services means these services will
coordinate and work together to form the system. But, how do these services
communicate? Imagine using multiple technologies to create different services. How do
they relate to each other?

Well, the simple answer would be the use of an API (Application Programming
Interface). The fundamental of microservice design is using the correct API. This is
crucial to maintaining communication between the service and the client calls. Easy
transition and execution are important for proper functioning.

5. Data Storage Segregation

Any data stored for a specific service should be made private to that specific service.
This means any access to the data should be owned by the service. This data can be
shared with any other service only through an API. This is very important to maintain
limited access to data and avoid ‘service coupling’. Classification of data based on the
users is important and can be achieved through the Command and Query
Responsibility Segregation (CQRS).

6. Traffic Management
Once the APIs have been set and the system is up and running, traffic to different
services will vary. The traffic is the calls sent to specific services by the client. In the real
world scenario, a service may run slowly, thus, causing calls to take more time. Or a
service may be flooded with calls. In both the cases, the performance will be affected
even causing a software or hardware crash.

This high traffic demand needs management. A specific way of calling and being called
is the answer to a smooth flow of traffic. The services should be able to terminate any
such instances which cause delay and affect the performance.

This can also be achieved using a process known as ‘auto-scaling’ which includes
constant tracking of services with prompt action whenever required. In some cases, a
‘circuit breaker pattern’ is important to supply whatever incomplete information is
available in case of a broken call or an unresponsive service.

7. Constant Monitoring
Imagine breaking down a monolithic architecture into a microservice design. This needs
a lot of time and resources. It is not easy to monitor all the changes made with the help
of traditional tools. The insertion of data layers and caching increases performance but
makes it difficult to monitor the entire process.

Hence, for designing a microservice architecture, it is important to establish a process

for actively monitoring the storage of the data in a central location. This will help reflect
the frequent changes without affecting the performance of the system. In a common
scenario, the microservice monitoring tools will monitor individual services and later
combine the data by storing it in a centralized location. This is a necessary step while
following micro-services design principles.

What do you mean by Microservices retry and circuit breaker

policy ?

Retry and circuit-breaker patterns are the 2 most

common approaches when coding for resiliency.

Retry: If something goes wrong, try repeating the same

operation again x number of times before giving up.
Generally, this approach is used when you have a flaky
dependency which you have no control over. Examples of
this might be your service calling a third-party API.

Circuit-breaker: If something goes wrong, hit the panic

button that prevents any further attempts to repeat the
operation.

This is typically used when you have an extremely

unreliable dependency. In this case, we want to stop
calling it altogether, as additional attempts to call it
might worsen the situation. An example of this might be
an overloaded database.

Just use Polly. It’s a mature library which is almost

synonymous with app resiliency, in the same way
that Newtonsoft.Json is the defacto library for JSON
(de)serialization.

public
interface
IMessageServi
ce
{
Task<string> GetHelloMessage();
Task<string> GetGoodbyeMessage();
}
 public class MessageService : IMessageService
{
private IMessageRepository _messageRepository;
private AsyncRetryPolicy _retryPolicy;
private AsyncCircuitBreakerPolicy _circuitBreakerPolicy;

public MessageService(IMessageRepository messageRepository)

{
_messageRepository = messageRepository;
_retryPolicy = Policy
.Handle<Exception>()
.WaitAndRetryAsync(2, retryAttempt => {
var timeToWait = TimeSpan.FromSeconds(Math.Pow(2,
retryAttempt));
Console.WriteLine($"Waiting
{timeToWait.TotalSeconds} seconds");
return timeToWait;
}
);

_circuitBreakerPolicy = Policy.Handle<Exception>()
.CircuitBreakerAsync(1, TimeSpan.FromMinutes(1),
(ex, t) =>
{
Console.WriteLine("Circuit broken!");
},
() =>
{
Console.WriteLine("Circuit Reset!");
});
}

public async Task<string> GetHelloMessage()

{
return await _retryPolicy.ExecuteAsync<string>(async () =>
await _messageRepository.GetHelloMessage());
}
 public async Task<string> GetGoodbyeMessage()
{
Try
{
Console.WriteLine($"Circuit State:
{_circuitBreakerPolicy.CircuitState}");
return await
_circuitBreakerPolicy.ExecuteAsync<string>(async () =>
{
return await _messageRepository.GetGoodbyeMessage();
});
}
catch (Exception ex)
{
return ex.Message;
}
}
}

In above code we are using both approaches (1) Retry policy (2) Circuit breaker

In retry policy we are giving the value like how many times the repository method should be invoked
if it gives Exception. Here we can give custom exception class so that retry should happen if we get
exception of that particular type only. If our application gets the response before maximum retries
then no more retry would happen. If we still get the exception after maximum retries then application
will throw exception.

Circuit-breaker Policies
In circuit breaker we define the value like after how many consecutives exception circuit should be
breaked and the duration for which circuit should be breaked.
If any further request comes during that period then circuit breaker will give
the message that “The circuit is now open and is not allowing calls.
“.

Lets see a example where we are doing both retry and circuit break.

//ConfigureServices() - Startup.cs

services.AddHttpClient<IBasketService, BasketService>()
 .SetHandlerLifetime(TimeSpan.FromMinutes(5)) //Sample. Default lifetime is 2 minutes

.AddHttpMessageHandler<HttpClientAuthorizationDelegatingHandler>()

.AddPolicyHandler(GetRetryPolicy())

.AddPolicyHandler(GetCircuitBreakerPolicy());

static IAsyncPolicy<HttpResponseMessage> GetCircuitBreakerPolicy()

{
return HttpPolicyExtensions
.HandleTransientHttpError()
.CircuitBreakerAsync(5, TimeSpan.FromSeconds(30));
}

n the code example above, the circuit breaker policy is configured so it breaks or
opens the circuit when there have been five consecutive faults when retrying the
Http requests. When that happens, the circuit will break for 30 seconds: in that
period, calls will be failed immediately by the circuit-breaker rather than actually be
placed. The policy automatically interprets relevant exceptions and HTTP status
codes as faults.

public class CartController : Controller

//…

public async Task<IActionResult> Index()

try

var user = _appUserParser.Parse(HttpContext.User);

//Http requests using the Typed Client (Service Agent)

var vm = await _basketSvc.GetBasket(user);

return View(vm);

catch (BrokenCircuitException)

{
 // Catches error when Basket.api is in circuit-opened mode

HandleBrokenCircuitException();

return View();

private void HandleBrokenCircuitException()

TempData["BasketInoperativeMsg"] = "Basket Service is inoperative, please try later on.

(Business message due to Circuit-Breaker)";

}
using Polly;

// ...

var retryPolicy = Policy

.Handle<Exception>()

.WaitAndRetryAsync(3, retryAttempt => TimeSpan.FromSeconds(Math.Pow(2, retryAttempt)));

await retryPolicy.ExecuteAsync(async () =>

// Your operation that might fail

await Task.Delay(1000);

throw new Exception("Simulated failure");

});

 The Policy.Handle<Exception>() part specifies that the policy should handle any exceptions.

 WaitAndRetryAsync(3, retryAttempt => TimeSpan.FromSeconds(Math.Pow(2, retryAttempt)))

configures the retry policy to retry up to 3 times, with an exponential backoff strategy.

using Polly.CircuitBreaker;

// ...

var circuitBreakerPolicy = Policy

.Handle<Exception>()

.CircuitBreakerAsync(3, TimeSpan.FromMinutes(5));
await circuitBreakerPolicy.ExecuteAsync(async () =>

// Your operation that might fail

await Task.Delay(1000);

throw new Exception("Simulated failure");

});

Microservices Pattern

Key Concepts and Technologies for .NET Core Microservices

To effectively build and manage microservices in .NET Core, you should focus on the following key areas:

Core Concepts

1. Microservices Architecture:

o Understand the fundamental principles of microservices: small, independent services.

o Learn about service boundaries, domain-driven design, and bounded contexts.

2. RESTful APIs:

o Master the design and implementation of RESTful APIs using ASP.NET Core.

o Grasp concepts like HTTP methods, status codes, and content negotiation.

3. API Gateways:

o Explore API gateways like Ocelot or Kong to route requests, handle authentication, and
rate limiting.

o Learn how to configure and deploy API gateways.

4. Service Discovery:

o Understand the importance of service discovery mechanisms like Consul or Eureka.

o Implement service registration and discovery in your microservices.

 5. Load Balancing:

o Learn about different load balancing techniques (round-robin, least connections, etc.).

o Configure load balancers to distribute traffic evenly across service instances.

6. Circuit Breaker Pattern:

o Implement circuit breakers using Polly or Hystrix to prevent cascading failures.

o Understand concepts like open, closed, and half-open states.

7. Retry Pattern:

o Implement retry mechanisms to handle transient failures.

o Configure retry policies with appropriate delays and maximum attempts.

8. Rate Limiting:

o Protect your services from overload by implementing rate limiting.

o Use tools like AspNetCoreRateLimit or API gateways to enforce rate limits.

.NET Core Technologies

1. ASP.NET Core:

o Master the fundamentals of ASP.NET Core, including MVC and Web API.

o Learn about dependency injection, middleware, and configuration.

2. gRPC:

o Explore gRPC for high-performance, efficient communication between microservices.

o Understand protocol buffers and streaming.

3. Message Queues:

o Use message queues like RabbitMQ or Azure Service Bus for asynchronous
communication.

o Learn about message patterns like publish-subscribe and request-reply.

4. Distributed Tracing:

o Implement distributed tracing tools like Jaeger or Zipkin to monitor and troubleshoot
microservices.

o Understand concepts like spans, traces, and logs.

5. Configuration Management:

o Use tools like IConfiguration or external configuration providers to manage settings.

 o Learn how to handle secrets and sensitive information securely.

6. Logging and Monitoring:

o Implement robust logging and monitoring solutions.

o Use tools like Serilog, ELK Stack, or Azure Monitor.

7. Security:

o Secure your microservices with authentication, authorization, and data encryption.

o Implement best practices for protecting sensitive information.

By mastering these concepts and technologies, you'll be well-equipped to build scalable, resilient, and
maintainable microservices applications in .NET Core.

Would you like to delve deeper into a specific topic or have any other questions?

Service Boundaries

Service boundaries are crucial in microservices architecture as they define the scope and responsibilities
of each individual service.

If we have clear boundaries of each microserive then we can easily scale,independent deploy,fault
tolerant,Technology diversity

How to define service boundaries

1)Domain driven development 2)Single responsibility principle 3) High Cohesion, Low Coupling

ex- Example: E-commerce Application

Consider an e-commerce application. We can define the following microservices with clear boundaries:

 Product Catalog Service:

o Manages product information, pricing, and inventory.

o Handles product search and filtering.

 Order Processing Service:

o Processes orders, including payment processing, shipping, and order tracking.

 o Manages order status updates and notifications.

 User Service:

o Manages user accounts, profiles, and preferences.

o Handles user authentication and authorization.

 Recommendation Service:

o Provides personalized product recommendations based on user behavior and purchase

history.

Additional Considerations:

Evolutionary Design: Start with a simple design and evolve your microservices architecture as your
application grows.

Service Boundaries, Domain-Driven Design, and Bounded Contexts

These concepts are fundamental to designing effective microservices architectures. Let's break them
down with examples:

1. Service Boundaries

 Definition: The clear demarcation between different microservices, defining their

responsibilities and interactions.

 Example: In an e-commerce application, you might have separate microservices for:

o Product Catalog: Manages product information, pricing, and inventory.

o Order Processing: Handles order placement, payment processing, and shipping.

o User Management: Manages user accounts, profiles, and preferences.

2. Domain-Driven Design (DDD)

 Definition: A software development approach that focuses on modeling a software system

around a specific domain.
  Key Concepts in DDD:

o Domain: A specific area of knowledge or business activity.

o Bounded Context: A specific context within a domain where a particular language and
set of terms apply.

o Ubiquitous Language: A shared language between technical and domain experts.

o Domain Model: A conceptual model of the domain, representing entities, value objects,
and aggregates.

 Example:

o E-commerce Domain:

 Bounded Context: Product Catalog

 Entities: Product, Category, Inventory

 Value Objects: Price, Weight, Color

 Bounded Context: Order Processing

 Entities: Order, OrderItem, Shipment

 Value Objects: Address, PaymentDetails

3. Bounded Contexts

 Definition: A specific context within a domain where a particular language and set of terms
apply.

 Example:

o In an e-commerce application, the "Product Catalog" and "Order Processing" contexts

might have different ways of representing a "Product."

 Product Catalog: Might focus on product attributes like color, size, and material.

 Order Processing: Might focus on product ID, price, and quantity.

Relationship Between the Three

 Service Boundaries are often aligned with Bounded Contexts. Each Bounded Context can
typically be implemented as a separate microservice.

 Domain-Driven Design helps define the Bounded Contexts and the Ubiquitous Language used
within each context.

 Well-defined Service Boundaries ensure that microservices are loosely coupled and can evolve
independently.

Benefits of Using These Concepts

  Improved System Design: More focused and cohesive services.

 Enhanced Team Collaboration: Shared understanding of the domain.

 Increased Agility: Faster development and deployment.

 Reduced Complexity: Breaking down a large, complex system into smaller, manageable parts.

By understanding and applying these concepts, you can design microservices that are well-structured,
maintainable, and scalable.

How Order Processing and Payment Processing Microservices Communicate

Understanding the Relationship

In a microservices architecture, the Order Processing and Payment Processing services often work in
tandem to complete a purchase. The Order Processing service initiates the order, while the Payment
Processing service handles the financial transaction.

Communication Mechanisms

Several strategies can be employed to facilitate communication between these two services:

1. RESTful API:

 Direct Request-Response:

o The Order Processing service sends an HTTP request to the Payment Processing service,
providing order details, payment information, and other relevant data.

o The Payment Processing service processes the payment and sends an HTTP response
indicating success or failure.

2. Message Queues:

 Asynchronous Communication:
 o The Order Processing service sends a message to a message queue containing order
details.

o The Payment Processing service consumes the message and processes the payment.

o This approach decouples the services and allows for asynchronous processing,
improving scalability and reliability.

3. Event-Driven Architecture:

 Event-Based Communication:

o The Order Processing service emits an event (e.g., "Order Placed") when an order is
created.

o The Payment Processing service subscribes to this event and triggers the payment
process.

o This approach enables real-time updates and reactive systems.

Key Considerations for Communication:

 Security:

o Implement strong security measures to protect sensitive payment information.

o Use encryption, authentication, and authorization mechanisms.

 Reliability:

o Implement retry mechanisms and circuit breakers to handle failures and ensure reliable
communication.

o Use asynchronous communication patterns to reduce the impact of network latency.

 Performance:

o Optimize API calls and message queues for efficient communication.

o Consider using caching and batch processing to improve performance.

 Scalability:

o Design the communication layer to handle increasing load and scale horizontally.

 Error Handling:

o Implement robust error handling and logging to identify and resolve issues.

Choosing the Right Approach

The best communication mechanism depends on various factors, including:

 Performance requirements: Real-time processing might favor synchronous RESTful APIs, while
asynchronous processing might be better for batch jobs.
  Reliability: Message queues and event-driven architectures can improve reliability by
decoupling services.

 Scalability: Asynchronous communication patterns can help scale systems effectively.

 Security: Strong security measures are essential for payment processing, especially when using
RESTful APIs.

By carefully considering these factors, you can design a reliable and efficient communication strategy
between your Order Processing and Payment Processing microservices.

Message broker allowed to

Flexible Routing: It provides flexible routing mechanisms, allowing messages to be routed to different
consumers based on various criteria.

How RabbitMQ Works:

1. Producer: A producer sends messages to a RabbitMQ exchange.

2. Exchange: The exchange routes messages to queues based on routing keys.

3. Queue: Messages are stored in queues until a consumer claims them.

4. Consumer: A consumer consumes messages from a queue and processes them.