---
term: 'Arquitectura de API Gateway'
seoTitle: '¿Qué es un API Gateway? Arquitectura, Patrones y Trade-offs'
headline: '¿Qué es un API Gateway?'
slug: api-gateway
category: api-realtime
shortDefinition: 'Un API gateway es una puerta de entrada gestionada para tus APIs: un punto único que enruta, autentica y aplica rate limiting a cada solicitud.'
relatedTerms:
  - api-rate-limiting-throttling
  - microservices-vs-monolith
  - api-orchestration
  - cors-cross-origin-resource-sharing
contrastsWith:
  - api-orchestration
faq:
  - question: '¿Qué es un API gateway y cómo funciona?'
    answer: 'Es un punto de entrada único delante de tus servicios de backend. Toda solicitud llega al gateway, que autentica a quien llama, aplica rate limits, enruta al servicio correcto, opcionalmente transforma o agrega respuestas y registra datos de observabilidad — y entonces devuelve el resultado. Los clientes ven una API coherente; la topología detrás de ella permanece privada y libre de cambiar.'
  - question: '¿Cuál es la diferencia entre un API gateway y un load balancer?'
    answer: 'Capa e intención. El load balancer distribuye tráfico entre copias idénticas de un servicio, por capacidad y disponibilidad — pregunta "¿qué instancia?". El gateway toma decisiones conscientes de la API — "¿qué servicio, puede este llamador, a qué tasa, con qué transformación?". Son complementarios: el arreglo clásico pone un load balancer delante de las instancias del gateway, y los servicios detrás de ambos.'
  - question: '¿Un API gateway es solo un reverse proxy?'
    answer: 'Es uno especializado. Todo gateway es un reverse proxy — termina las solicitudes de los clientes y las reenvía hacia dentro — pero con un cerebro de políticas con forma de API: autenticación, rate limits por clave, transformación de solicitudes, agregación y observabilidad a nivel de API. Si solo necesitas reenvío y TLS, un reverse proxy común basta; el gateway se gana su lugar cuando entra la política.'
  - question: '¿Cuál es la diferencia entre un API gateway y un service mesh?'
    answer: 'La dirección del tráfico. El gateway gobierna el tráfico norte-sur — clientes entrando al sistema. El service mesh gobierna el tráfico este-oeste — servicios hablando entre sí por dentro, vía sidecars que manejan mTLS, reintentos y enrutamiento. Los sistemas grandes corren ambos; los pequeños normalmente no necesitan el mesh — y a veces tampoco el gateway.'
  - question: '¿Qué es el patrón Backend for Frontend (BFF)?'
    answer: 'Una variación del gateway: en lugar de un gateway atendiendo a todos los clientes, cada tipo de cliente — web, mobile, partners — recibe su propio gateway delgado, que moldea las respuestas a sus necesidades. Resuelve el tira y afloja en el que una API genérica atiende mal a todos, al costo de más piezas que desplegar. El BFF es el patrón de gateway admitiendo que los clientes son distintos.'
  - question: '¿Un API gateway es un punto único de falla?'
    answer: 'Arquitectónicamente sí — todo pasa por él — y por eso los gateways de producción corren como flotas clusterizadas y escaladas horizontalmente detrás de un load balancer, con health checks y failover. La mitigación es estándar; el pecado es correr la puerta-de-todo como instancia única porque funcionó bien en staging.'
  - question: '¿Un API gateway agrega latencia?'
    answer: 'Un hop, típicamente de un solo dígito de milisegundos — y a menudo una ganancia neta: la agregación colapsa varios viajes de ida y vuelta del cliente en uno, la caché responde las resolicitudes en el edge, y reutilizar conexiones hacia los backends es más rápido que las conexiones frías del cliente. La cuenta honesta compara el hop contra los viajes y el código de políticas duplicado que elimina.'
  - question: '¿Cuándo NO necesitas un API gateway?'
    answer: 'Más seguido de lo que los vendedores admiten: un solo servicio con un tipo de cliente, una app renderizada en el servidor llamando a su propio backend, APIs internas detrás de una VPN, o cualquier lugar donde un reverse proxy existente ya cubra TLS y enrutamiento. El gateway paga su costo operativo cuando hay muchos servicios, muchos clientes o política de verdad que centralizar — no antes.'
codeLanguages: [javascript, dart, swift, kotlin]
externalAuthorities:
  - name: 'API Gateway pattern — microservices.io'
    url: 'https://microservices.io/patterns/apigateway.html'
  - name: 'Backend for Frontends — Sam Newman'
    url: 'https://samnewman.io/patterns/architectural/bff/'
  - name: 'Envoy Proxy (open source)'
    url: 'https://www.envoyproxy.io/'
  - name: 'Cloud Code & backend guide'
    url: 'https://docs.parseplatform.org/parse-server/guide/'
