Direct vs Gateway Microservice Architecture
Key Points
- The example uses a fictional e‑commerce site, “Indies Custom Threads,” where users order customized T‑shirts via web, mobile, and third‑party API clients.
- The product‑detail UI is split into several microservices (product info, pricing, order, inventory, reviews) instead of a monolithic app.
- One possible architecture lets each client call those microservices directly, with the UI making separate requests for info, price, stock, etc.
- While direct client‑to‑service communication can work for a small system, it quickly generates many API calls as functionality and services grow, making the approach inefficient.
- This limitation motivates the need for an API gateway or other pattern to consolidate and streamline client interactions with the microservice backend.
Full Transcript
# Direct vs Gateway Microservice Architecture **Source:** [https://www.youtube.com/watch?v=OAdOa31EH4o](https://www.youtube.com/watch?v=OAdOa31EH4o) **Duration:** 00:08:05 ## Summary - The example uses a fictional e‑commerce site, “Indies Custom Threads,” where users order customized T‑shirts via web, mobile, and third‑party API clients. - The product‑detail UI is split into several microservices (product info, pricing, order, inventory, reviews) instead of a monolithic app. - One possible architecture lets each client call those microservices directly, with the UI making separate requests for info, price, stock, etc. - While direct client‑to‑service communication can work for a small system, it quickly generates many API calls as functionality and services grow, making the approach inefficient. - This limitation motivates the need for an API gateway or other pattern to consolidate and streamline client interactions with the microservice backend. ## Sections - [00:00:00](https://www.youtube.com/watch?v=OAdOa31EH4o&t=0s) **Microservice Architecture for Custom T‑Shirts** - A walkthrough of a fictitious e‑commerce storefront illustrating users, web/mobile/third‑party clients, and how its product detail UI is broken out from a monolith into separate microservices such as a product‑info service. ## Full Transcript
so let's start off an example here let's
say we have a fictitious ecommerce
storefront
indies custom threads and in this store
you can order customized t-shirts kind
of like my nifty api gateway t-shirt
here
so let's walk through this scenario
right we have our users here and then
they would make the purchase and look at
the t-shirts on the website through
these different clients right so you'd
have your web application here which
would be a standard web browser
we'd have our mobile client as well it
could be ios it could be android and
then we also have a third-party api
integration service right so this could
be if you want to integrate your website
with like say something like facebook
or in our case we have a review
api that's integrated through a third
party so say you see someone makes a
comment about the t-shirt and they're
like
man the t-shirt fit comfortable but the
50 polyester really gave me a bad skin
rash that would all be possible through
this third-party integrated service
so now that we've established our users
and our clients
now let's take a look at the actual
product detail ui so there's a lot of
different functionality a lot of
different tasks that we've broken down
into these micro services here
and this originally would be a
monolithic application like we
previously talked about but we've broken
it apart and segmented it into different
services so
as you can see the first one here is the
product info service this would be stuff
like you know look at the t-shirt what
kind of color is a t-shirt is it black
red
the size of the t-shirt large medium and
so on
and then we have our pricing service we
have our order service if you want to
look at you know purchase history you
got the inventory service and the review
service and so on and this is just a
handful of different microservices here
we could have many more so just for this
presentation we're going to keep it
pretty simple okay
so the first architecture pattern that
we could operate where we could have
users communicate with these
microservices would be without an api
gateway
and this would be a direct
client
to microservice
i'm just going to put svc for short
communication
so in in this approach in this
architecture pattern
we have our clients speaking directly to
our micro services right so
say that
this user here
goes to the the product detail ui and
wants to look at the product info right
and see what kind of shirt they have
so that it would talk directly to this
service right here um
and then so on if you want to see the
price scene right
does another click on the ui it would go
to this microservice and so on so
this client is speaking to all these
individual services right here
and this is completely fine and this
operates really well for like a small
application but as you start to grow and
add more functionality and more services
to your product ui page
you're going to have many more calls
right api requests
and this is not ideal for that once you
start to grow so
trying to scale something like this can
be very cumbersome and be very
problematic both for the user and the
development team
so let's take a look at some of those
pitfalls that you may run into
the first one
is
too many round trips
you're probably wondering what the
hell's a round trip right well round
trip
in this instance
is discussing
going from the client
all the way to the product info service
right so again say you don't want a
black t-shirt you want a red one
and maybe instead of large you want to
get one for your child who's a youth
size
and
the price goes down
so this service will need to communicate
with this service
but it'll have to go all the way back
call the way back to the client and then
go all the way back to this pricing
service and then all the way back and so
on so as you can see there's a lot of
traffic going across the network here
and this causes a major significant
latency issue
so
the page loads very slow you're going to
have to wait it's not very user friendly
and then again the development
experience is not great for developers
because you got to maintain all this
traffic and there's just so much room
for error using this model
so another issue to think about is cross
cutting right so by cross cutting
this would be the issues dealing with um
the actual internet protocols that your
clients are using
for the most part it's most likely to be
using like https where the s would be a
security credential that you got to get
certified
but every now and then you're going to
have some server-side protocols say
something like amqp
which is advanced messaging queueing
protocol
and you're not able to do that with this
model because
you have to be consistent have the same
common functionality of all these
services right
so you're very limited with your
resource right your resource pool as far
as who can operate and make a purchase
on your site
another issue is security and this is a
big one especially nowadays as we're
seeing more and more
you know
large enterprises being hacked and so on
so
in this model all these micro services
are exposed externally right they're all
public facing so they can operate with
these clients
here so
there's a lot of room
getting hacked right here
so you have a larger footprint that's
susceptible to getting hacked and
you know ideally you would have a
central
hub that could manage that for you'd
have like a layer a barrier um to block
you from all that but
again this is just
in this model
and the last real quick pitfall i just
want to cover briefly is coupling right
so again as we we talked about
previously about the whole monolithic to
micro surface architecture right so
you're taking this large application and
you're segmenting it into smaller
microservices which is great and we've
done that here but
microservices
over time can start to become more
tightly coupled and reliant upon each
other so that's something you want to be
mindful of especially in this
architecture pattern because you have so
many communication channels going back
and forth and again like the product
info service right was relying upon
their pricing service in certain
instances
if this product info service needs to be
maintained and updated
that could be contingent on this other
pricing service if it's operating and
they could affect each other so
if one goes down another one go down it
could have
a cascade effect where you know your
services aren't operational
and then you know again it's all about
your user experience it's not ideal for
a user if one service goes down and
they're not able to operate because
another service goes down
so you really want to try to mitigate
that
so coupling is another thing to be
mindful of in this architecture pattern
so i hope this quick overview of direct
client to microservice communication
architecture has been helpful for you
again it's not a bad option if you're
just going to have one single api that's
only read only
however if you're going to scale out
your application in the future and
you're going to have much more
functionality and features added as well
as having more api requests come in then
you really want to consider implementing
an api gateway to help mitigate all
these issues we went over in the video
so again thank you so much for watching
and please don't forget to hit that
subscribe button as always thank you
if you have questions please drop us a
line below if you want to see more
videos like this in the future please
like and subscribe