Yesterday I published The Gateway Is a Tired Concept, Because Gateways Are About Power, and I will own that the headline was link baity. It did its job, the thread on LinkedIn filled up, and the best thing about it is that several people in that thread said what I was trying to say better than I did. Rob Meyer, JC De Villiers, and Mike Goerlich, taken together, get at the intent behind that piece more clearly than the piece itself, and Marius C. added the piece I left out entirely. So this is the follow-up I promised in the thread, trying to capture the essence of what they said, while also paying attention to how everyone else reacted, because the reaction is part of the story too.
Rob gets at the core of it. His read is that the problem is not the gateway, it is the organization. Organizations have an architecture too, and that org architecture was never designed for governance. Each business unit has its own charter and needs to control its own destiny to hit its own goals, and security, or the policies that make an SLA real, often are not as important to them as those goals, so they do not invest in the skills. So we overlay centers of excellence to compensate. The safest way to secure and govern APIs is to centralize, and once you build an org and give it a charter, that org slows things down. As Rob points out, this is not unique to gateways — look at data governance, application integration, and security teams in general. The gateway remains because the org problem remains. That is a much more honest way of saying what I was calling power. It is not that someone is scheming to own the chokepoint, it is that the org chart produces the chokepoint, and the gateway is where it shows up in the architecture diagram.
JC pushed back on the motive, and I think he is right to. In his experience a lot of organizations ended up with the central chokepoint not because someone wanted the control, but because the gateways of that era were heavy enough that running more than one cluster was not realistic or affordable. That is a fair correction to my framing. A lot of what I was calling a power move was a cost and weight constraint. And JC’s next point is the hopeful one: that constraint has largely gone. With platform engineering and lightweight gateways that deploy on-prem, in the cloud, or across both, teams can run their own enforcement right next to their services, and share governance artifacts like policy and standards as code. This is the evolution of the gateway I was actually calling for. Smaller, more configurable, policy-driven, owned by the team, while still participating in a federated strategy that has centralized components.
Mike gave me the phrase I wish I had started with: centralized decision layer, distributed enforcement. He spent years around gateways and still thinks they are incredibly useful, and his point is that centralized control and centralized enforcement got conflated. The gateway became the obvious place to pile things because it sat smack in the middle of the path — security, policy, routing, rate limits, transformation, analytics, governance, whatever else. All useful, all needed. But “everything has to go through here” quickly becomes both an architectural and an organizational power center. Mike does not think the answer is less control, quite the opposite, he just does not think control has to mean one technical chokepoint. The gateway should absolutely be one of the enforcement points, and a very good one, but the control should be able to follow the action rather than forcing every action through the same box. That is the whole argument in two lines, and it is better than my seven paragraphs.
Marius was the one who rejected my statement outright as unilateral, and his objection is the part I had not given enough weight to. Most developers he has encountered still have a hard time with rate limiting, proper authentication and authorization, mTLS, distributed caching, and now AI-specific needs like token-based rate limiting. The gateway delivers those capabilities to every API whether or not the developer understands them. Where we landed in the replies is that education is a must, at many levels, and that Marius is very much in favor of a decentralized runtime with centralized governance and guardrails, where the workload owns the stack or at least self-serves how it wants to package it. If you are going to push enforcement out to teams, you have to push the knowledge out with it, or you have just distributed the mess. Which is exactly the problem another commenter raised from the other side — someone who owns a federated API platform with a gateway at its center, and who sees everyone setting up their own gateway, and it is not so much federation as a giant mess. Both of those are true, and they are the same problem: distributing enforcement without distributing the education, training, and shared decisions.
The other reactions matter too, maybe more. Most of the replies I got, here and elsewhere, went straight to one of two positions — I do not want gateways, or nothing should be centralized — and neither is what I was arguing, and neither is what Rob, JC, Mike, or Marius were arguing either. One person reminded me that people gravitate towards gateways because they are an easily understandable solution to a lot of problems, and I replied that they gravitate towards power the same way. Another walked back through the XML gateway era, before the term API gateway existed, when that layer was brought in because firewalls and reverse proxies could not handle the threats at layer 7, and it looked like a firewall to the network people because it was one. All of that is real history and a real rationale. But the instinct to answer every question with either “put it all in the gateway” or “tear it all down” is precisely the centralizing pile-on I was clumsily trying to name. We reach for the one place in the middle of the path because it is the one place we understand, and then we keep adding to it until it is the bottleneck.
So here is where I land after the thread. The gateway is not bad and does not need to go away. Centralization is not bad and does not need to go away. What needs to go away is conflating the two, so that making a decision centrally means enforcing it centrally, through one box, owned by one team, that everyone else waits on. Keep the decision layer central — the policies, the standards, the rules, expressed as code that everyone can see and pull. Push the enforcement out to lightweight gateways and other points that teams own and run next to their services. Invest in the education and training that lets those teams actually own it, rather than overlaying another center of excellence to compensate for skills nobody funded. And be honest, as Rob says, that the org chart is an architecture too, and that most of what we argue about as gateway design is really an argument about how the organization is structured and who it trusts.
The trick is going to be providing smaller gateway policy tooling that domains and teams can use to express and evolve what Rob describes, implementing different patterns along the way, with a centralized effort behind it, but one that is honest about the organizational realities. That is a product, not a slogan, and I think one of the more progressive gateway providers should go build it, and probably hire Rob to define it. Thank you to everyone who showed up in the thread, including the people who told me I was wrong. You made the argument better, and you showed me which parts of it were about technology and which parts were about people.