cta:
  title: 'La puerta de entrada, ya construida'
  text: 'Back4app pone un gateway gestionado delante de cada app: autenticación, rate limits y enrutamiento hacia APIs generadas automáticamente y Cloud Code — todo impuesto en el edge de la plataforma, sin infraestructura de gateway que tengas que desplegar o escalar.'
  linkText: 'Empieza gratis'
  linkUrl: 'https://www.back4app.com/signup'
author: 'Back4app Engineering'
publishedDate: '2026-09-04'
translationKey: api-gateway-architecture
---

**Un API gateway es una puerta de entrada gestionada para tus APIs: un punto único que enruta, autentica y aplica rate limiting a cada solicitud.** La idea es la centralización: el trabajo transversal que todo endpoint necesita (quién eres, a qué tasa puedes llamar, adónde va esto, qué pasó) sale de N servicios y entra en una capa de políticas que los clientes no pueden rodear.

## Puntos clave

| Pregunta | Respuesta |
| --- | --- |
| Qué es | Un punto de entrada: enrutar, autenticar, limitar, transformar, observar |
| vs. load balancer | El LB elige una instancia; el gateway toma decisiones de política conscientes de la API |
| vs. reverse proxy | Un gateway *es* uno — con un cerebro de políticas de API acoplado |
| vs. service mesh | Gateway = norte-sur (clientes entrando); mesh = este-oeste (servicio a servicio) |
| La pregunta honesta | Si de verdad necesitas uno — muchos sistemas todavía no |

## Qué hace la puerta de entrada

La lista de tareas de un gateway, como configuración en lugar de N copias de middleware — una ruta declarativa típica:

```yaml
# ruta del gateway: una entrada, política adjunta
route: /orders/**
  service: orders-api:8080          # enrutamiento — la topología queda privada
  auth: bearer-jwt                  # autenticación en la puerta
  rate_limit: 100/min per key       # presupuestos antes de los backends
  transform:
    strip_headers: [X-Internal-*]   # traducir entre el edge y el interior
  timeout: 5s
  observe: log + trace + metrics    # un solo lugar para observarlo todo
```

Del lado del cliente, un gateway gestionado desaparece dentro del SDK — una llamada, con las revisiones de la puerta aplicadas antes de que corra cualquier código tuyo:

**JavaScript:**

```javascript
// JavaScript / Node.js — Back4app JS SDK
// One managed entry point: auth, rate limits, and routing applied per call
const receipt = await Parse.Cloud.run('placeOrder', { cartId: 'crt_812' });
// The platform's gateway verified the session, applied limits,
// and routed to the function — none of it in your code.
console.log(`Order ${receipt.orderId} confirmed`);
```

**Flutter:**

```dart
// Flutter / Dart — Back4app Flutter SDK
// One managed entry point: auth, rate limits, and routing applied per call
final function = ParseCloudFunction('placeOrder');
final response = await function.execute(parameters: {'cartId': 'crt_812'});
if (response.success) {
  print('Order ${response.result['orderId']} confirmed');
}
```

**Swift:**

```swift
// iOS / Swift — Back4app Swift SDK
// One managed entry point: auth, rate limits, and routing applied per call
ParseCloud.callFunction("placeOrder",
                        parameters: ["cartId": "crt_812"]) { result in
  if case .success(let receipt) = result {
    print("Order confirmed: \(receipt)")
  }
}
```

**Kotlin:**

```kotlin
// Android / Kotlin — Back4app Android SDK
// One managed entry point: auth, rate limits, and routing applied per call
val params = hashMapOf("cartId" to "crt_812")
ParseCloud.callFunctionInBackground<Map<String, Any>>("placeOrder", params) { receipt, e ->
  if (e == null) Log.d("Orders", "Order ${receipt["orderId"]} confirmed")
}
```

## Los cuatro parecidos, separados

| | Reverse proxy | Load balancer | **API gateway** | Service mesh |
| --- | --- | --- | --- | --- |
| Pregunta que responde | "Reenvía esto hacia dentro" | "¿Qué instancia?" | **"¿Qué servicio, puedes tú, a qué tasa?"** | "¿Cómo hablan los servicios con seguridad?" |
| Tráfico | Norte-sur | Norte-sur | **Norte-sur** | Este-oeste |
| Base de la decisión | Host/path | Salud + algoritmo | **Política de API: auth, límites, forma** | Identidad del servicio |
| Capa típica | L7 básico | L4/L7 | **L7, consciente de la API** | Sidecars por todas partes |
| Relación | Clase madre del gateway | Normalmente delante del gateway | — | Coexiste detrás de él |

