Microservice - Deep Dive

12/12/21, 12:26 PM Microservice - Deep dive.
Prerequisite: we have learned in… | by Jolly srivastava | System Design Concepts | Medium
Microservice - Deep dive

Jolly srivastava Follow
Dec 23, 2020 · 7 min read
Prerequisite: we have learned in previous microservice blogs about

monolithic and microservice architecture, the Advantages and
disadvantages of both, and when to go for which architecture.
https://medium.com/system-design-concepts/microservice-deep-dive-c100f641db73 1/17
12/12/21, 12:26 PM Microservice - Deep dive. Prerequisite: we have learned in… | by Jolly srivastava | System Design Concepts | Medium
https://medium.com/system-design-concepts/monolithic-
architecture-51272d0b3393
https://medium.com/system-design-concepts/microservice-
architecture-47e9581f8be9
Microservice is an architectural style in which an application is basically

structured as a group of individual loosely coupled services that are very
fine-grained and talks with other microservice/s using a very lightweight
protocol(as they are Single purpose, do one thing only e.g REST/HTTP,
RPC). These services are also deployed separately and not dependent on
any other service/s.
Microservice for e-commerce application
Let’s take the example of e-commerce microservice. As we can see in the

picture above, e-commerce microservice essentially comprises 4 other
loosely couple, fine-grained services that are deployed individually.
Monolith is the way of developing an application where all the modules are
built into one big application and are deployed together. The advantage of
this architecture is that they are simple to develop, deploy, and scale. It gets
complex when the customer base increases. Drawbacks are technology
dependency, engineering focus, scaling data layer not easy, overloaded
VM/container, understanding of code base, and many more.
FUNCTIONAL DECOMPOSITION:
A technique where we break down the application into smaller modular
pieces. How do we do this? We decompose the application based on the
functional areas like search, payment, product, shipping, authentication,
and other functional areas into their own microservices. These are now
granular service deployed independently and all of these has their
individual codebase. They can be scaled horizontally based on traffic/load.
How users/actors/applications interact with these services?
Monolith vs Microservices
In the above picture, the left side of the dotted line depicts monolith
architecture where all the modules i.e search+product, shipping, and
notification are bundled together, have one common code base, and are
deployed together on one server. When the shipping module wants to
interact with the notification module, it can make a simple function call.
Also, these modules share one common DB, which can be RDBMS or
NoSQL.
The Right Side of the dotted line depicts microservice architecture where all
the services have their own codebase (can be written in different languages
say search+product in java, shipping in python, and notification in
golang) and each one of these microservice has its own DB. The Advantage
of this is that it gives us the freedom to have our choice of DB as per our use
i.e for search we can use elastic, for shipping we can have any NoSQL say
mongo DB, and for notification, we can have RDBMS(oracle). If the
shipping service wants to interact with the notification service it makes a
rest call/RPC call to the notification service.
As we can see in the second scenario, scaling is easy i.e if more and more
user is performing only the search operation in our application we can scale
“search+product” without touching/affecting other services, deployment
is easy, no dependency on technological stack among services, loosely
coupled i.e changing one part of code won't affect other, and easy to
understand(one can focus on the service he/she is deveoping).
Disadvantages include interprocess communication ( Call using REST
API), distributed transaction(Will discuss this later in more detail), more
resources, and debugging issues.
THE SCALING CUBE:
In the previous blog, we have already gone through the scaling cube concept. I
am attaching the link herewith. Happy learning!!!
Microservice Architecture
Melvyn Conway, 1967i.
medium.com
API GATEWAY:
In a typical e-commerce application, we can see product details, reviews,
ratings, price, frequently together bought item, merchant details, shipping
information.
Let’s say all these services are functionally decomposed. When an

eCommerce page loads up we see all this info at once. How does this
happen?
Amazon’s product page
Direct calls where front end/client calls all these services one by one or
parallelly i.e 7 different calls to get this info. It’s not the best way of doing
this. It would have an impact on load and time.
Diret call
API GATEWAY: Another way is using API gateway i.e between client and
these microservices there’s one more service “API GATEWAY” in the same
network as these services (hence reducing the calling time). This service
internally can call these other 7 services in any order. It is much faster than
the above approach.
Api gateway
Advantage:
1. Authentication: Instead of every microservice checking for

authentication, now it can happen at the API gateway level itself (JSON
web token).
2. SSL termination: HTTPS is recommended for better security. However,

we can call other services from API gateway to microservices can use
HTTP. For the clients, they use only HTTPS, From the API gateway, it
can be web socket/HTTP/HTTPS/RPC anything.
3. Acts as a load balancer.
4. Insulation: No client from outside can directly access the microservice.
Disadvantage:
1. An increase in the hop may result in increased latency.
2. Results in a complex system as we now need to maintain API gateway.
Another pattern is BFF: Back-end for front-end: sort of same as API

