Apache Apisix: The high-performance cloud-native API gateway for microservice architectures

Today, organizations depend on an increasingly broad ecosystem of distributed applications and services. This increase in complexity raises a difficult question: how can a company manage and control API traffic efficiently, securely, and without interruptions? That’s where Apache APISIX comes in.

In this article, we will explore the key aspects that make Apache APISIX a leading platform in the world of API management:

• Main advantages and technical features that differentiate it from other gateways.
• Practical use cases in microservice architectures and hybrid environments.
• Comparisons with other leading API gateways on the market, such as Kong and Envoy.

Stay with us until the end of the article, as we will show examples applied in practice, as well as a testimonial from Jesús Navarro, Technical Director at Chakray Consulting Mexico.

What is Apache APISIX?

Apache APISIX is an open source API management platform designed as a modern, high-performance API gateway. Its goal is to optimize, manage, and secure API traffic in microservices-based architectures.

One of its strengths is its cloud-native approach. APISIX relies on NGINX through OpenResty (with LuaJIT) to achieve very low latencies, and offers an extensible plugin system (Lua, multi-language runtimes, and an experimental WASM runtime) for authentication, security, and observability.

The project was born in 2019, initially developed by ZhiLiu Technology, and donated to the Apache Software Foundation in October of that year; since July 15, 2020, it has been an Apache Top-Level Project. API7.ai—founded by part of the creative team—continues to invest in its evolution and community. 

Why choose Apache APISIX?

By choosing APISIX, organizations not only get a high-performance gateway, but also a platform that evolves with business needs, integrates with hybrid and multicloud environments, and supports continuous innovation through an extensible and dynamic plugin ecosystem.

APISIX distinguishes between a control plane (configuration) and a data plane (routing/proxy). In traditional mode, configuration is managed via Admin API and persisted in etcd; data plane nodes “observe” etcd and apply changes in seconds, enabling distributed clusters with real-time synchronization. 

Likewise, for scenarios without etcd, there is a standalone mode (experimental) that loads a declarative configuration (YAML/JSON) and reloads it periodically without reboots.

—You may be interested in the following article: “API Management: the best ally to accelerate your digital business”—

Key features and benefits

Before diving in, it’s important to understand the overall proposal: APISIX centralizes policies and configuration so that platform teams and product squads can work independently but under common rules. 

Its plugin hub covers everything from load balancing, canary and circuit breaking to OIDC/JWT authentication and observability with Prometheus/Grafana. All of this is activated by declarative resources (routes, services, consumers) or as an Ingress Controller in Kubernetes.

1. Advanced traffic management (load balancing, routing, and multi-protocol)

Apache APISIX is a fully dynamic gateway designed to govern traffic between clients and microservices without restarts, with rich routing policies, high-performance load balancing, and multi-protocol support (L7 and L4). This allows for gradual deployments (canary, A/B), protects upstreams with rate limits and circuit breaking, and continuously monitors service health. 

1. 1. Supported load balancing algorithms

APISIX uses the Upstream object to distribute requests among nodes following different algorithms. It supports round-robin (and weighted), chash (consistent hashing), ewma (exponential moving average based on latency), and least_conn (fewest connections). 

This allows you to choose the appropriate strategy depending on the case: uniform distribution, session affinity, dynamic latency, or long-lived connections.

• round-robin / weighted round-robin: distributes sequentially; with weights, a node with weight 2 receives ~twice as much as another with weight 1. Useful when servers have similar capacity.
• chash (consistent hashing): assigns requests with the same key (IP, cookie, header, consumer, etc.) to the same node to preserve state or cache.
• ewma: prioritizes nodes with lower observed latency, adapting to real-time variations.
• least_conn: sends to the node with the fewest active connections; useful with WebSockets or other long-connection scenarios.

In addition, Upstreams include retries, active/passive health checks, and automatic filtering of unhealthy nodes to maintain stability.

1. 2. Dynamic routing by path, host, method, and headers

