Hey everyone, I'm trying to wrap my head around the architecture of a simple system. I've noticed that some resources show the API Gateway positioned before the Load Balancer (LB), while others suggest the opposite. Personally, I think it makes more sense to have one API Gateway in front of multiple Load Balancers that each manage different clusters of services. The reasoning is that the API Gateway tends to be more complex and serves multiple functions, so a single instance should handle incoming requests. The way I see it, the Gateway would direct a request to the appropriate cluster, and then the Load Balancer would choose which specific service to route the request to. Does this logic hold up? Are there any counterarguments out there? Also, what's the general implementation in these cases and why is it preferred? Thanks for your insights!
3 Answers
Honestly, it's better not to get too caught up in how others design their systems unless you're really experienced. If it works for you, then it's valid. The main thing is to tackle real problems instead of dwelling on the architecture debate.
In a lot of cases, that structure you described is indeed what’s implemented. The API Gateway manages the complexities of request handling and routing before passing traffic to the load balancer, which then handles distribution among the various services. It creates a clean separation of concerns and can simplify things as your system scales.
The order really depends on the type of load balancer in question. If you're using an application load balancer (Layer 7), it's typically used alongside an API gateway. On the other hand, a network load balancer (Layer 4) is used at the edge of your infrastructure for scenarios like regional load balancing. For most high-level designs, your initial thought is quite common: an API gateway in front of an application load balancer leading to your actual services.
Fair point! But when there are conflicting recommendations, which design should I pick? That’s really tripping me up.