Microservices:

Application is structure as a group of individual loosely coupled services and they

Interact with each other like lightweight protocol like rest http and also lot of library available.

Also we use RPC.

e-commerce have many services

like search product

list product

shipping

payment
They are not dependent on other services in same app.

If required they make rest or RPC call for other services to get or update services and they deploy
separately.

Service: group of API’s

Service contains many API’s:

Monolithic architecture?

Advantage as Monolithic:

Configure load balancer for the server

Server contains application package and all.

It get complex when more and more customers comes in.

What happens when millions of users users then how?

Disadvantage:

If technology build on jango then may be notification serve build with nodeJS or someotjer
Or some company give nodejs or go.

Can’t use because we use jango and python cant integrate due to technology difference

Or break into features as service orientate architecture.

2) engineer focus: team work on order management understand same team and understand code
and tightly couple too

3)scaling data layer: we can scale VM but as we have more VM everyone talking to same DB.

Even we have load balancer as conteainer talk to same DB.

If RDMS used and anyother.

Transacgtion and request problem as lot of VM.

All DB in one DB but it will problem as we cant serve too much .

Adding read replicas of DB is possible but writes are still a problem.

4) overloaded VM/container:

Since every module in single application.

Size of app problem copy to VM take time all problem.

Cant spin out some application take 15 to 20 mins take time.

5)CI/CD problem: the test will be pain point need to run test for all application

As its tight couple.

And build take time and push code have so many conflicts to same repo.

So new dev to team understand code pain as its huge file of code as new dev lost understand all of
this code.

To take problem and make a better ecommerce scaling and all we can do with microservices.

Monolithic architecture:
Functional Decomposition:

Break down existing system into small different modular services.

Breakdown application into different services.

Search+product-> one microservices

Rating & Review-> one microservices

Users-> one microservers

Payment,shipping,notification-? Indidepent microsevvices.

Not packed in one services but individual services.

Broken into different services and have code base and different team have underatand for specific
services and maintain application and individual deploy and scale horizontally based on traffic.

How app interact with e-commerce application?

Search+product -> request to this services

Users-> different users.

Everymodule in same DB but now much easier to do.

If user interact with payment call payment function calls.

Payment send notification for function call and send notification.

Shipping notify user then shipping.

As these are decomposed how interacted.

Product called then send notification need to send.

From shipping call notification in similar way the user is calling.

What to do is make call from shipping to notification it will be of different interface like

Rest or RPC or whatever it is.

Service interact with each other with rest calls.

All happens through rest calls:

Do we have one DB ?

Every service should have own database.

Advantage : since one DB per service shows what kind of data we want not like old monolotic.

Like notification RDBMS

Search+product ->elastic .

As below application servers can use different database:

Also transaction for read and right distributed individually,

The load is distributed to different DB.

Earlier join can done with same DB in monolithic

Now its not possible as each in different services.

Advantages:

Scaling is easy bcoz if want to scale one service faster

If search more traffic can scale out that service.

Deploy easy: as size of code base is small and start time is reduce.

Load and build application is easy

Scale fast and deploy faster more container deployment more.

No dependency on services

One services one code like python or golang or java.

Faster to develop to understand: code base is small like how payment work can check payment code
only bcoz its loosely couple as code based to specific services.
Microsevices are loosely coupled:

Means change part of code in one services doesn’t affect other services.

While monolithic app change one part of code have impact on other modules.

Loosely couple service:

If payment service not working it wont impact other services like search or add to cart or other.

Can easily fix due to mixroservices.

If search is down then ony that not working.

Insead of taking application only part of them affected.

 Interprocess communication: call different service call using restapi.
To handle new cases
Call rest services from payment from fraud deduction
What happen fraud deduction api give 500 or 404 error what to do
We need to handle different use cases like circuit breaking and all.
 Distributed transaction: different DB cannot have transaction leads to usage of
New kind of distributed transactions like two face commit or saga

 More resources-> deployed individually so needed more resources.

 Debugging issues-> earlier all functional calls in monolithic easy
Now rest calls one service to other it difficult to trace and debug issues
So many tools like agar.io implementation to trace microservices also hops between services
called as distributed tracing.

Maintain microservices also difficult it will be.

Might be data duplicate too due to different services and DB.
Scale microservices:
Scale cube in different directions.
Horizontal scaling: search + product (run duplicate of same services)

Also load balancer and all also service discovery and gateway.

Functional decomposition: decompose search and product page into more services

