Awesome!!! In one video I learnt lot new things. I got about idea about the services. Thanks Keep posting like this End to End. My Suggestion Make series End-to-End under this heading post like these kind of videos.
I really loved it. Loved the animation, and the information. But If you could make it into a playlist or a single video itself wherein you describe all the components, its nuances, their effects on the lifecycle, the bottlenecks, current market players and the tradeoffs between them, best industry practices, a bit of history and every component and its evolution to current form, average response time and processing required for each component, alternatives, currrent big tech faang analogy between these components and the crazy ways they handle and solve the scaling problems. And that too in a systematic manner. That's just a few to name, but the issue is, everybody wants to know all of this and much more, but there is no single solution and most of the videos over the net provide just the same high level overview of these topics every single time. but a dedicated playlist going completely in depth would be really helpful. There can be short videos cut out from those long videos for people who just want some sort of revision on those topics. I know this is a huge task and would take a lot of time and lot of study on your side as well. but if done, i know really that that playlist would be among the most watched ones. Apart from this, really love your content and appreciate it. Keep doing this awesome work. I just said all of this because somewhere I have this expectation that if I see this in-depth playlist then I wouldn't need to go anywhere else from there to understand these topics. a final one-stop solution.
Thanks so much for the detailed feedback and kind words-I really appreciate it! You're absolutely right, there’s a real demand for that level of in-depth, comprehensive content that ties everything together systematically. Covering each component, its trade-offs, industry best practices, and how big tech tackles scaling problems is no small task, but it's definitely something worth pursuing. I’ve been working toward build detailed playlists, and this approach aligns perfectly with that vision. In fact I have been building multiple playlists which you will find in my description. However, It’ll take some time to research and break down everything step by step, but I totally see the value in it. Thanks again for the support! I'll definitely look into making this happen! Stay tuned!
@@ByteMonk I am really enthralled that you replied and more that you agree to making such playlist happen soon. So, I guess all that's left is subscribe, turn all notifs and wait. Really appreciate your animation and way of explaining
Is it better using api gateway first(even third-party like apigee) or ALB first in the flow. I feel if apigee comes first, it takes care of authorization/authentication then the ALB can takes care of routing based on scaled instances
I was looking for this comment. For me, it does not make sense to put an API gateway behind a load balancer, because you don't need need to balance traffic to more than one API gateway. On the other hand, I can see how it can make sense to put a load balancer behind an API gateway-that is if the request handling needs to be distributed over a set of nodes, such as an auto-scaling group of EC2 instances.
Replied the same to another comment. it depends on the architecture and how traffic flows. In many setups, the Load Balancer (L4/L7) comes first, distributing traffic across API Gateway instances to ensure scalability and availability. After that, the API Gateway handles things like routing, authentication, rate limiting, and more. So, typically, the Load Balancer comes first to manage traffic, followed by the API Gateway for additional API-specific logic. Thanks for bringing this up!
@@ByteMonk thanks for replying. I didn't know this setup is as common as you say it is, and I'm finding it hard to search the web to study more about this design pattern. Can you give us an idea about how a single API Gateway instance can become unreliable enough to warrant multiple instances and a load balancer? I had assumed scalability and availability are built into the API Gateway service by AWS.
@@_imawesome You're welcome! It’s actually a pretty common setup, especially in larger systems where reliability and scalability are critical. Even though API Gateway is reliable, any single point of failure can be a risk. By placing multiple API Gateway instances behind a load balancer, you add an extra layer of redundancy. If one instance goes down, traffic is automatically routed to others, minimizing downtime. For extremely high-traffic systems, a load balancer distributes the traffic across multiple API Gateway instances, ensuring no single instance becomes a bottleneck, and If you're serving users globally, having API Gateways in different regions and balancing traffic can reduce latency by routing users to the closest API Gateway instance.utilize a combination of API Gateways and load balancers to handle large amounts of traffic while routing users to the nearest available service instance, preventing overload on a single API Gateway. Netflix utilize a combination of API Gateways and loasd balancers to handle large amounts of traffic while routing users to the nearest available service instance, preventing overload on a single API Gateway. AWS itself applies load balancing to distribute requests between different regions and availability zones to ensure maximum reliability. We follow the same architecture pattern at my current job :)
It would be interesting to zoom into the frontend part as well, from clicking the button to DOM element detection, event handler, creating the request sending it to the server, there can be REST, GraphQL etc. JS event loop and waiting for the asyc request to complete, then the response part being parsed which may be HTML/CSS or JSON, which will be converted to the content that will be visible on the screen ready for interaction again.
Excellent. I wonder if the api gateway should be switched around with alb. Isn’t api throttling done before the request is sent to a specific application? Also , in a microservice architecture, where there may be several instances of an application running , is the alb aware of which instance should receive the request ? Or is the container orchestration coordinating that ?
In most setups, the API Gateway typically comes after the Application Load Balancer (ALB), but you’re right-it could work the other way around. If throttling, authentication, or authorization is a priority right from the start, you might place the API Gateway in front, so those checks happen before the traffic hits the ALB. That way, you’re filtering requests early on, which can save backend resources. As for routing in a microservices setup, the ALB does indeed have awareness of which instance to route a request to, but its awareness is limited to instances registered with it. For containerized applications, container orchestration platforms like Kubernetes(ECS, Fargate, DockerSwarm) often handle this routing. They coordinate scaling, load balancing, and distribution of requests among container instances. The ALB generally routes traffic to a service endpoint or load-balancing layer within the orchestration environment, which then directs it to the right pod or container instance. So, the ALB handles the initial distribution to a service endpoint, while the container orchestrator coordinates specific instance-level routing!
Just curious-why put API Gateway after ALB? Wouldn't it make more sense to handle rate limiting, throttling, or authentication before reaching the ALB?
Hy bytemonk , following your yt long time can you go deep down into AWS a bit how things work there and let us know about some important services quite of them u mentioned in this video
Actually, it depends on the architecture and how traffic flows. In many setups, the Load Balancer (L4/L7) comes first, distributing traffic across API Gateway instances to ensure scalability and availability. After that, the API Gateway handles things like routing, authentication, rate limiting, and more. So, typically, the Load Balancer comes first to manage traffic, followed by the API Gateway for additional API-specific logic. Thanks for bringing this up!
Yeah, I have been struggling to get the audio right. I’ll work on adjusting the audio in future videos to boost the high end and improve clarity. Thanks again for the tip!
yeah, they are distractions which I didn't realize during the final edit(I listen to each video multiple times before publishing, so my ears get used to the sounds and didn't realize) We will keep them subtle. Thank you for the feedback!
finally someone(you) made a video of the full workflow of web apps..thanks man..
Glad this was helpful for you!
the best, clear and most easy understandable blueprint I meet
Thank you for the awesome feedback!
Finally found something I was looking for. Awesome presentation & explanation. Really appreciate great work!
Thanks so much! Glad you found it helpful!
Great explanation! I'd love to see a really in-depth explanation of Prometheus, if you are able to.
I just discovered this channel and its amazing !!!! I am literally watching the videos for fun and not for some interview!Keep up the good work !!
very explanatory and visually appealing content. Thanks :)
It's Great man 👌👌 Finally found something I was looking for..
Appreciate the support 🙂
the explanation is simply phenomenal 🔥🔥
Awesome!!! In one video I learnt lot new things. I got about idea about the services. Thanks Keep posting like this End to End. My Suggestion Make series End-to-End under this heading post like these kind of videos.
I’m glad you found the video helpful and learned something new. I have been building multiple playlists which you will find in my description.
Great explanation on web application architecture!
Greate Job really !!! thank you and keep going with similar videos
THE BEST VIDEOOOO THANK YOUUU
In a nutshell. Great work man !!
Brilliant , Superb loved you efforts . thanks so much
Wonderful explaination
As someone said, please do one for mail servers, great video as always
I really loved it. Loved the animation, and the information. But If you could make it into a playlist or a single video itself wherein you describe all the components, its nuances, their effects on the lifecycle, the bottlenecks, current market players and the tradeoffs between them, best industry practices, a bit of history and every component and its evolution to current form, average response time and processing required for each component, alternatives, currrent big tech faang analogy between these components and the crazy ways they handle and solve the scaling problems. And that too in a systematic manner.
That's just a few to name, but the issue is, everybody wants to know all of this and much more, but there is no single solution and most of the videos over the net provide just the same high level overview of these topics every single time. but a dedicated playlist going completely in depth would be really helpful. There can be short videos cut out from those long videos for people who just want some sort of revision on those topics.
I know this is a huge task and would take a lot of time and lot of study on your side as well. but if done, i know really that that playlist would be among the most watched ones.
Apart from this, really love your content and appreciate it. Keep doing this awesome work. I just said all of this because somewhere I have this expectation that if I see this in-depth playlist then I wouldn't need to go anywhere else from there to understand these topics. a final one-stop solution.
Thanks so much for the detailed feedback and kind words-I really appreciate it! You're absolutely right, there’s a real demand for that level of in-depth, comprehensive content that ties everything together systematically. Covering each component, its trade-offs, industry best practices, and how big tech tackles scaling problems is no small task, but it's definitely something worth pursuing. I’ve been working toward build detailed playlists, and this approach aligns perfectly with that vision.
In fact I have been building multiple playlists which you will find in my description. However, It’ll take some time to research and break down everything step by step, but I totally see the value in it. Thanks again for the support! I'll definitely look into making this happen! Stay tuned!
@@ByteMonk I am really enthralled that you replied and more that you agree to making such playlist happen soon. So, I guess all that's left is subscribe, turn all notifs and wait.
Really appreciate your animation and way of explaining
Great explanation
Excellent video
Valueble video.. thanks❤❤❤
Nice video and articulation. Good job
Nice.... please make and upload more videos on this deeply with goland and JavaScript etc
Jp Here, Thank you ByteMonk :)
There are still a lot for me to learn in full stack development.
Nice one!
Thank you for the helpful content. I would like to know more abouy ALB and NLB with some examples, thank you in advance
Is it better using api gateway first(even third-party like apigee) or ALB first in the flow. I feel if apigee comes first, it takes care of authorization/authentication then the ALB can takes care of routing based on scaled instances
I was looking for this comment. For me, it does not make sense to put an API gateway behind a load balancer, because you don't need need to balance traffic to more than one API gateway. On the other hand, I can see how it can make sense to put a load balancer behind an API gateway-that is if the request handling needs to be distributed over a set of nodes, such as an auto-scaling group of EC2 instances.
Replied the same to another comment. it depends on the architecture and how traffic flows. In many setups, the Load Balancer (L4/L7) comes first, distributing traffic across API Gateway instances to ensure scalability and availability. After that, the API Gateway handles things like routing, authentication, rate limiting, and more. So, typically, the Load Balancer comes first to manage traffic, followed by the API Gateway for additional API-specific logic. Thanks for bringing this up!
@@ByteMonk thanks for replying. I didn't know this setup is as common as you say it is, and I'm finding it hard to search the web to study more about this design pattern.
Can you give us an idea about how a single API Gateway instance can become unreliable enough to warrant multiple instances and a load balancer? I had assumed scalability and availability are built into the API Gateway service by AWS.
@@_imawesome You're welcome! It’s actually a pretty common setup, especially in larger systems where reliability and scalability are critical.
Even though API Gateway is reliable, any single point of failure can be a risk. By placing multiple API Gateway instances behind a load balancer, you add an extra layer of redundancy. If one instance goes down, traffic is automatically routed to others, minimizing downtime.
For extremely high-traffic systems, a load balancer distributes the traffic across multiple API Gateway instances, ensuring no single instance becomes a bottleneck, and If you're serving users globally, having API Gateways in different regions and balancing traffic can reduce latency by routing users to the closest API Gateway instance.utilize a combination of API Gateways and load balancers to handle large amounts of traffic while routing users to the nearest available service instance, preventing overload on a single API Gateway.
Netflix utilize a combination of API Gateways and loasd balancers to handle large amounts of traffic while routing users to the nearest available service instance, preventing overload on a single API Gateway. AWS itself applies load balancing to distribute requests between different regions and availability zones to ensure maximum reliability. We follow the same architecture pattern at my current job :)
It would be interesting to zoom into the frontend part as well, from clicking the button to DOM element detection, event handler, creating the request sending it to the server, there can be REST, GraphQL etc.
JS event loop and waiting for the asyc request to complete, then the response part being parsed which may be HTML/CSS or JSON, which will be converted to the content that will be visible on the screen ready for interaction again.
Great point, I'll explore the front-end lifecycle in a future video!
Super content
wow very nice bro thx
Hey, can you make this for mail server ? It would be great because there is no such content available
will look into it, thank you!
Excellent. I wonder if the api gateway should be switched around with alb. Isn’t api throttling done before the request is sent to a specific application? Also , in a microservice architecture, where there may be several instances of an application running , is the alb aware of which instance should receive the request ? Or is the container orchestration coordinating that ?
In most setups, the API Gateway typically comes after the Application Load Balancer (ALB), but you’re right-it could work the other way around. If throttling, authentication, or authorization is a priority right from the start, you might place the API Gateway in front, so those checks happen before the traffic hits the ALB. That way, you’re filtering requests early on, which can save backend resources.
As for routing in a microservices setup, the ALB does indeed have awareness of which instance to route a request to, but its awareness is limited to instances registered with it. For containerized applications, container orchestration platforms like Kubernetes(ECS, Fargate, DockerSwarm) often handle this routing. They coordinate scaling, load balancing, and distribution of requests among container instances. The ALB generally routes traffic to a service endpoint or load-balancing layer within the orchestration environment, which then directs it to the right pod or container instance.
So, the ALB handles the initial distribution to a service endpoint, while the container orchestrator coordinates specific instance-level routing!
@ thanks - that was helpful!
Hey nice video
Which tool you are using for diagrams.and video presentation??
Subscribed..!!!!
Just curious-why put API Gateway after ALB? Wouldn't it make more sense to handle rate limiting, throttling, or authentication before reaching the ALB?
More details on reverse proxy and kafka would be great. Thanks
checkout my playlists in description please, you will find both the videos. Kafka especially, I have covered extensively
Great sir. I have a question. Which tools you used for creating this animation video?
depends on the video, there are plenty I use, from Adobe to FCP , will add links to them in future
How I can connect with you
Good content brother. May be you should focus on articulation. What is your presentation stack ?
thank you for the feedback, can you please pinpoint the specifics on the articulation with example, is it the accent, pronunciation or something else?
Great presentation
But our flow is API GW --> ALB --> Micro Servces
Bhai, Aevy ka cohort kiye ho kya?
Great👍
can you also make this kind of architecture without using cloud services
from which app you made this transition
Hy bytemonk , following your yt long time can you go deep down into AWS a bit how things work there and let us know about some important services quite of them u mentioned in this video
Thank you for following the channel :). I have had thought about it and will be one of my priorities in 2025. Stay tuned.
can u implement a full fledged web app from absolute zero to END... please 🙏
In which software......i shold make this type of video
Excellent content,
But could have been a bit slow, may be you might have planned to make the video short
firsr API gateway will come and then load balancer (L4 / L7)
Actually, it depends on the architecture and how traffic flows. In many setups, the Load Balancer (L4/L7) comes first, distributing traffic across API Gateway instances to ensure scalability and availability. After that, the API Gateway handles things like routing, authentication, rate limiting, and more. So, typically, the Load Balancer comes first to manage traffic, followed by the API Gateway for additional API-specific logic. Thanks for bringing this up!
Your voice have high low end that making the audio muddy please increase some high end in your voice so that Clarity will enhanced
Yeah, I have been struggling to get the audio right. I’ll work on adjusting the audio in future videos to boost the high end and improve clarity. Thanks again for the tip!
Those frequent pluck, click, and sshhh sounds are so annoying, but content is good.
Yeah they should have low volume
yeah, they are distractions which I didn't realize during the final edit(I listen to each video multiple times before publishing, so my ears get used to the sounds and didn't realize) We will keep them subtle. Thank you for the feedback!
@@ByteMonkmaybe do sounds at the end of the editing process?
That is what works for me
creating mess
Hi sir is there a way to contact you.
Great explanation