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 :)
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!
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, 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 found something I was looking for. Awesome presentation & explanation. Really appreciate great work!
finally someone(you) made a video of the full workflow of web apps..thanks man..
Glad this was helpful for you!
Great explanation! I'd love to see a really in-depth explanation of Prometheus, if you are able to.
Valueble video.. thanks❤❤❤
very explanatory and visually appealing content. Thanks :)
Great explanation on web application architecture!
Great explanation
Wonderful explaination
Nice.... please make and upload more videos on this deeply with goland and JavaScript etc
Excellent video
Jp Here, Thank you ByteMonk :)
Greate Job really !!! thank you and keep going with similar videos
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.
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
Nice one!
Super content
Subscribed..!!!!
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?
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 :)
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
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!
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!
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!
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!