Like 3 services

Search one service

List another service

Product another services.

Data partitioning: scale by partition data

If microservice user service if scale user service with data partition

This service all user starting with letter a to z.

Add another service and them first server a to N and next n to z

By doing so update data partition

Service 1 -> a to c

Service 2-> d to k

Service 3 -> N to z.
Above techniques to scale microservices but vertical scaling cant do bcoz can be hard end

We get bigger machine of ram and all which is not feasible.

API gateway:

Above each services are totally different functionality and individual.

If monolithic architecture we use expose one API /productinfo/product ID 123 all in one api we
could have.

Only one call in monolithic.

Now decompose monolithic into different means individual each services.

1) Direct calls -> front end call each services one by one or parallel.

Through mobile calling different services:

So total 7 calls to get info.

But is it good or best way to do it as we need to make 7 calls as will have impact on load time

And resource consumption.

If tomorrow split rating and review into two different services then update client to update 8 calls
than 7.

2) API gateway:

Have one services between client and services:

Any client access microservices directly it should make call to API gateway and it make calls to the
services.

We can configure API gateway or expose one API like /productInfo/

And API gateway makes 7 calls to microservices and combine those and give to client

Since API gateway on same network wont take any time.

Its faster since its parallel calls.

if want to make two serial calls one of another then can configure in API gateway

first call search product based on that 6 different calls can make also possible with API gateway.

Another access pattern for API gateway called as backend for front end :

Instead of one API gateway it can have another API gateway for mobile and web or another

API gateway for third party.

if call from web it goes to API web and get info.

Advantage for BFF:

Mobile cant pull all info at once.

Scroll and pull data based on info different kind of combination for different kind of devices

Which can have through BFF.

API gateway advantage:

Authentication: can happen at API gateway like token based(JWT JSON token based) which check

API or have authentication at every microservices.

SSL termination: call using https until microservices

Only HTTPS verify until API gateway and services can have using http internal calls.

From API gateway it can be WebSocket or https or RPC call.

Internally whatever protocol and external http or https with port.

Load balancer: increase serve for search product then API gateway understand increase LB.

Insulation: no one can access directly only API gateway can access it.

Loosely couple too

No need to change code in client but in API gateway we can make different calls to services .

If no need different services then we can do using API gateway.

Disadvantages:

Increases hops one hop to API and another hop to service might increase latancy.

System get complicated take API gateway and configure and maintain microservices.

Service Registry:

Client wants to talk to microservices without API gateway how can it be achieved?

Need Network address-> IP address + port No

API gateway act as load balancer too.

If shipping want to talk to merchant microservices which can be solved using service discovery.

But its work as load balancer but LB need to be informed about network address of microservices
where service registry come into picture.

Service discovery: identity network address all instance of microservices using service registry.

Service registry: DB contain IP address of all services and network addresses.

When client talk to microservices then ask service registry give address of shipping network address.

How service registry get latest address of microservices?

Two ways?

 Self registry -> automatic register.

As soon as server come up shipping service talk to service registry update network services
 IP and port.
So latest address of shipping added here.
What happens if instance goes down?
Every X second or minutes microservice update latest location in service registry
Old records removed and new updated latest update from microservices.

 Third party registry: Microservice not talk to service registry but service registry ask
microservices about address.

Service registry listen to cluster scaling up it heard that and service registry talk to that

Ip address and port no.

It also check if instance alive or not.

Other advantage: how many instance of service running or responding or not as its

Periodically pulling services and know state of each services.

Service registry also take to load balancer to increase the instances.

What is discovery?

Access all info from registry.

If client want to talk to any microservices

Client know location of service registry ask for latest network address of services.

Its upto client to talk to any services.

What if client cant go and ask service registry every time it might get timeout?

Server side discovery:

Client wont talk to service registry but talk to API gateway.

And API request service registry to give network address for microservices and use that list

And send the request and get the response back.

Inter Microservices Communication:

Synchronous: one call to two over rest or PRC and wait until it return response.

Asynchronus intern communication:

We use this when microservices wanted data to be updated.

An order is placed and every other microserices wanted to know if order is placed

We can build data pipeline of system like queues.

MS1 send a message to the queue and then all microservice listen to queue that order is placed.

MS1 write data to different queue and other consume.

https://www.youtube.com/watch?v=5XeVoHtFGo0

https://www.youtube.com/watch?v=q-EkBbfuiAo

https://www.youtube.com/watch?v=XJS_GwcLfHc