Práctica: Añadir middleware de rate limiting a tu API

En esta lección práctica, nos sumergiremos en la implementación de un componente crítico para cualquier API pública o de alto consumo: el rate limiting o límite de tasa. Moverás tu API de Go más allá de la funcionalidad básica, protegiéndola contra abusos, garantizando equidad en el uso de recursos y preparando el terreno para estrategias de monetización. Utilizaremos la biblioteca go-rate-limiter, una solución robusta y flexible que se integra perfectamente con Gorilla/Mux y es ideal para entornos distribuidos.

El rate limiting no es un lujo, es una necesidad. Sin él, un solo cliente malintencionado o un error en un script de cliente puede saturar tus microservicios, degradando el servicio para todos los demás usuarios y generando costos inesperados. Implementarás un limitador que funciona en memoria para desarrollo y que puede ser extendido a usar almacenes como Redis para producción, dando un salto importante en la madurez de tu aplicación.

Concepto Clave: El Guardián de la Puerta Inteligente

Imagina que tu API es un club exclusivo con recursos limitados: un número finito de mesas (ancho de banda del servidor), camareros (procesadores de CPU) y bebidas (memoria RAM). El rate limiting actúa como el guardia de seguridad en la entrada. No prohíbe la entrada a nadie, pero aplica reglas de fair play. Por ejemplo, podría decidir que un mismo grupo (dirección IP o usuario) no puede entrar más de 100 veces en una hora (límite de solicitudes por ventana de tiempo). Si alguien intenta colarse demasiadas veces, el guardia (el middleware) le dice amablemente pero con firmeza: "Disculpe, debe esperar un momento" (respuesta HTTP 429 Too Many Requests).

Este guardián no solo previene peleas por los recursos (ataques de denegación de servicio), sino que también garantiza que todos los invitados (clientes) tengan una experiencia aceptable. En el mundo de los microservicios, este guardián debe ser rápido (para no añadir latencia), justo y capaz de recordar quién ha entrado y cuándo, incluso si hay múltiples puertas (varias instancias del servidor). Ahí es donde entra el uso de almacenes de datos externos como Redis para un limitador distribuido.

Cómo Funciona en la Práctica: El Algoritmo Token Bucket

Implementaremos el rate limiting utilizando el popular algoritmo Token Bucket (Cubo de Fichas). Visualiza un cubo que puede contener un número máximo de fichas (por ejemplo, 100). Este cubo se rellena constantemente a una tasa fija (por ejemplo, 10 fichas por segundo). Cada vez que un cliente realiza una solicitud a la API, debe tomar una ficha del cubo. Si el cubo tiene fichas disponibles, la solicitud se procesa normalmente y se resta una ficha. Si el cubo está vacío, la solicitud es rechazada inmediatamente con un código de estado 429. La belleza de este modelo está en su simplicidad y en que permite ráfagas cortas de tráfico (hasta la capacidad total del cubo) mientras se regula la tasa promedio a largo plazo.

En nuestro caso, usaremos la implementación proporcionada por go-rate-limiter. Configuraremos un limiter por IP. Esto significa que cada dirección IP cliente tendrá su propio "cubo" virtual de fichas. Cuando un request llega al middleware, este extrae la IP del cliente de la petición HTTP, consulta el estado de su cubo en el almacén (en memoria para esta práctica), decrementa una ficha si es posible y, según el resultado, permite que la solicitud continúe hacia el router o la rechaza. Todo esto ocurre en milisegundos, antes de que tu handler real ejecute cualquier lógica de negocio, protegiendo así recursos valiosos.

Tip: La elección de la "clave" de limitación (IP, API Key, ID de usuario) es crucial. Limitar por IP es común pero puede afectar a usuarios detrás de un NAT (como una oficina). Para APIs con autenticación, limitar por API Key o ID de usuario es más justo y granular.

Código en Acción: Implementación Paso a Paso

Comencemos por extender la estructura de nuestro proyecto. Asumiremos que ya tienes un proyecto Go con Gorilla/Mux configurado. Primero, necesitamos añadir la dependencia de nuestro limitador. Ejecuta en tu terminal: go get github.com/go-rate-limiter/rate-limiter. Asegúrate de que tu módulo Go esté inicializado. Ahora, crearemos un archivo dedicado para la configuración del middleware, por ejemplo, middleware/ratelimit.go. Esta separación mantiene el código ordenado y facilita las pruebas.

Definiendo el Middleware de Rate Limiting

El siguiente código muestra la creación de una función middleware que envuelve nuestro router. La función RateLimitMiddleware crea una instancia del limitador con una configuración específica y devuelve una función http.Handler que realiza la lógica de comprobación.

