Página técnica · La misma arquitectura que mueve la demo

Así funciona por dentro

Esta página existe porque la confianza se gana enseñando la cocina. Nada de humo: esta es la arquitectura exacta de cada tienda que entregamos, la misma que mueve la demo.

Todo proyecto empieza sencillo

Cada tienda arranca como un MVP: una tienda mínima pero completa y en producción, que encaja igual en una bodega de 20 referencias que en un distribuidor industrial. Después crece sobre lo que el ecommerce pida de verdad. Nuestro punto fuerte es justo ese, hacer las cosas sencillas desde el principio — y lo que viene debajo explica por qué eso también es lo más barato de mantener.

El principio: casi todo es estático

La tienda se genera como HTML puro y se sirve desde la red global de Cloudflare (300+ ciudades, la tuya incluida). Por eso carga en menos de medio segundo: no hay servidor pensando, solo ficheros viajando desde muy cerca del comprador. Las únicas piezas dinámicas son el carrito, el pago y el panel — funciones pequeñas que despiertan solo cuando se usan y se cobran por uso: una tienda que empieza gasta muy poco, y el gasto sube al ritmo del tráfico en vez de por adelantado.

El flujo de una compra

Comprador carrito en su navegador API en el edge revalida precios y stock Base de datos D1 la única fuente de precios Stripe Checkout la tarjeta nunca nos toca Webhook firmado pagado → stock → email
  1. El carrito vive en el navegador del comprador, pero solo guarda referencias. Los precios se recalculan siempre en el servidor contra la base de datos: manipular el carrito no sirve de nada.
  2. Al pagar, la API revalida stock y precios y crea la sesión en la pasarela — en la demo, Stripe Checkout. El comprador paga en la página de la pasarela: el número de tarjeta jamás pasa por nuestra infraestructura. PayPal u otra pasarela encajan en el mismo hueco; lo que se describe aquí no cambia.
  3. Stripe nos confirma el pago con un webhook firmado criptográficamente. Solo entonces el pedido pasa a «pagado», se descuenta el stock y se envía el email de confirmación — todo en una única transacción.
  4. Si Stripe reenvía la confirmación (pasa a menudo), el sistema la reconoce y no duplica nada: el webhook es idempotente.
La bandeja de emails del panel: cada confirmación de pedido y aviso de envío que el sistema ha generado
El resultado visible del webhook: la bandeja de emails de la demo, con cada confirmación y aviso generados por pedidos reales de prueba.

El modelo de datos completo

Seis tablas. Sin ORM mágico, sin cincuenta relaciones. Dos decisiones importan: el dinero se guarda en céntimos enteros (nunca decimales flotantes) y cada línea de pedido congela el nombre y el precio del momento de la compra — cambiar una tarifa hoy jamás altera un pedido de ayer.

products Catálogo: precio en céntimos, stock, categoría, activo
orders Pedido con totales congelados, estado y datos de envío
order_items Líneas con nombre y precio del momento de la compra
order_events Historial auditable de cada cambio de estado
shipping_rates Tarifa por zona con umbral de envío gratis
emails_outbox Cola de emails transaccionales

¿Hasta dónde escala? De 10 referencias a un millón

Las cuentas son públicas y se pueden comprobar: una referencia con su descripción pesa ~1–2 KB en la base de datos, y cada base D1 admite 10 GB — un millón de productos ocupa una fracción. Las páginas se sirven estáticas o cacheadas desde el CDN, así que el catálogo puede crecer tres órdenes de magnitud sin cambiar de arquitectura ni de plataforma.

La parte honesta: a esa escala el trabajo no está en el motor, está en el catálogo — la búsqueda pasa a necesitar índice propio, aparecen los filtros por facetas y la sincronización de inventario. Eso se construye en el tramo a medida, sobre esta misma base y sin migrar nada: la tienda que arranca con 10 productos y la que sirve un catálogo industrial comparten motor.

Envíos: simple a propósito

Nada de integraciones frágiles con APIs de transportistas. El comercio exporta los pedidos pagados en un CSV compatible con Packlink PRO o SendCloud, imprime las etiquetas allí (donde además el precio del envío es mejor), y pega el número de seguimiento en el panel. El cliente recibe su aviso automáticamente. Menos piezas, menos averías, y el mejor precio de etiqueta en cada momento.

El listado de pedidos del panel con sus estados y el botón de exportar CSV para Packlink o SendCloud
El panel de ejemplo: fixtures de pedidos, estados y exportación CSV para enseñar cómo funcionaría una tienda real.

Lo que esto significa para ti

El coste sigue al tráfico

La tienda no paga servidores encendidos sin usar: el gasto acompaña a las visitas que recibe, y las visitas son justo lo que trabajamos por ti.

Sin cuellos de botella

Si sales en la radio y entran 5.000 personas a la vez, la tienda ni se entera: es HTML servido desde 300 ciudades.

Sin rehenes

El código está en un repositorio a tu nombre. Si mañana quieres irte, te lo llevas todo.

¿Quieres verlo funcionando?

Recorre una compra simulada en ARCE y explora por separado el panel ficticio.

Cuéntanos tu proyecto

Empezamos por un MVP sencillo que funcione desde el primer día y crezca contigo. Dinos qué vendes y te decimos si encajamos.

Te contestamos en 24 h laborables. Sin compromiso y sin llamadas comerciales.

Contacta