Routes match requests by URI, host, method, headers, remote IP, and expressions (vars), load plugins, and forward to the corresponding upstream. APISIX offers three router options for HTTP:

• radixtree_host_uri (default): prioritizes hostname over URI; NGINX style.
• radixtree_uri: prioritizes the path (URI) over the hostname.
• radixtree_uri_with_parameter: same as above, but supports parameters in the URI. This facilitates complex scenarios (exact matches, prefixes, headers, methods, query args, etc.).

1. 3. Multi-protocol support (L7 and L4)

APISIX is not limited to HTTP/1.1:

• HTTP/2 and gRPC / gPRCS: native gRPC (HTTP/2) proxying, with paths such as /service/method and upstream grpc or grpcs. 
• gRPC-Web: grpc-web plugin for web clients; ideal when the browser does not expose HTTP/2.
• gRPC transcoding: grpc-transcode plugin to convert HTTP/JSON ↔ gRPC without touching the backend.
• WebSocket: proxying of WebSocket connections and guides for authentication during the handshake.
• HTTP/3 (QUIC): HTTP/3/QUIC support to reduce latency and improve connection resilience.
• TCP/UDP (L4): Stream Proxy to route transport traffic (LDAP, MySQL, DNS, etc.).
• MQTT: mqtt-proxy plugin, with load balancing by client_id (MQTT 3.1.* and 5.0).
• Dubbo: dubbo-proxy (and http-dubbo) plugin to publish Dubbo services via HTTP.
• Proxy Protocol (HAProxy PROXY): can be enabled in stream to preserve client IP/port after an L4 LB.
• Dynamic SSL/TLS and mTLS: certificates managed as SSL objects (via Admin API) and mTLS support; all without restarts.

In addition, APISIX synchronizes configuration in real time via etcd and supports hot reloading of plugins and configuration changes (including TLS certificates), avoiding downtime windows. Even external plugin runners include hot reloading in their guides.

Benefits: reduction of timeouts and peak errors, secure deployments of new versions with canary, and declarative routing rules that are easy to version.

2. Comprehensive security

APISIX centralizes authentication, access control, and encryption policies, which can be applied by route/service/consumer and activated on the fly. The goal: to reduce the attack surface, standardize access, and meet security requirements without rewriting microservices.

• Authentication: native plugins for API Key (key-auth) and JWT; also supports OpenID Connect via a dedicated plugin. These are configured in Consumers and enabled by route/service.
• IP control lists: whitelist/blacklist and real-ip compatibility when the gateway is behind another proxy. Useful for restricting environments, admin endpoints, or partners.
• Traffic limitation: rate limiting per consumer/key, with the option of counting in memory or at the cluster level using Redis, to absorb peaks and mitigate abuse.
• Encryption and zero trust: enables end-to-end mTLS —client↔APISIX and APISIX↔upstream— with mutual authentication. Each party presents and validates its certificate against a trusted CA, blocking unauthenticated connections. APISIX also supports mTLS with etcd to protect the control plane. It is ideal for highly compliant environments that require encryption in transit and strong identity in both directions.

3. Observability and monitoring

APISIX acts as a central observation point for API traffic and, through plugins, integrates with platforms such as Prometheus, SkyWalking, and OpenTelemetry.

Observability is based on three pillars—logs, metrics, and traces—that allow you to understand usage, performance, and security without instrumenting each microservice separately.

• Logs: Plugins such as http-logger, kafka-logger , and others send structured logs to HTTP/HTTPS or brokers for debugging and auditing.
• Metrics: The prometheus plugin exposes latencies, status codes, and counts in an endpoint for scraping and visualization (e.g., Grafana).
• Traces: Plugins for OpenTelemetry/Zipkin/SkyWalking generate and export distributed traces (OTLP/HTTP or Zipkin API) to track each request across services.

4. Extensibility with plugins

APISIX is based on a modular and dynamic plugin system that allows you to add capabilities without reboots, apply them with granularity (by route, service, consumer, or as global rules), and orchestrate them in a consistent execution flow using priorities and phases. 

