• It decouples the system from each other as components (it divides the problem into small pieces).
• Since it also scales the teams, it allows us to develop and deploy applications quickly.
• Facilitates maintenance and testability.
• It allows us to scale our system as a pinpoint.

• We decoupled the system into components, divided it into smaller pieces.

• So how will versioning and testing work? Components should talk to each other with consistent versions.
• What if an instant network split occurs in one of the parts in the system?
• What if an unexpected error occurs in a part of the components, where and in which conditions?

• We scaled the teams, and also we said that we can develop and deploy applications quickly.

• Most times the teams are unaware of each other.
• When we think of the system as a microservice, how will this system act in a reactive way? The A team's API is under the heavy load, but the B team's API still sending requests to the A. Then what will happen?

• What about monitoring and logging?

Of course,

Generally,

But,

Distributed monolith
architecture?

Synchronous dependencies.

E.g:

just like dominoes

Like fusebox in our house.

Cascading failures

Applications communicate with each other continuously:

• Network splits
• Timeouts
• Higher loads of traffic​

We can avoid:

• Unnecessary use of system resources (combining with bulkhead isolation)
• Cascading failures

Some tools:

In most cases, the failed operations can be performed successfully in the 2nd or 3rd retries.

Linear retry policy

It is a great mechanism against the transient faults in a distributed architecture.

Some tools:

What if things don't go as planned?

It is our backup strategy, especially in microservice architecture.

For example:

• An e-commerce payment operation.
  • Maybe we can process it asynchronously.
  • Maybe we can do payment operation on another bank.
  A fetch operation of product catalog on a search engine.
  • Maybe we can be returned a cached response?

Unavailable?

An API Gateway is one of the must-have parts of a microservice architecture.

It is great enabler because of:

• It provides us to create a single entry point to the system and create uniform experiences.

• End-user just talk with a single point.
• We can route an API to different points as we want without affecting to an end-user.
• We can log all requests and responses from a single point.
• We can manipulate requests and responses.
• Authentication.
• Caching...

• Reliable processing using policies (API level retry, throttling).

It is great enabler because of:

• Request shadowing

• It is a great feature in order to test an API under the real user traffic.

Due to the nature of microservice architecture, they are independent of each other.

Which request, where does it go?

How long does a request spend time?

We need to a distributed tracing mechanism.

With distributed tracing, we can debug and optimize code.

Which service is up? Which service is down?​

This is the question.

Services also have databases and different external services.

Health monitoring also important like tracing in order to see the health of the infrastructure.

End-to-end health status.

Application Insight

Prometheus

Metrics: