Cómo hacer un eCommerce escalable: arquitectura, stack y decisiones técnicas

Cómo hacer un eCommerce escalable: arquitectura, stack y decisiones técnicas

Hacer un eCommerce que soporte 100k visitas/día en Black Friday sin caerse, 0.5% tasa de conversión, y picos de tráfico 10x en campañas requiere decisiones técnicas desde el día 1. Aquí la arquitectura que recomiendo en 2026, basada en 8 años viendo tiendas online caerse (y otras escalar bien).

(Este artículo es parte de nuestro cluster CRO para eCommerce. Si ya tienes tienda, mira el Shopify vs WooCommerce 2026.)

El mito de "escalar cuando sea necesario"

Realidad cruel: si tu eCommerce se cae en Black Friday, pierdes el 70% de las ventas que podrías haber hecho (datos de Baymard). No es el momento de "escalar cuando haga falta". Es el momento de diseñar para escalar desde el día 1.

Ejemplo real: cliente con 8M €/año, falló en Black Friday por usar un hosting compartido de 15 €/mes. Perdió 280.000 € ese día. Después cambió a arquitectura escalable y nunca más falló.

Las 4 métricas que importan para escalar eCommerce

Antes de optimizar la arquitectura, entiende qué mides:

1. P99 latency (no promedio): el 1% de requests más lentos. Tu problema está ahí 2. Conversion rate: a > 3s de LCP, pierdes 7% de conversión por cada 100ms (Akamai) 3. Uptime: el 99.9% es "3 nines" = 8.7 horas de caída/año. Black Friday = 1 hora = 99.99% ya roto 4. CPU/DB load en picos: 80% sostenido = problema. 50% pico Black Friday = bien

Arquitectura en 4 capas

` ┌─────────────────────────────────────┐ │ CAPA 1: EDGE (CDN + WAF) │ │ Cloudflare + WAF + cache edge │ └──────────────┬──────────────────────┘ │ ┌──────────────▼──────────────────────┐ │ CAPA 2: FRONTEND (SSG + ISR) │ │ Astro/Next.js + Vercel/Netlify │ └──────────────┬──────────────────────┘ │ ┌──────────────▼──────────────────────┐ │ CAPA 3: API + BUSINESS LOGIC │ │ Node.js/Edge functions + queue │ └──────────────┬──────────────────────┘ │ ┌──────────────▼──────────────────────┐ │ CAPA 4: DATA │ │ PostgreSQL + Redis + S3 │ └─────────────────────────────────────┘ `

Capa 1: Edge (CDN + WAF)

Objetivo: servir el 80% del contenido sin tocar tu servidor.

Componentes:

Cloudflare (recomendado) o BunnyCDN

WAF (Web Application Firewall): bloquea bots, SQL injection, DDoS

Edge cache: imágenes, JS, CSS, incluso HTML estático

Cloudflare Workers (opcional): lógica de A/B testing, geolocation, edge redirects

Configuración crítica:

DNS en Cloudflare (proxy activado)

SSL en modo Full (no Flexible)

Cache rules: HTML 1h, CSS/JS 1 año (inmutable), imágenes 1 mes

WAF rules: bloquear países no objetivo (en eCommerce España)

Bot Fight Mode: activado

Coste: 0-25 €/mes según tráfico.

Capa 2: Frontend (SSG + ISR)

Objetivo: servir HTML pre-renderizado o regenerado en build.

Stack recomendado 2026 (mi opción para eCommerce):

Astro 6+ (mi favorito actual): zero-JS por defecto, partial hydration

Next.js 15+ con App Router: si necesitas más JS interactivo

Nuxt 3+: si prefieres Vue

Hosting:

Vercel (si Next.js): 0-20 $/mes, escala automática

Netlify (si Astro/Next): 0-19 $/mes

Cloudflare Pages (gratis, excelente con Astro): 0 $/mes hasta 100k visitas/mes

Astro standalone (si quieres control): 0 $ de hosting si lo sirves desde Cloudflare

Decisiones críticas:

SSG por defecto (Static Site Generation): el 90% de páginas de eCommerce son estáticas

ISR (Incremental Static Regeneration) para páginas que cambian: stock, precios

CSR mínimo: solo para carrito, checkout, login (donde necesitas estado)

Imágenes en formato WebP/AVIF + responsive con srcset

Capa 3: API + Business Logic