This makes it easy to incorporate authentication, traffic control, transformation, logging, observability, or advanced cases (AI/LLM, MQTT, Kafka) without touching the microservices.

• Official catalog and dynamic activation. The Plugin Hub documents dozens of ready-to-use plugins (authentication, security, traffic shaping, serverless, observability, transformations, loggers, specific proxies, etc.). They are enabled and configured declaratively, with hot reloading.
• Execution order and priorities. Each plugin defines a priority to ensure a deterministic order through the phases (e.g., rewrite, access, log), even when route, consumer, and global plugins coexist.
• Multilingual runners. In addition to native plugins (using Lua), you can write them in Go or Python using plugin runners managed by APISIX as gateway threads (RPC communication via unix socket).
• WebAssembly (Proxy-Wasm). APISIX supports Wasm plugins following the Proxy-Wasm specification, enabling code portability between compatible proxies and development in different languages/SDKs.

5. Cloud-native ready

APISIX is designed to integrate naturally into cloud-native environments. It offers an Ingress Controller with CRDs to manage routes and policies as code, simplified deployments using Helm Charts, and metrics ready for Prometheus/Grafana. 

In addition, it supports dynamic service discovery (Consul, Nacos, ZooKeeper) and declarative/GitOps modes that allow you to manage the gateway without interruptions or dependencies on external tools.

• Kubernetes Ingress with CRDs. Define HTTP/TCP/UDP routes with ApisixRoute, and configure upstreams (balancing, health checks, timeouts, retries) with ApisixUpstream. The controller reconciles these resources and applies hot changes to the gateway.
• Deployment with Helm. Charts maintained by the project allow you to install APISIX, its Ingress Controller, and associated components in a single command; they include ServiceMonitor so that Prometheus can scrape metrics from the controller.
• Cloud-native observability. Ingress exposes Prometheus/Grafana-compatible metrics to monitor control plane reconciliations, latency, and errors; these are automatically enabled when deploying with Helm + Prometheus Operator.
• Service discovery. Integrates registries such as Nacos, ZooKeeper (in the control plane), and Consul to dynamically resolve backends, avoiding static lists and facilitating autoscaling.
• Declarative modes and GitOps. In file-based standalone mode, APISIX reads and monitors the  apisix.yaml file, where routes, upstreams, and plugins are defined. 

There is also API-based standalone mode, where all configuration resides in memory and is managed declaratively through the Admin API. Both approaches allow GitOps flows to be implemented, eliminating dependence on the dashboard and ensuring greater traceability and change control.

Brief comparison: APISIX vs. other API Gateways

The API Gateway ecosystem has evolved with different philosophies and priorities: some focus on high performance and extensibility, others on the depth of their integration with Kubernetes, and others on operational simplicity for less complex environments. 

Before choosing, it is important to have a clear understanding of how Apache APISIX compares to popular alternatives such as Kong Gateway, Envoy Gateway, and Traefik. 

This comparison does not seek to identify an “absolute winner,” but rather to highlight the strengths and ideal use cases for each option, so that you can identify which one best suits your architecture, scalability needs, and level of technological maturity.

Testimonial from Jesús Navarro, Technical Director at Chakray Consulting Mexico

“In our experience, Apache APISIX has allowed us to handle large volumes of traffic with very low latency and without sacrificing performance. Its architecture, based on NGINX and LuaJIT, outperforms alternatives such as Kong, making it a solid option for cloud-native and Kubernetes environments. 

The ability to extend it in multiple languages and its native integration with observability tools like Prometheus and OpenTelemetry give us the flexibility and visibility we need, with the support of a large active community and no licensing costs.”

—If you want to explore other solutions from the Apache Foundation, read the following article: “Apache Camel: The Definitive Guide to Integrating Applications and Microservices”—

Getting Started with Apache APISIX

This section provides a quick adoption roadmap: from Hello, API to operating in production.

Requirements and Quick Deployment

