Monolith is huge system

Microservices are Single business unit all data all functions which are relevant to a service are put into one service if you can separate it.

With a lot of concerts being separated out then you probably want to separate a single service into pieces.

Client may not be talking to the microservices. They will be talking to gateway

Stackoverflow : monolith

Google , facebook: microservices

Pros:

· We can use different technologies using microservices.

· It takes care of the security of each service.

· More than one service can be parallelly developed and deployed.

· Services are independently managed.

· Better scalability and agility.

Cons:

· Communication between microservices can be complex.

· Large numbers of service management is difficult.

· Handling microservices with different business requirements is a tough task.

· So many configurations have to do which increases efforts.

· Network maintenance is difficult.

· Complex development and Security issues.

Adv:

· Easier to scale.

· Easy for new member.

· Loose coupling

· Easy to identity which one consuming more CPU %

Disadv:

· More context is required

· Deployments may be getting complicated

· Too much responsibility

· Service to service will be RPC instead of normal direct call

What is microservice ?

Difference between Monolithic vs Microservice

Advantages of Microservices ?

Disadvantages of Microservices ?

Why spring boot is preferred for microservice for java ?

Suppose there are 3 microservices. How do they communite with each other ?

How you have implemented service discovery?

Is it mandatory to use service discovery in Microservice architecture?

circuit breaker

The basic idea behind the circuit breaker is very simple. You wrap a protected function call in a circuit breaker object, which monitors for failures. Once the failures reach a certain threshold, the circuit breaker trips, and all further calls to the circuit breaker return with an error, without the protected call being made at all. Usually you'll also want some kind of monitor alert if the circuit breaker trips.

Suppose there are 3 microservices. What will happen if one fails ?

How to implement circuit breaker ?

Instead of fallback method, can we start from where we have failed? If yes how ?

Do not expose any web service url to users directly

How you have implemented Api Gateway

What are the things you can do at Api Gateway ?

Best practices of Microservice ?

Yes 12 Factor App describes the best practices of Microservices.

Microservice is architectural pattern or design pattern ?

Architectural pattern

Any other Architectural pattern ?

Monolithic, SOA, Hexogonal

Difference between architectural pattern and design pattern ?

Do you know any Microservice design pattern ?

· Saga design pattern

· API composition

· Service discovery pattern

· API Gateway pattern

· Circuit breaker pattern

· Observability pattern

· Deployment pattern

What is meant by distributed transaction ?

A tranaction spanning over multiple DB in microservice context

Data consistency ?

Used saga design pattern to implement data consistency distributed transaction

Where you deploy your microservice ?

Generally cloud, to take advantage of cloud native architecture

AWD EC2, AWS Beanstalk, Pivotal cloud foundary

Do you know about any deployment strategy in Microservices ?

Deployment per container, we have used

Single microservice -> single container

How do I monitor my microservice ?

Actuator.

For API monitoring, we can use API management tools like kong, apigee

For monitoring running service, we can use actuator, if using spring boot

For distributed logging, we can use ELK stack or Zipkin+sleuth or Jaeger+sleuth

What do you mean by scaling in microservices ?

Based on traffic increasing or decreasing instances of application

If you are using AWS ec2, you can increase or decrease instances based on traffic using

        CPU utilization percentage

CloudWatch

Is Microservice a part of cloudnative ?

         Yes. One of the features of Cloud Native Architecture

Tech Blogss

Advantages of Microservices Architecture

Advantage	Description
Independent Development	All microservices can be easily developed based on their individual functionality
Independent Deployment	Based on their services, they can be individually deployed in any application
Fault Isolation	Even if one service of the application does not work, the system still continues to function
Mixed Technology Stack	Different languages and technologies can be used to build different services of the same application
Granular Scaling	Individual components can scale as per need, there is no need to scale all components together

Microservice Architecture, is an architectural style that structures an application as a collection of small

autonomous services, modeled around a business domain.

Features of Microservices?

A microservice architecture has the following components:

What are the pros and cons of Microservice Architecture?

Pros of Microservice Architecture	Cons of Microservice Architecture
Freedom to use different technologies	Increases troubleshooting challenges
Each microservices focuses on single capability	Increases delay due to remote calls
Supports individual deployable units	Increased efforts for configuration and other operations
Allow frequent software releases	Difficult to maintain transaction safety
Ensures security of each service	Tough to track data across various boundaries
Mulitple services are parallelly developed and deployed	Difficult to code between services

There are many patterns related to the Microservices architecture pattern

The following diagrams shows how the saga for creating an Order works:

It consists of the follow steps:

The Order Service creates an Order in a pending state

The Order Service creates a CreateOrderSaga to coordinate the creation of the order.

The CreateOrderSaga sends a reserveCredit command to the CustomerService

The Customer Service receives the command and attempts to reserve credit for that Order. It replies with a message indicating the outcome.

