Microservices vs Monoliths -

In system design interviews, microservices are a popular topic, and it's crucial to understand
why they're used instead of monolithic systems. Simply put, microservices offer scalability

Advantages of microservice architecture:

1) Simpler to reason about and design for complicated systems -

Microservices architecture can make it easier to understand and develop complex software
systems. In a monolithic architecture, where the entire application is developed and
deployed as a single unit, it can be challenging to identify the components that are
responsible for specific functionalities, making it harder to make changes and maintain the
system over time.

In contrast, a microservices architecture breaks down the application into smaller,

independent services that are focused on specific business functionalities. Each
microservice can be developed and tested independently, making it easier to understand
how the overall system works and how each component interacts with the others.
Additionally, changes to a specific microservice do not necessarily require changes to the
entire application, which can simplify the development and deployment process.

Overall, a microservices architecture can provide developers with a more manageable and
structured approach to building complex software systems, making it easier to maintain and
scale them over time.

2) Enable new team members to train for shorter periods and require
less context before working on a system - A microservices architecture can
reduce the time and effort required for new team members to become productive
contributors to a software development project.

Since each microservice in a microservices architecture is designed to perform a specific

function and operates independently of the other services, a new team member can focus on
learning the functionalities of a specific microservice without needing to understand the
entire system. This can reduce the amount of context and knowledge transfer that is
required for the new team member to become productive.

In contrast, in a monolithic architecture, a new team member would need to understand the
entire application's codebase, including all of its dependencies and interactions, before being
able to work on any part of the system. This can take a significant amount of time and may
delay the new team member's ability to contribute meaningfully to the project.

Overall, a microservices architecture can enable new team members to ramp up faster and
start contributing to the project more quickly, making it easier for teams to scale up and
deliver software projects on time.
3) Deployments are fluid and continuous for each service - A microservices
architecture enables independent deployment of each service in the system. In a
microservices architecture, each service is designed and deployed independently of the
other services, allowing for a more fluid and continuous deployment process.

This means that when changes are made to a particular microservice, the deployment of that
service can be done independently of the other services in the system. This enables teams
to deploy new features, bug fixes, and other changes to specific services without affecting
the rest of the system.

In contrast, in a monolithic architecture, the entire application needs to be deployed at once,

even if only a small portion of the application has been changed. This can make the
deployment process more time-consuming and increase the risk of errors.

Overall, the fluid and continuous deployment process of microservices architecture can
make it easier and faster to deliver new features and changes to an application, while
reducing the risk of errors and minimizing downtime.

4) Services can be decoupled based on business responsibility - A

microservices architecture allows developers to break down an application into independent
services that are focused on specific business functionalities. Each microservice can be
developed and deployed independently, allowing teams to work on each service separately,
without affecting the other services.

This decoupling of services based on business responsibilities can make it easier for
developers to understand and modify the system's functionality, since each microservice is
designed to handle a specific task or feature. It can also help to isolate problems, as issues
in one service are less likely to affect the functionality of the other services.

For example, a company that provides an e-commerce platform may break down its
application into separate microservices, such as payment processing, order management,
and inventory management. By decoupling these services, the company can focus on the
functionality of each microservice independently, which can help to improve the overall
reliability, scalability, and maintainability of the application.

Overall, the ability to decouple services based on business responsibility is a key advantage
of microservices architecture, as it can enable developers to design, develop, and deploy
applications that are more flexible, scalable, and resilient.

5) Less prone to single points of failure since a bug in a single service

doesn't bring down the entire system - A microservices architecture is designed to
minimize the impact of failures within individual services on the overall system. Since each
microservice is developed and deployed independently, a bug or issue in one microservice is
less likely to affect the other services in the system.
In contrast, in a monolithic architecture, a single bug or failure in one part of the system can
bring down the entire application, making it a single point of failure. This can result in
downtime, lost revenue, and other issues that can impact the business.

By breaking down an application into independent microservices, a microservices

architecture can reduce the risk of single points of failure. Since each service can operate
independently, a failure in one service is less likely to affect the other services in the system.
This can help to ensure that the application remains available and responsive even when
individual services experience issues.

Overall, the reduced risk of single points of failure is a key advantage of microservices
architecture, as it can help to improve the reliability and availability of applications, making
them more resilient to issues and better able to meet the needs of users and businesses

6) Each service can be written in different languages - In a microservices

architecture, developers can use different programming languages and frameworks to
implement each individual service in the system. This is possible because each service
operates independently and communicates with other services through well-defined APIs,
which provide a standardized way for the services to exchange data and functionality,
regardless of the language in which they are written.

This flexibility can be useful for several reasons. For example, different services may require
different programming languages or frameworks to achieve optimal performance, or
developers may have different skills and preferences for different languages. Additionally,
using different languages can help to avoid vendor lock-in (a situation where a company
becomes dependent on a particular vendor's technology or products, making it difficult or
expensive to switch to an alternative vendor or technology. This can occur when a vendor's
products or services are tightly integrated with a company's existing systems, making it
difficult to replace them without significant disruption.

Vendor lock-in can be a problem for several reasons. For example, it can limit a company's
ability to innovate or adapt to changing market conditions, since they may be constrained by
the vendor's technology or products. Additionally, it can result in higher costs and reduced
flexibility, since companies may be required to pay premium prices or adhere to restrictive
licensing agreements.

In a microservices architecture, using different languages and frameworks for each service
can help to avoid vendor lock-in, since the services can be developed and deployed
independently using a variety of different technologies. This can help to ensure that the
company is not overly dependent on a particular vendor's technology or products, which can
reduce the risk of vendor lock-in and other issues), since the services can be developed and
deployed using a variety of different technologies.

