Redis sobre HTTP, facturado por petición, sin pool de conexiones que cuidar

La mayoría de guías "Upstash quickstart" te muestra un solo GET y SET. El patrón que le gana a Upstash su sitio en un stack serverless es el de abajo: un rate limiter de ventana deslizante y un check de token de idempotencia, los dos corriendo dentro de una Server Action, los dos respaldados por la misma instancia Redis, con el patrón de webhook Stripe visto antes en el stack tomando prestada la misma primitiva de idempotencia.

1. El rate limiter

@upstash/ratelimit hace la corrección algorítmica dentro de Redis con MULTI/EXEC. El código aplicativo es una línea en el call site.

// src/lib/upstash/ratelimit.ts
import { Ratelimit } from '@upstash/ratelimit'
import { Redis } from '@upstash/redis'

const redis = new Redis({
  url: process.env.UPSTASH_REDIS_REST_URL!,
  token: process.env.UPSTASH_REDIS_REST_TOKEN!,
})

export const ipLimiter = new Ratelimit({
  redis,
  limiter: Ratelimit.slidingWindow(20, '10 s'),
  prefix: 'rl:ip',
  analytics: true,
})

export const userLimiter = new Ratelimit({
  redis,
  limiter: Ratelimit.slidingWindow(100, '60 s'),
  prefix: 'rl:user',
  analytics: true,
})

export const tenantLimiter = new Ratelimit({
  redis,
  limiter: Ratelimit.tokenBucket(1000, '60 s', 1000),
  prefix: 'rl:tenant',
  analytics: true,
})

export async function checkRate(opts: {
  ip: string
  userId: string
  tenantId: string
}): Promise<
  | { ok: true }
  | { ok: false; scope: 'ip' | 'user' | 'tenant'; reset: number }
> {
  const ipResult = await ipLimiter.limit(opts.ip)
  if (!ipResult.success) return { ok: false, scope: 'ip', reset: ipResult.reset }

  const userResult = await userLimiter.limit(opts.userId)
  if (!userResult.success) return { ok: false, scope: 'user', reset: userResult.reset }

  const tenantResult = await tenantLimiter.limit(opts.tenantId)
  if (!tenantResult.success) return { ok: false, scope: 'tenant', reset: tenantResult.reset }

  return { ok: true }
}

2. El helper de idempotencia

Una clave única codifica la forma de la petición; la respuesta se cachea contra esa clave. Un reintento con la misma clave devuelve la respuesta original sin volver a ejecutar el trabajo.

// src/lib/upstash/idempotency.ts
import { Redis } from '@upstash/redis'

const redis = new Redis({
  url: process.env.UPSTASH_REDIS_REST_URL!,
  token: process.env.UPSTASH_REDIS_REST_TOKEN!,
})

const TTL_SECONDS = 24 * 60 * 60

interface RecordedResult<T> {
  status: 'success' | 'error'
  response: T
}

export async function withIdempotency<T>(
  key: string,
  run: () => Promise<T>,
): Promise<T> {
  const fullKey = `idem:${key}`

  const existing = await redis.get<RecordedResult<T>>(fullKey)
  if (existing) {
    if (existing.status === 'error') {
      throw new Error('previous attempt failed; retry with a different key')
    }
    return existing.response
  }

  try {
    const result = await run()
    await redis.set(
      fullKey,
      { status: 'success', response: result } satisfies RecordedResult<T>,
      { ex: TTL_SECONDS },
    )
    return result
  } catch (err) {
    await redis.set(
      fullKey,
      { status: 'error', response: null } satisfies RecordedResult<unknown>,
      { ex: 60 },
    )
    throw err
  }
}

3. La Server Action que usa los dos

La Server Action toma un header Idempotency-Key, ejecuta el rate limiter, luego ejecuta la lógica de negocio dentro del helper de idempotencia. Un POST reintentado con la misma clave devuelve la respuesta original; una escritura duplicada nunca ocurre.

// app/[lang]/(app)/invoices/actions.ts
'use server'

import { headers } from 'next/headers'
import { z } from 'zod'
import { checkRate } from '@/lib/upstash/ratelimit'
import { withIdempotency } from '@/lib/upstash/idempotency'
import { getServerSession } from '@/lib/auth/server'
import { stripe } from '@/lib/stripe/server'

const Input = z.object({
  customerId: z.string(),
  amountCents: z.number().int().positive(),
  description: z.string().min(1).max(200),
})

export async function createInvoice(
  raw: unknown,
): Promise<
  | { ok: true; invoiceId: string }
  | { ok: false; error: string; reset?: number }
> {
  const session = await getServerSession()
  if (!session) return { ok: false, error: 'unauthorised' }

  const hdrs = await headers()
  const ip = hdrs.get('x-forwarded-for')?.split(',')[0] ?? '0.0.0.0'
  const idempotencyKey = hdrs.get('idempotency-key')
  if (!idempotencyKey) return { ok: false, error: 'missing idempotency key' }

  const rate = await checkRate({
    ip,
    userId: session.userId,
    tenantId: session.tenantId,
  })
  if (!rate.ok) {
    return { ok: false, error: `rate limited (${rate.scope})`, reset: rate.reset }
  }

  const parsed = Input.safeParse(raw)
  if (!parsed.success) return { ok: false, error: 'invalid input' }

  return withIdempotency(`invoice:${session.tenantId}:${idempotencyKey}`, async () => {
    const invoice = await stripe.invoices.create({
      customer: parsed.data.customerId,
      collection_method: 'send_invoice',
      days_until_due: 30,
      description: parsed.data.description,
      metadata: { tenant_id: session.tenantId },
    })

    await stripe.invoiceItems.create({
      customer: parsed.data.customerId,
      amount: parsed.data.amountCents,
      currency: 'eur',
      invoice: invoice.id,
    })

    return { ok: true as const, invoiceId: invoice.id }
  })
}

4. Qué te compra esto

El rate limiter corre en un par de milisegundos en el edge. El helper de idempotencia convierte un POST reintentado en una lookup de cache, así la API de Stripe nunca ve un duplicado. Todo el flujo vive en tres archivos; la capa Redis no aparece en la lógica aplicativa salvo como dos helpers que se leen como funciones normales.

Este es el Upstash que se gana su sitio: no una curiosidad "hemos sustituido Redis por HTTP", sino la capa operativa que hace los deploys serverless realmente seguros bajo reintentos y tráfico alto.