```mermaid
flowchart LR
  accTitle: Arquitectura de API gateway
  accDescr: Clientes web, mobile y partners envían solicitudes a un load balancer delante de un API gateway clusterizado, que autentica, aplica rate limits y enruta hacia servicios internos; los servicios y su topología quedan privados detrás de él.
  W["Web"] --> LB["Load balancer"]
  M["Mobile"] --> LB
  P["Partners"] --> LB
  LB --> G["API gateway (clusterizado)<br/>auth · límites · enrutamiento ·<br/>transformación · observabilidad"]
  G --> S1["Servicio de pedidos"]
  G --> S2["Servicio de usuarios"]
  G --> S3["Servicio de búsqueda"]
```

La [descripción canónica del patrón](https://microservices.io/patterns/apigateway.html) agrega la variación que vale la pena conocer: el **[Backend for Frontend](https://samnewman.io/patterns/architectural/bff/)** — un gateway delgado *por tipo de cliente*, cada uno moldeando respuestas para su cliente — que cambia más piezas desplegadas por el fin de las APIs de talla única que no le quedan a nadie.

## Las desventajas, sin rodeos

El gateway centraliza poder, y la centralización te cobra de cuatro formas. **Punto único de falla:** todo fluye por él — córrelo clusterizado detrás de un load balancer o acepta que su caída es *la* caída. **El nuevo cuello de botella:** cada equipo de features ahora presenta cambios de configuración contra un componente compartido; la gobernanza y las herramientas de autoservicio son parte de la adopción, no extras. **El monolito renacido:** la lógica de agregación que se acumula en el gateway reconstruye en silencio la aplicación centralizada que descompusiste — mantenlo denso en política y delgado en lógica. **Expansión de config:** cientos de rutas con políticas por ruta son un código base; revísalas como tal. Nada de esto argumenta contra los gateways; todo argumenta contra los gateways casuales.

## Casos de uso comunes

- **Puerta de entrada de microservicios** — la historia de origen: muchos servicios, una API coherente, topología libre de evolucionar detrás de ella.
- **Productos multi-cliente** — web, mobile y partners con auth, formas y límites distintos — el territorio del BFF.
- **Monetización de APIs** — claves, planes, cuotas y medición de uso impuestos en un solo punto.
- **Migraciones** — el patrón strangler: el gateway enruta los caminos viejos al sistema legado y los nuevos a su reemplazo, de forma invisible.
- **Política de edge** — CORS, TLS, higiene de headers y [rate limiting](/glossary/es/rate-limiting-de-api/) aplicados una vez en lugar de N.

## ¿Necesitas uno? Matriz de decisión

| El gateway se gana su lugar cuando… | Sáltatelo (o postérgalo) cuando… |
| --- | --- |
| Muchos servicios viven detrás de una API | Un servicio atiende a un tipo de cliente |
| Los clientes difieren en auth, forma o límites | Un reverse proxy ya cubre TLS + enrutamiento |
| La política debe imponerse centralmente | La política está a un import de middleware de distancia |
| La topología cambia más rápido que los clientes | La topología es una sola caja |
| Alguien es dueño del gateway como producto | Nadie lo operaría |

La respuesta huérfana en la mayoría de las páginas de comparación: **todavía no** es una arquitectura legítima. Agrega la puerta cuando haya un edificio detrás de ella.

## Limitaciones y trade-offs

- **La disponibilidad ahora es la disponibilidad del gateway.** Clusterízalo, vigílalo con health checks y ensaya su falla — la mitigación es estándar y no es opcional.
- **Un hop de latencia, contabilizado con honestidad** contra los viajes de ida y vuelta y el middleware duplicado que elimina; mide, no supongas en ninguna dirección.
- **La agregación es una pendiente.** Componer respuestas es legítimo; la lógica de negocio en el gateway es el patrón ESB con un gafete nuevo.
- **Las opciones open-source cargan operación.** Existen gateways excelentes en open source (stacks basados en Envoy y pares) — cada uno es un sistema distribuido que ahora corres, actualizas y proteges.
- **Los gateways gestionados cambian control por silencio.** La puerta operada por la plataforma es la respuesta correcta exactamente cuando operar el gateway sería trabajo pesado sin diferencial.

## El gateway en Back4app

Back4app es una plataforma open-source de Backend as a Service (BaaS) que combina base de datos gestionada, APIs REST y GraphQL generadas automáticamente, autenticación, almacenamiento de archivos y funciones serverless con Cloud Code. La capa de gateway viene con la plataforma: toda solicitud — REST, GraphQL, SDK o llamada a Cloud Code, como en las pestañas de código de arriba — entra por un edge gestionado que autentica sesiones y claves, aplica rate limits por app y enruta hacia las APIs generadas o tus funciones, con la plataforma operando el clustering y el escalado que hacen segura una puerta de entrada. La matriz de decisión colapsa: obtienes las garantías del gateway desde el primer día, y te saltas por completo ser dueño de la puerta.