Overall, the ability to use different languages and frameworks to develop each service in a
microservices architecture can provide developers with greater flexibility, allowing them to
choose the best tools for each individual service. This can help to improve the efficiency and
performance of the system, while reducing the risk of vendor lock-in and other issues.
7) Developer teams can communicate through API sheets instead of
working on the same repository, which may require conflict resolution -
In a microservices architecture, different development teams can work on different services
without needing to share the same codebase or repository. Instead, each service has its own
codebase, and the teams communicate with each other through a set of well-defined APIs.

This approach has several benefits. For example, it can help to reduce conflicts and errors
that can occur when multiple developers are working on the same codebase, since each
team is responsible for their own service and does not need to worry about affecting other
services. It can also make it easier to scale development efforts, since different teams can
work on different services simultaneously without getting in each other's way.

Overall, designing the architecture to enable developer teams to communicate through API
sheets instead of working on the same repository is a key aspect of microservices
architecture, and can help to improve development efficiency, reduce conflicts and errors,
and enable easier scaling of development efforts.

8) Testing new services is easier and more like unit testing than in a
monolith - In a microservices architecture, each service can be tested independently of
the other services in the system, which makes it easier to test new services as they are
developed. This is in contrast to a monolithic architecture, where testing new features often
requires testing the entire application as a whole, which can be more time-consuming and
complex.

In a microservices architecture, each service has its own set of tests that can be run
independently of the other services. This approach allows developers to identify and fix
issues with new services more quickly and efficiently, since they can focus on a single
service at a time and test it in isolation. This also makes testing more like unit testing, where
individual units of code are tested in isolation to ensure they are working correctly.

Overall, designing the architecture to enable testing new services independently and more
like unit testing is a key aspect of microservices architecture, and can help to improve
development efficiency and speed, reduce errors and bugs, and enable more rapid iteration
and deployment of new services.

Microservices are at a disadvantage to Monoliths in some cases.

Monoliths are favorable when:

1) The technical/developer team is very small - A monolithic architecture may be

a better choice than a microservices architecture in situations where the development team
is small and may not have the resources to manage a more complex microservices
architecture.

In a monolithic architecture, all of the code for an application is contained in a single

codebase, which can make it easier for a small team to manage and maintain. With fewer
services to manage, it may be easier to ensure that the application is running smoothly and
to fix any issues that arise.

In contrast, a microservices architecture can be more complex to manage, with many

different services that must be coordinated and tested together. This can be more
challenging for a small team to handle, especially if they do not have experience with
microservices architecture.

Overall, the choice between a monolithic architecture and a microservices architecture

depends on a variety of factors, including the size and experience of the development team,
the complexity of the application, and the requirements for scalability, flexibility, and
maintainability.

2) The service is simple to think of as a whole - A monolithic architecture may be

a better choice than a microservices architecture for simple services where all of the
functionality can be easily conceptualized and managed as a single unit.

In a monolithic architecture, all of the code for an application is contained in a single

codebase, which can make it easier to understand and manage the entire system as a
whole. This can be advantageous for simpler services that do not require a lot of
coordination between different components or services.

In contrast, a microservices architecture can be more complex to manage, with many

different services that must be coordinated and tested together. This can be more
challenging for simple services where there is not as much complexity to manage.

3) The service requires very high efficiency, where network calls are
avoided as much as possible - A monolithic architecture may be more appropriate
than a microservices architecture for services that require high performance and low latency,
where the overhead (the additional time, resources, and complexity required for
microservices to communicate with each other over a network, rather than within a single
codebase as in a monolithic architecture) of network communication between services in a
microservices architecture may be too great.

In a monolithic architecture, all of the code for an application is contained in a single

codebase, which can provide better performance and lower latency by avoiding the
overhead of network communication between different services. This can be advantageous
for services that require very high efficiency, where even small amounts of additional latency
can have a significant impact on performance.

In contrast, a microservices architecture can introduce additional latency and overhead due
to the need for network communication between different services. This can be a
disadvantage for services that require very high efficiency and low latency.

4) All developers must have context of all services - When all developers working
on a project must have a deep understanding of all the services in the system, a monolithic
architecture may be more advantageous than a microservices architecture.
In a monolithic architecture, the entire application codebase is stored in a single code
repository, making it easier for developers to work on any part of the codebase and have a
comprehensive view of the entire system. This is particularly useful in cases where all
developers must have an in-depth understanding of the entire system to develop or maintain
it effectively.

In contrast, in a microservices architecture, each service is developed and maintained

independently, and developers may only have a deep understanding of the services they are
responsible for. This can lead to challenges in maintaining consistency and coherence
across the entire system (the difficulties that may arise in ensuring that all the services in a
microservices architecture work together seamlessly and efficiently to deliver the desired
functionality to end-users), particularly when all developers must work together to build or
maintain the system.

Therefore, a monolithic architecture may be more favorable in cases where all developers
must have context of all services, as it provides a unified view of the entire system and can
make it easier to ensure consistency and coherence across the entire codebase.