// middleware/ratelimit.go
package middleware

import (
    "context"
    "net/http"
    "strings"
    limiter "github.com/go-rate-limiter/rate-limiter"
)

// RateLimitMiddleware crea un middleware que limita las solicitudes por IP.
func RateLimitMiddleware(next http.Handler) http.Handler {
    // Configuración del limitador: 100 solicitudes máximas, con relleno de 10 por segundo.
    cfg := &limiter.Config{
        Max:      100,   // Capacidad total del bucket (tokens máximos).
        Duration: 10,    // Tokens que se reponen por segundo.
        // Usamos un store en memoria. En producción, usaríamos limiter.NewRedisStore().
        Store:    limiter.NewMemoryStore(),
        // Función para extraer la clave única (en este caso, la IP del cliente).
        KeyFunc: func(r *http.Request) string {
            // Intentamos obtener la IP real si hay proxies (X-Forwarded-For).
            forwarded := r.Header.Get("X-Forwarded-For")
            if forwarded != "" {
                // Toma la primera IP de la lista (la del cliente original).
                ips := strings.Split(forwarded, ",")
                return strings.TrimSpace(ips[0])
            }
            // Fallback a la IP remota directa.
            return strings.Split(r.RemoteAddr, ":")[0]
        },
    }

    // Creamos la instancia del limitador con nuestra configuración.
    limit := limiter.New(cfg)

    // Devolvemos el Handler que ejecuta la lógica.
    return http.HandlerFunc(func(w http.ResponseWriter, r *http.Request) {
        // El limitador decide si la solicitud es permitida.
        ctx, cancel := context.WithTimeout(r.Context(), limiter.DefaultWaitTimeout)
        defer cancel()

        // Wait obtiene un token. Si no puede (limite excedido), devuelve un error.
        if err := limit.Wait(ctx, r); err != nil {
            // Si el error es de límite excedido, respondemos con 429.
            if err == limiter.ErrLimitExceeded {
                http.Error(w, "Límite de tasa excedido. Por favor, intente más tarde.", http.StatusTooManyRequests)
                return
            }
            // Para otros errores (ej., timeout del store), respondemos con 500.
            http.Error(w, "Error interno del servidor", http.StatusInternalServerError)
            return
        }
        // Si Wait no devuelve error, el token fue adquirido. Pasamos al siguiente handler.
        next.ServeHTTP(w, r)
    })
}

Integrando el Middleware en el Router Principal

Ahora, en nuestro archivo principal (por ejemplo, main.go), debemos aplicar este middleware a nuestro router. Con Gorilla/Mux, podemos usar router.Use() para aplicar middleware a todas las rutas, o podemos aplicarlo de forma más selectiva. Aquí lo aplicaremos globalmente.

// main.go
package main

import (
    "log"
    "net/http"
    "tu-proyecto/middleware" // Ajusta la ruta de importación a tu módulo.
    "github.com/gorilla/mux"
)

func main() {
    r := mux.NewRouter()

    // Define tus rutas como de costumbre.
    r.HandleFunc("/api/v1/health", healthHandler).Methods("GET")
    r.HandleFunc("/api/v1/users", usersHandler).Methods("GET")
    r.HandleFunc("/api/v1/products", productsHandler).Methods("POST")
    // ... más rutas

    // *** PASO CRÍTICO: Aplica el middleware de rate limiting al router. ***
    // El middleware se ejecutará para cada solicitud, en el orden en que se aplica.
    wrappedRouter := middleware.RateLimitMiddleware(r)

    log.Println("Servidor iniciado en el puerto 8080 con rate limiting activado.")
    // Usamos el router envuelto por el middleware.
    if err := http.ListenAndServe(":8080", wrappedRouter); err != nil {
        log.Fatal(err)
    }
}

// Handlers de ejemplo
func healthHandler(w http.ResponseWriter, r *http.Request) {
    w.WriteHeader(http.StatusOK)
    w.Write([]byte(`{"status": "ok"}`))
}
// ... implementaciones de los otros handlers

Errores Comunes y Cómo Evitarlos

Al implementar rate limiting, es fácil caer en trampas que reducen su efectividad o introducen nuevos problemas. Aquí detallamos los más frecuentes:

1. Limitar la IP incorrecta en entornos con proxy/load balancer: Si tu API está detrás de un load balancer (como AWS ALB, Nginx o Cloudflare), la IP en r.RemoteAddr será la del balanceador, no la del cliente final. Todos los usuarios parecerán venir de la misma IP, y el límite se aplicará globalmente, bloqueando a todos si uno abusa. Solución: Siempre verifica y utiliza cabeceras estándar como X-Forwarded-For o X-Real-IP, como se muestra en el KeyFunc del código. Configura tu infraestructura para que inyecte estas cabeceras de manera confiable.