The CreateOrderSaga receives the reply

It send either an ApproveOrder or a RejectOrder command to the OrderService

The Order Service receives the command and changes state of the order to either approved or rejected.

Microservices Interview questions | Interview Preparation (youtube.com)

Principles behind microservices

Independent & Autonomous Services

Scalability

Decentralization

Resilient services

Real time load balancing

Availability

Continuous delivery through devops integration

Seamless API integration & continuous monitoring

Isolation from failures

Auto provisioning

Aggregator: Collects related items of data and displays them. Based on DRY principle

API Gateway: can convert the protocol request from one type to other

API gateway acts as an entry point to forward the clients requests to appropriate microservices

Chain of responsibility

Produces a single output which is a combination of multiple chained outputs

Use synchronous http request or response for messaging

Asynchronous messaging

All the services can communicate with each other, but they do not have to communicate with each other sequentially.

Event sourcing

Creates events regarding the changes in the application state.

Command query responsibility segregator (CQRS)

Application is divided into 2 parts: Command and query

Circuit breaker

Used to stop the process of request and response if a service is not working.

Decomposition

Types of architectures

SAGA design pattern

How transaction is managed in microservices

Managing transactions in a microservices architecture can be more challenging than in a traditional monolithic system because microservices are designed to be independent, and they may use separate databases or even different types of data storage solutions. Ensuring data consistency and maintaining the ACID (Atomicity, Consistency, Isolation, Durability) properties across microservices can be complex. There are several approaches to manage transactions in a microservices environment:

1. Distributed Transactions:

• Two-Phase Commit (2PC): In this approach, a coordinator service coordinates the transaction across multiple microservices. It works in two phases - prepare and commit. All participating services must agree to the transaction in the prepare phase before it can be committed. While 2PC provides strong consistency, it can be slow and may not be suitable for high-throughput systems.

• Saga Pattern: A saga is a sequence of local transactions where each microservice is responsible for its own data. If a local transaction succeeds, it sends an event to trigger the next step in the saga. If a transaction fails, it can trigger compensating actions to undo the previous steps. Sagas are more scalable and resilient than 2PC, but they require careful design to ensure data consistency.

2. Event-Driven Architecture:

• Microservices can communicate via events. When one microservice needs to inform others about a change, it publishes an event to a message broker. Subscribing microservices can react to these events to maintain their own data consistency. Event-driven architectures are highly decoupled and provide asynchronous processing, making them suitable for many microservices scenarios.

3. Compensating Transactions:

• If a transaction in one microservice fails, it can trigger a compensating transaction to reverse the effects of the original operation. For example, if you deducted money in one service and failed to credit it in another, you can create a compensating transaction to credit the money back.

4. Idempotency:

• Make the operations of your microservices idempotent, meaning that performing an operation multiple times has the same effect as performing it once. This way, you can safely retry operations without worrying about unintended side effects.

5. CQRS (Command Query Responsibility Segregation):

• In a CQRS architecture, commands and queries are treated separately. Commands that modify data can be handled as transactions, ensuring data consistency, while queries for retrieving data can be eventually consistent.

6. Distributed Databases:

• Consider using distributed databases that support transactions across microservices, such as CockroachDB, Google Spanner, or Amazon Aurora. These databases provide strong consistency guarantees even in a distributed environment.

7. API Composition:

• In some cases, you can use API composition to retrieve data from multiple services and present it as a single response. While this doesn't provide full transactional consistency, it can be a practical approach for certain scenarios.

8. Distributed Tracing and Monitoring:

• Implement distributed tracing and monitoring to track the flow of transactions and identify issues in real-time. Tools like Zipkin, Jaeger, and Prometheus can help with this.

Design Patterns in Microservices

· Service Discovery: Helps microservices to find each other on the network, often implemented with tools like Consul or Eureka.

· API Gateway: Acts as a single entry point for all clients, handling requests, routing, and sometimes authentication.

· Circuit Breaker: Prevents cascading failures by stopping the service calls when a service is down, implemented with tools like Hystrix.

· Event Sourcing: Stores state changes as a sequence of events, which can be useful for auditing and rebuilding state.

Event sourcing changes the programming paradigm from persisting states to persisting events

· CQRS (Command Query Responsibility Segregation): Segregates read and write operations for better performance and scalability.

· Saga: Manages distributed transactions by coordinating microservices to maintain data consistency.

Microservice Connector We can also use event event-sourcing paradigm for transmitting events among microservices. For example, the shopping cart service generates various events for adding or removing items from the cart. Kafka broker acts as the event store, and other services including the fraud service, billing service, and email service consume events from the event store. Since events are the source of truth, each service can determine the domain model on its own.

I NEED TO UPDATE LOT OF SYSTEM DESIGN DOCUMENT. THIS IS IN MY TODO LIST