GATEWAY pattern.
BFF
Here we have three different API gateway for three different purposes. If
the requet is coming from the web application then all calls will get
redirected to API gateway for web and in the case of mobile application and
third-party users, all the calls will get redirected to the respective API
gateway as shown in the above image. This way we can compose different
responses for different types of clients using the same microservice. Also,
we can track and rate limit the 3rd party API usage. one API gateway can be
for android and one for IOS as well.
SERVICE REGISTRY:
Let us consider a situation where we have horizontally scaled

search+product, inventory, merchants, and finance microservice. Let's
say we have 3 instances of merchants running and one goes down. The
question here arises that whose responsibility is it to inform API gateway
about the network address of the 3rd instance which is now down and the
network address of the new 4th instance which came up as a part of auto-
scaling?
There can be a situation where the “shipping” service wants to interact

with the “merchant” service. How will the shipping service get to know
about the IP address of the merchant service?
These are the problem which we will solve using “service discovery”.
Service discovery is a pattern to identify network add of other services

using service register which is kind of DB which contains the list of instance
and IP address. so if the client wants to interact with the shipping service
directly it can query service register and get the list of network addresses for
that particular service.
The question here arises that how service registry will get to know the latest
network address of any microservice?
1. Self registry: Let's say one instance gets added up in “shipping”

microservice, shipping microservice then interacts with service registry
and adds/updates its network address, port, and service name. If any of
the running instances goes down then after every x no of
minutes/seconds microservice keeps on updating their location, if any
service fails to update then the service registry deletes that information.
2. Third-party: in this case, a service registry asks microservices about

their address and port. It keeps on checking microservices periodically
and keep updating the service register/DB. The advantage of this is that
now the registry knows exactly how many instances of service are
running and the state of each and every service.
Let’s talk about discovery now. It is the counterpart of registration. We

basically access all the information present in the registry.
This answers “There can be the situation where the “shipping” service
wants to interact with the “merchant” service. How will shipping service
get to know about the IP address of the merchant service?”
The client can now request service registry and gets the list of network
address lets say ip1:<port1>, ip2:<port2> and ip3:<port3> in case of
merchant also load balances the requests among these machines. client
can’t keep on talking with service registry every time if it needs to interact
with microservices, there will be a designated TTL. What will happen if the
service registry updated itself but at the client end information still is not
updating. This is one disadvantage of talking with services directly and is
not advisable. Also, traffic on the service registry will be high as clients keep
asking for the latest data continuously. This is what the client discovery is.
There’s something known as server discovery as well where instead of a

client talking with service registry, API gateway requests service registry to
get the updated list of a network address of all the microservices and to
interact with all the microservices.
Service Registry
That’s all for this blog. Much more to come.
Stay tuned!!!
Get an email whenever Jolly srivastava publishes.

Emails will be sent to mishukran@gmail.com.
Subscribe
Not you?
Microservices System Design Interview Api Gateway Service Registry
Learn more. Make Medium yours. Write a story on Medium.

Medium is an open platform where 170 million Follow the writers, publications, and topics that If you have a story to tell, knowledge to share, or
readers come to find insightful and dynamic matter to you, and you’ll see them on your a perspective to offer — welcome home. It’s
thinking. Here, expert and undiscovered voices homepage and in your inbox. Explore easy and free to post your thinking on any topic.
alike dive into the heart of any topic and bring Start a blog
new ideas to the surface. Learn more
About Write Help Legal

Microservice - Deep Dive

Uploaded by

Document Information

Original Description:

Original Title

Copyright

Available Formats

Share this document

Share or Embed Document

Sharing Options

Did you find this document useful?

Is this content inappropriate?

Copyright:

Available Formats

Microservice - Deep Dive

Uploaded by

Copyright:

Available Formats

12/12/21, 12:26 PM Microservice - Deep dive.

Microservice - Deep dive

Dec 23, 2020 · 7 min read

Prerequisite: we have learned in previous microservice blogs about

Microservice is an architectural style in which an application is basically

Microservice for e-commerce application

Let’s take the example of e-commerce microservice. As we can see in the

loosely couple, fine-grained services that are deployed individually.

How users/actors/applications interact with these services?

THE SCALING CUBE:

Let’s say all these services are functionally decomposed. When an

Amazon’s product page

1. Authentication: Instead of every microservice checking for

2. SSL termination: HTTPS is recommended for better security. However,

3. Acts as a load balancer.

4. Insulation: No client from outside can directly access the microservice.

1. An increase in the hop may result in increased latency.

2. Results in a complex system as we now need to maintain API gateway.

Another pattern is BFF: Back-end for front-end: sort of same as API

Let us consider a situation where we have horizontally scaled

There can be a situation where the “shipping” service wants to interact

Service discovery is a pattern to identify network add of other services

1. Self registry: Let's say one instance gets added up in “shipping”

2. Third-party: in this case, a service registry asks microservices about

Let’s talk about discovery now. It is the counterpart of registration. We

There’s something known as server discovery as well where instead of a

That’s all for this blog. Much more to come.

Get an email whenever Jolly srivastava publishes.

Microservices System Design Interview Api Gateway Service Registry

Learn more. Make Medium yours. Write a story on Medium.

About Write Help Legal

You might also like