Objetivo: manejar operaciones dinámicas (carrito, checkout, stock, precios).

Stack recomendado 2026:

Node.js 22+ con TypeScript

Hono o Elysia (más rápidos que Express)

Edge functions (Cloudflare Workers, Vercel Edge) para latencia sub-50ms

Cola de mensajes (BullMQ, Inngest) para: emails, abandoned cart, sync inventario, webhooks

Patrones clave:

API REST + GraphQL: REST para admin, GraphQL para frontend

Idempotency keys: para evitar duplicados en pagos

Rate limiting: por IP, por user, por endpoint

Auth: JWT con refresh tokens, no sesiones server-side

Webhooks: Stripe, Shopify, Klaviyo todos con webhooks → cola

Capa 4: Data (PostgreSQL + Redis + S3)

Base de datos principal: PostgreSQL 16+

Por qué PostgreSQL:

Maduro, escalable, gratuito

Soporta JSON (para schema flexible)

Replicación nativa

Excelente para queries complejas (joins, agregaciones)

Compatible con Supabase, Neon, AWS RDS, etc.

Cuándo escalar a otras DBs:

ClickHouse si tienes > 1B eventos/mes (analytics)

MongoDB si tu schema es realmente flexible (raro en eCommerce)

Elasticsearch si necesitas búsqueda full-text compleja (usa Typesense antes)

Cache: Redis 7+

Cuándo usar Redis:

Sesiones de usuario

Cache de queries frecuentes (productos top, precios)

Rate limiting

Colas de trabajo ligeras

NO usar Redis para:

Datos que no quieres perder (usa DB)

Cosas que no son hot data

Storage de assets: S3 + Cloudflare R2

Por qué:

S3 es estándar, integración nativa

R2 es 10x más barato y 0 egress fees

Cloudflare Images se integra con R2

Patrón recomendado:

Imágenes en R2 con Cloudflare Images

Transformaciones on-the-fly (resize, format conversion)

Cache de transformaciones en edge

El stack concreto que recomiendo en 2026

Para tienda pequeña/media (< 1M €/año, < 50k visitas/mes)

` Frontend: Astro 6 + SolidJS (interactividad selectiva) Hosting: Cloudflare Pages (gratis hasta 100k visitas) CMS: Sanity o Strapi (o tu Supabase actual) DB: Supabase (PostgreSQL managed) Cache: Upstash Redis (serverless) Auth: Supabase Auth Pagos: Stripe Email: Resend (transactional) + Klaviyo (marketing) Búsqueda: Meilisearch (Typesense) o Algolia Storage: Cloudflare R2 Monitor: Sentry + Plausible `

Coste mensual típico: 50-150 €.

Para tienda grande (> 1M €/año, > 50k visitas/mes)

` Frontend: Next.js 15 + React 19 (App Router) Hosting: Vercel Pro (20 $/mes) o auto-hospedaje CMS: Sanity (con GROQ para queries complejas) DB: Neon (PostgreSQL serverless) o Supabase Pro Cache: Upstash Redis (regional) Auth: Clerk o Auth0 Pagos: Stripe (con SCA y 3DS) Email: Resend + Klaviyo Búsqueda: Algolia (con replicas) Storage: AWS S3 + CloudFront Cola: Inngest (serverless) o BullMQ (si self-hosted) Monitor: Sentry + Plausible + Datadog CI/CD: GitHub Actions + Vercel `

Coste mensual típico: 500-2000 €.

Decisiones críticas que tomar ANTES de empezar

1. Headless vs Monolítico

Monolítico (Shopify, WooCommerce):

✅ Más rápido de lanzar

✅ Menos decisiones técnicas

❌ Menos flexible

❌ Más caro a largo plazo

Headless (Astro + Shopify Storefront API, Astro + WooCommerce Headless):

✅ Performance top

✅ Control total del front

✅ SEO imbatible

❌ Más caro de construir (3-10k € setup)

❌ Mantenimiento más complejo

Mi recomendación para 2026:

< 50k visitas/mes: Shopify o WooCommerce monolítico

50k-200k visitas/mes: Shopify + headless en Shopify Hydrogen o Next.js commerce

> 200k visitas/mes: Headless completo (Astro + Shopify Storefront API o similar)

2. Multi-tenant o single-tenant

Single-tenant (1 eCommerce, 1 DB): más simple.

Multi-tenant (varias tiendas, 1 backend): ahorra costes pero suma complejidad.