2. No configurar tiempos de espera (timeout) para el store: Si usas un store distribuido como Redis y no configuras un timeout de contexto, una lentitud o caída de Redis podría hacer que todas las solicitudes a tu API se queden bloqueadas indefinidamente, causando una denegación de servicio autoinfligida. Solución: Como vimos en el código, siempre usa context.WithTimeout cuando llames a limit.Wait. En caso de timeout, es mejor permitir la solicitud (fail-open) o al menos fallar con gracia (500), pero nunca colgarse.

3. Elegir límites demasiado estrictos o demasiado laxos sin métricas: Poner 10 solicitudes por hora paralizará a tus usuarios legítimos. Poner 10,000 por segundo podría no protegerte de nada. Solución: Implementa métricas y logging. Registra los eventos 429. Usa herramientas de monitoreo para entender el patrón de tráfico normal de tu API y ajusta los límites basándote en percentiles (ej., el 99% de los usuarios hace menos de 50 req/min). Comienza con límites conservadores en producción y ajústalos gradualmente.

4. Olvidar aplicar el middleware a rutas críticas o aplicarlo de forma inconsistente: Aplicar el limitador solo a las rutas /api/v1 pero olvidar una ruta de login o de upload puede dejar puertas traseras abiertas para ataques. Solución: Usa router.Use() para un alcance global o crea subrouters con middleware específico. Documenta y audita regularmente qué rutas están protegidas. Considera si las rutas de health check (/health, /ready) deben estar exentas del límite para que los sistemas de orquestación (Kubernetes) no sean bloqueados.

5. No comunicar los límites a los clientes de la API: Un cliente que recibe un 429 sin información adicional no sabe cuándo puede volver a intentarlo, lo que genera una mala experiencia de desarrollo. Solución: Mejora tus respuestas de error 429 incluyendo cabeceras estándar como Retry-After (que indica los segundos de espera) o X-RateLimit-Limit, X-RateLimit-Remaining, X-RateLimit-Reset. Esto convierte tu API en una API "amigable para desarrolladores".

Checklist de Dominio

Antes de considerar esta lección completa, verifica que puedes realizar o comprender cada uno de los siguientes puntos:

• Puedo explicar la analogía del "Cubo de Fichas" (Token Bucket) y cómo regula las solicitudes promedio y las ráfagas.
• He integrado exitosamente el middleware go-rate-limiter en una API existente basada en Gorilla/Mux y puede verificar que rechaza solicitudes después de alcanzar el límite (código 429).
• Sé cómo extraer correctamente la IP del cliente real en un entorno con proxies o load balancers usando X-Forwarded-For.
• Comprendo la diferencia entre un store en memoria (para desarrollo/una sola instancia) y un store distribuido como Redis (para producción con múltiples réplicas) y puedo explicar por qué el segundo es esencial para microservicios.
• Puedo listar al menos tres estrategias diferentes para la "clave" de limitación (por IP, por API Key, por usuario) y describir un caso de uso para cada una.
• Sé cómo configurar un timeout en la llamada al limitador para evitar que una falla en el store (ej., Redis) derribe toda mi API.
• Puedo modificar el código para añadir cabeceras informativas (X-RateLimit-*, Retry-After) en las respuestas, tanto exitosas como de error 429.
• He probado el comportamiento del limitador usando una herramienta como curl en bucle, un script simple en Go, o una herramienta de carga como wrk o ab.

Consejo Final de Implementación: El rate limiting es una capa de defensa. Para una API robusta en producción, combínalo con otros middlewares como autenticación/autorización, logging estructurado, recuperación de pánicos (panic recovery) y validación de entrada. La secuencia en la que apilas estos middlewares en tu router es importante: típicamente, el rate limiting y la autenticación deben ir lo más cerca del principio de la cadena como sea posible para proteger recursos costosos.

Con esta implementación, has dado un paso fundamental hacia la operación profesional de tus microservicios en Go. Has pasado de construir una API que "funciona" a construir una que es resiliente y justa. El middleware de rate limiting es ahora un guardián silencioso pero poderoso, trabajando en cada solicitud para asegurar la estabilidad y disponibilidad de tu sistema. En el siguiente módulo, podrás explorar cómo llevar esta configuración a un entorno distribuido utilizando Redis como store centralizado.

Falar no WhatsApp