• Docker: the official guide explains how to run APISIX and configure config.yaml (ports 9080/9443 and Admin API on 9180 by default).
• Kubernetes (Helm): install APISIX + Dashboard + Ingress Controller from the charts repository with a couple of commands.
• Images: official images are available on Docker Hub (APISIX and Dashboard) and third-party distributions such as Bitnami.
• Deployment modes: choose between traditional, decoupled (data plane/control plane), or standalone depending on your control and blast radius needs.

Your first API in minutes

1. Create a Route to httpbin.org with Admin API (local environment):

# Assuming admin_key is configured in conf/config.yaml

curl -i -X PUT “http://127.0.0.1:9180/apisix/admin/routes/1” \

  -H “X-API-KEY: ${admin_key}” \

  -d ‘{

    “uri”: “/ip”,

    “upstream”: { “type”: “roundrobin”, “nodes”: { “httpbin.org:80”: 1 } }

  }’

• Try it out:

curl -i “http://127.0.0.1:9080/ip” -H “Host: httpbin.org”

Official guides: Configure Routes and Admin API.

On Kubernetes? Create an ApisixRoute that points to a Service (or external domain) and let the Ingress Controller synchronize the configuration: the documentation includes ready-to-copy manifests.

Some notable use cases

Below are some examples of how APISIX can be applied in specific cases. The following information can be found at Apache.org.

1. API Aggregator

Description: In this pattern, the API Gateway acts as a central point that receives a request from the client, makes calls to multiple internal services, and merges those responses (or transforms the data) to return a single coherent response to the client.

This reduces the number of calls the client must make, minimizes latency, and simplifies the client. 

Application in APISIX:

APISIX allows you to configure routes that aggregate or transform responses from multiple upstreams. You can use plugins to transform payloads and concatenate information from different services. 

This is especially useful for mobile applications or microfrontends when you want the view to consume a single endpoint, even though the data comes from different services.

API Aggregator

2. API Caching

Description: The Gateway can cache responses from upstream endpoints, so that if a request is received for a resource that has been requested recently (and is still valid), it can be responded to directly from the cache, without the need to call the backend. 

This reduces load, improves performance, and latency for clients. 

Application in APISIX:

With APISIX, you can use cache plugins to configure which routes will use cache, how long they will retain data, and under what conditions they will be invalidated. For example, you can cache common GET responses or endpoints that change infrequently, which improves response speed and reduces pressure on internal services.

API Caching

3. API Fault Handling

Description: Systems are not perfect: network failures, inaccessible services, unexpected latencies, etc. In this use case, the API Gateway supports mechanisms to handle these failures: upstream service health checks, retries, timeouts, circuit breakers, fallback, etc., to improve the overall resilience of the system. 

Application in APISIX:

APISIX includes support for health checks on upstreams, timeout configuration, and also plugins or mechanisms for circuit breakers or fault injection that allow you to test resilience. 

Thus, if a service is down or degraded, the gateway can automatically redirect traffic, return a controlled error, or use an alternative strategy (fallback), ensuring that customers have a more predictable experience.

API Fault Handling

Conclusion

Apache APISIX has established itself as one of the most comprehensive high-performance cloud-native API gateways for microservices, offering advanced traffic management, centralized security, observability, and extensibility with plugins.

Likewise, its integration with Kubernetes through CRDs and Ingress Controller makes it a key component for API governance and the adoption of DevOps and GitOps practices.

Use cases such as API Aggregator, API Caching, and API Fault Handling show how APISIX facilitates traffic management and brings direct value in performance, end-user experience, and the resilience of digital platforms.

At Chakray, we have extensive experience in implementing integration solutions, API management, and cloud-native platforms. Our team of specialists can help you:

• Design and implement an API Gateway such as APISIX tailored to your business needs.
• Optimize the security and performance of your microservices architectures.
• Integrate observability and automation to ensure more reliable and efficient operation.
• Accompany you on your journey toward modernizing your technology ecosystem, with expert advice and ongoing support.

If your organization is ready to take its APIs to the next level with Apache APISIX, contact us!