Mi recomendación: single-tenant hasta 5M €/año. Multi-tenant solo si tienes marketplace o varias marcas independientes.

3. Multi-región

Una región (ej: solo España): un CDN, un DB.

Multi-región (ej: España + LATAM): DBs en cada región, sincronización, GDPR.

Mi recomendación: una región hasta 5M €/año. Multi-región si tienes > 30% de tráfico internacional.

Patrones de cache para eCommerce escalable

Cache de productos

`typescript // Cache de producto individual (1h TTL) async function getProduct(id: string) { const cached = await redis.get(product:${id}); if (cached) return JSON.parse(cached);

const product = await db.products.findUnique({ where: { id } }); if (product) { await redis.setex(product:${id}, 3600, JSON.stringify(product)); } return product; } `

Pero ojo con stock: si el stock cambia, invalida el cache.

`typescript // Invalidar cache al actualizar stock await db.products.update({ where: { id }, data: { stock: newStock } }); await redis.del(product:${id}); await redis.del(products:category:${product.categoryId}); `

Cache de listado de productos

Patrón: cache de páginas de categoría con stale-while-revalidate.

` GET /category/[slug] → 1. Buscar en cache (HTML cacheado por 1h) 2. Si hit: devolver + actualizar en background 3. Si miss: generar, devolver, guardar `

Esto lo hace Next.js con revalidate o Astro con adapter hybrid.

Cache de queries frecuentes

Top 100 productos: cache 1h

Categorías: cache 24h

Marcas: cache 24h

Stock por producto: cache 1min (debe ser fresco)

Precios: cache 1h (pueden cambiar, pero no en segundos)

Monitorización: saber ANTES de que se caiga

Herramientas esenciales

Real User Monitoring (RUM):

Plausible (privacy-first, simple)

Google Analytics 4 (gratis, completo)

Sentry (errores en producción)

Application Performance Monitoring (APM):

Datadog (caro, completo)

Sentry (errores + performance)

Cloudflare Analytics (gratis si usas CF)

Server monitoring:

Uptime monitoring: UptimeRobot, BetterStack, BetterUptime

Log aggregation: Logtail, BetterStack, Datadog

Métricas clave a monitorizar:

| Métrica | Alerta si... | |---|---| | P99 latency | > 1s | | Error rate | > 0.5% | | CPU | > 70% sostenido | | DB connections | > 80% del pool | | Cache hit rate | < 80% | | Conversion rate | Baja > 20% en 1h | | Stock inconsistencies | Cualquiera (es bug) | | Failed payments | > 1% de intentos |

Manejo de picos (Black Friday, Cyber Monday, rebajas)

Pre-pico (1 mes antes)

Load testing: simular 10x tráfico normal con k6, Gatling o Loader.io

Capacity planning: dimensionar DB, cache, CDN para 10x

CDN warm-up: pre-cargar páginas top

Stock backup: si dependes de proveedores, confirma inventario

Customer support: aumenta equipo 2x

Durante el pico (Black Friday)

Rate limiting agresivo: 10 req/seg por IP, no 100

Checkout queue: si hay más demanda que capacidad, queue en lugar de error

Cache más agresivo: TTL 5min en lugar de 1h para datos dinámicos

Status page: status.mjora.studio o statuspage.io para comunicar a clientes

Devs on-call: alguien disponible 24h para resolver incidentes

Post-pico (después)

Análisis: qué falló, qué funcionó, qué mejorar

Cleanup: datos temporales, logs, jobs pendientes

Documentación: post-mortem del incidente (qué pasó, cómo evitarlo)

Conclusión: la arquitectura correcta depende del tamaño

No hay una arquitectura única para todos. La regla general:

< 100k visitas/mes: Shopify o WooCommerce con hosting básico

100k-1M visitas/mes: Shopify + headless o WooCommerce + Cloudways/Kinsta

> 1M visitas/mes: Headless completo (Astro/Next + Postgres + Redis + CDN)

Lo más importante: diseña para escalar desde el día 1. Migrar una arquitectura pequeña a una grande es MUCHO más caro que empezar bien.

¿Necesitas ayuda para diseñar la arquitectura de tu eCommerce? Escríbeme a hola@mjora.studio — primera consulta gratuita de 30 min.

---

Lee el Shopify vs WooCommerce 2026, la guía de email marketing con Klaviyo o las 7 mejoras de checkout optimization.