{"id":11618,"date":"2026-08-18T15:18:08","date_gmt":"2026-08-18T13:18:08","guid":{"rendered":"https:\/\/www.scaleuptech.com\/de\/?p=6198"},"modified":"2026-08-18T15:42:48","modified_gmt":"2026-08-18T13:42:48","slug":"api-gateway-vs-service-mesh-vs-message-queue","status":"publish","type":"post","link":"https:\/\/www.scaleuptech.com\/en\/blog\/api-gateway-vs-service-mesh-vs-message-queue\/","title":{"rendered":"API gateway vs. service mesh vs. message queue - when do I use what?"},"content":{"rendered":"

Note: This post was first published in March 2020 and has since been thoroughly revised to incorporate recent developments such as the Kubernetes Gateway API and eBPF-based service meshes.<\/em>obtain.<\/p>\n\n\n\n

Microservices solve one problem, but they also create a new one: Once the monolithic application has been broken down into many small services, it must be determined how these services communicate with each other and with the outside world. Anyone making this decision for their cluster will almost inevitably end up with three components: an API gateway, a service mesh, and a message queue. In most cases, however, it\u2019s not an either-or decision. Many DevOps teams use a combination of these approaches\u2014for example, an API gateway for incoming traffic from outside, a service mesh for communication between services, and a message queue for asynchronous tasks. This article categorizes the three concepts, highlights their overlaps, and provides guidance on when to use each component.<\/p>\n\n\n\n

What is actually the problem?<\/strong><\/h3>\n\n\n\n

Here is a brief analysis of the problem: For microservices to function as a distributed system, they must overcome a long list of challenges.<\/p>\n\n\n\n

Elasticity<\/strong>
There can be dozens or even hundreds of instances of a particular microservice, any of which can fail at any given time\u2014for example, due to a node restart, an out-of-memory error, or a failed deployment. A system that doesn\u2019t account for this will bring down the entire request with every single failure. Elasticity means: The failed payment service pod simply disappears from the list of responsive instances, and a new one takes over\u2014without the calling application even noticing.<\/p>\n\n\n\n

Load balancing and automatic scaling<\/strong>
With potentially hundreds of endpoints capable of handling a request, routing and scaling are anything but trivial. It\u2019s not enough to simply distribute requests on a round-robin basis: An instance that is currently processing a computationally intensive request should receive new requests less frequently than one that is currently idle. More precise routing and scaling decisions\u2014such as those based on current load rather than a fixed distribution\u2014are among the most effective ways to control costs in large-scale architectures.<\/p>\n\n\n\n

Service detection<\/strong>
The more distributed an application is, the harder it becomes to determine which instances of a service currently exist and are accessible\u2014pod IP addresses change with every restart. Service discovery solves this by having services register under a stable name (e.g.,. payment service<\/code>) rather than under a fixed IP address, and a directory that continuously resolves this name to the currently active instances.<\/p>\n\n\n\n

Tracking and monitoring<\/strong>
In a microservices architecture, a single user request can pass through multiple services\u2014for example, a purchase process might go through the auth service, payment service, inventory service, and notification service in succession. If something goes wrong anywhere in this chain, it is nearly impossible to determine which of the four services caused the problem without end-to-end tracing. Distributed tracing links all the steps of a request via a common trace ID, allowing the entire path to be reconstructed afterward.<\/p>\n\n\n\n

Versioning<\/strong>
As systems grow, APIs must be further developed without breaking existing consumers\u2014another team that's still working against \/api\/v1\/orders<\/code> work must not suddenly come to nothing just because, internally, it has long since \/api\/v2\/orders<\/code> is in use. As a result, multiple API versions often need to be offered in parallel and phased out with a clear end date (deprecation), rather than rolling out breaking changes without warning.<\/p>\n\n\n\n

The solutions<\/h2>\n\n\n\n

In this article, we present the three key approaches to solving these problems: service meshes, API gateways (including their Kubernetes-native variant, the Gateway API), and message queues. Of course, there are also a number of other approaches that could be used, ranging from simple static load balancing via fixed IP addresses to central orchestration servers. In this post, however, we\u2019ll focus on the most popular and, in many respects, the most sophisticated options.<\/p>\n\n\n\n

API Gateways<\/strong><\/h3>\n\n\n\n
\"API<\/a>
API Gateway - Graphic from arcentry.com<\/figcaption><\/figure>\n\n\n\n

An API gateway is the big brother of the good old reverse proxy for HTTP calls. It is a scalable server, normally connected to the Internet, that can receive requests from both the public Internet and internal services and route them to the most appropriate microservice instance. API gateways provide a number of helpful features, including load balancing and integrity checks, API versioning and routing, request validation and authorization, data transformation, analysis, logging, SSL termination, and more. Examples of popular open source API gateways include. Kong<\/a> or Tyk<\/a>. Most cloud providers also offer their own implementation, such as AWS API Gateway, Azure API Management, or Google Cloud Endpoints.<\/p>\n\n\n\n

The advantages
<\/strong> API gateways offer powerful features, are comparatively low in complexity, and are easy for seasoned web veterans to understand. They provide solid protection against the public Internet and perform many repetitive tasks such as user authentication or data validation.<\/p>\n\n\n\n

The disadvantages<\/strong>
API gateways are fairly centralized. They can be deployed in a horizontally scalable manner. However, unlike service meshes, new APIs have to be registered or the configuration changed at a central location. From an organizational perspective, they should therefore also only be managed by one team.<\/p>\n\n\n\n

Kubernetes-native variant: Gateway API<\/strong>
Running microservices on Kubernetes is now virtually impossible without using another feature: the Gateway API. It is the official successor to the classic Kubernetes Ingress object and addresses its biggest weakness: the reliance on controller-specific annotations. These annotations are not portable between different Ingress controllers. The core resources of the Gateway API\u2014GatewayClass, Gateway, HTTPRoute, GRPCRoute, TLSRoute, and ReferenceGrant\u2014have reached \u201eGeneral Availability\u201d (GA) status and are considered production-ready. Of particular note: The Ingress NGINX controller, which is used in many clusters, has been officially retired since March 2026. Several highly critical CVEs (including one with a CVSS score of 8.8) have already been published for the abandoned codebase, for which no further patches will be released. Anyone still running on classic Ingress should therefore plan to migrate to the Gateway API to avoid continuing to operate without security updates.<\/p>\n\n\n\n

Service meshes<\/strong><\/h3>\n\n\n\n
\"Service<\/a>
Service mesh - graphic by arcentry.com<\/figcaption><\/figure>\n\n\n\n

Service meshes are decentralized, self-organizing networks between microservice instances that handle load balancing, endpoint discovery, integrity checks, monitoring, and tracing. They operate by adding a small agent to each instance, called a \"sidecar.\" The service mesh mediates traffic and registration of instances, handles metrics collection and maintenance. While most service meshes are conceptually decentralized, they have one or more centralized elements to collect data or provide admin interfaces. Popular service mesh examples include Istio, Linkerd, or Hashicorp's Consul.<\/p>\n\n\n\n

Advantages<\/strong>
Service meshes are more dynamic and can easily change shape to accommodate new features and endpoints. Their decentralized nature makes it easier to work on microservices in isolated teams.<\/p>\n\n\n\n

Disadvantages<\/strong>
Service meshes are based on many moving parts and can therefore become very complex very quickly. For example, fully leveraging Istio requires deploying a separate traffic manager, telemetry collector, certificate manager, and sidecar process for each node. They are also a relatively recent development for something that should form the backbone of your IT architecture.<\/p>\n\n\n\n

The Next Step: Sidecar-Free Meshes<\/strong>
The main criticism of the classic sidecar model\u2014an additional proxy process per pod that consumes resources and increases latency (see comparison table)\u2014is now addressed by eBPF-based approaches. eBPF (extended Berkeley Packet Filter) allows network logic to be executed directly in the Linux kernel instead of running it in a separate sidecar process per pod. Cilium Service Mesh uses this for a sidecar-less approach at the node level. Istio itself also offers, with Ambient Mesh<\/strong> now supports an operating mode that does not require a sidecar per pod. For new clusters, the following approach is therefore increasingly recommended: Use Cilium as the CNI (Container Network Interface), test its native mesh capabilities with Hubble for observability\u2014and only add a separate mesh layer like Istio if additional needs arise, rather than assuming it\u2019s required from the outset.<\/p>\n\n\n\n

Message queues<\/strong><\/h3>\n\n\n\n
\"Message<\/a>
Message Queue - Graphic from arcentry.com<\/figcaption><\/figure>\n\n\n\n

At first glance, comparing service meshes to a message queue seems like comparing apples to oranges: They are completely different things, but they solve the same problem, albeit in very different ways.<\/p>\n\n\n\n

With a message queue, you can establish complex communication patterns between services by decoupling senders and receivers. You accomplish this using a number of measures, such as topic-based routing or publish-subscribe messaging, as well as buffered processing, which makes it easier for multiple instances to handle different aspects of a task over time.<\/p>\n\n\n\n

Message queues have been around for ages, resulting in a wide range of options: Popular open-source alternatives include Apache Kafka, AMQP brokers such as RabbitMQ, and Apache ActiveMQ Artemis. However, they are also provided by the respective cloud providers.<\/p>\n\n\n\n

Advantages<\/strong>
Simply decoupling senders and receivers is an effective concept that eliminates the need for a number of other concepts such as integrity checks, routing, endpoint detection, or load balancing. Instances can select relevant tasks from a buffered queue as soon as they are ready. This is particularly effective when automatic orchestration and scaling decisions are based on the number of messages in each queue, resulting in resource-efficient systems.<\/p>\n\n\n\n

Disadvantages<\/strong>
Message queues are not good at request \/ response communication. Some allow you to match this to existing concepts, but it is not really what they are made for. Because of their buffering, they can also add significant latency to a system. They are also quite centralized (although horizontally scalable) and can be quite expensive on a large scale.<\/p>\n\n\n\n

Comparison Table<\/h4>\n\n\n\n
Criterion<\/strong><\/td>API Gateway<\/strong><\/td>Service mesh<\/strong><\/td>Message Queue<\/strong><\/td><\/tr>
Traffic Direction<\/td>external \u2192 internal<\/td>Service-to-Service<\/td>Asynchronous, decoupled<\/td><\/tr>
Architecture<\/td>Central Reverse Proxy<\/td>Decentralized, one sidecar per instance<\/td>Central Broker<\/td><\/tr>
Typical Applications<\/td>Securing & Routing Public APIs<\/td>Monitoring & Managing Internal Communication<\/td>Process Tasks on a Delayed Basis<\/td><\/tr>
Operating Expenses<\/td>Medium<\/td>High<\/td>Low \u2013 medium<\/td><\/tr>
Scaling<\/td>Horizontal, centrally managed<\/td>Self-organizing<\/td>Horizontal (which can be expensive on a large scale)<\/td><\/tr>
Suitable for request\/response<\/td>Yes<\/td>Yes<\/td>No (Buffering\/Latency)<\/td><\/tr>
Latency<\/td>An extra hop (Edge)<\/td>Additional hop per call (sidecar), reduced with Ambient Mesh<\/td>Higher thanks to buffering, but decoupled<\/td><\/tr>
Security \/ mTLS<\/td>TLS Termination, Authentication\/Authorization at the Edge<\/td>mTLS is often built in natively between services (internal Zero Trust)<\/td>Transport Encryption, Access Control at the Broker Level<\/td><\/tr>
Sample Tools<\/td>Kong, Tyk, Gateway API, AWS API Gateway<\/td>Istio, Linkerd, Consul, Cilium<\/td>Kafka, RabbitMQ, SQS, Pub\/Sub<\/td><\/tr>
Team Model<\/td>A central team<\/td>One isolated team per service is possible<\/td>Centrally managed<\/td><\/tr><\/tbody><\/table><\/figure>\n\n\n\n

With classic sidecar mesh (Istio with Envoy sidecar), the following occur: two additional hops<\/strong> per call (sending a sidecar + receiving a sidecar), not just one. With Ambient Mesh, this is partially eliminated due to the split node-proxy architecture.<\/p>\n\n\n\n

So, when should you choose which solution?<\/strong>
Actually, this is not necessarily an either-or decision. In fact, it may make perfect sense to provide the publicly available API with an API gateway, run a service mesh for inter-service communication, and support things with a message queue for asynchronous task scheduling. A service mesh can work with an API gateway to efficiently accept external traffic and then effectively forward that traffic once it is on the network. The combination of these technologies can be a powerful way to ensure application availability and resiliency while ensuring that your applications can be used with ease.<\/p>\n\n\n\n

In a deployment with an API gateway and a service mesh, incoming traffic from outside the cluster is routed first through the API gateway and then into the mesh. The API gateway can handle authentication, edge routing, and other edge functions, while the service mesh provides detailed observation and control of your architecture.<\/p>\n\n\n\n

However, if you want to focus only on communication between services, one possible answer could be:<\/p>\n\n\n\n