Infraestructura para ecommerce headless: decisiones clave antes de salir a producción

En un ecommerce headless, el equipo es responsable de más infraestructura que en Shopify o WooCommerce managed. El backend (Medusa o similar), la base de datos, el sistema de caché, los workers de jobs y el servidor de frontend son componentes separados que hay que operar, monitorear y actualizar.

No todas esas decisiones tienen que ser perfectas desde el inicio, pero algunas no se pueden posponer: la base de datos de producción, la estrategia de secretos y el sistema de logs. Empezar con SQLite en producción o con credenciales en variables de entorno sin un gestor de secretos crea deuda que cuesta cara más adelante.

Un frontend de ecommerce en Next.js o Astro puede servirse de varias formas: estático con CDN (máxima performance, contenido que cambia poco), SSR por request (contenido personalizado, más carga en servidor) o híbrido con ISR (pages estáticas regeneradas en background). La elección afecta costos, latencia y complejidad operativa.

Para la mayoría de ecommerce, el patrón híbrido es el correcto: páginas de categoría y producto estáticas con revalidación cada pocos minutos, carrito y checkout completamente dinámicos. Vercel, Cloudflare Pages y AWS CloudFront soportan ese patrón con configuración mínima.

Medusa y similares corren bien en instancias pequeñas si la base de datos está bien indexada y el caché está activo. Para un lanzamiento inicial, una instancia de 2 vCPU y 4 GB de RAM con PostgreSQL en RDS o Railway es suficiente para varios miles de pedidos al mes. El error frecuente es sobredimensionar el compute y sub-dimensionar la base de datos.

PostgreSQL necesita backups automatizados, punto de restauración en el tiempo y al menos una réplica de lectura si el tráfico de reportes compite con el tráfico de la tienda. Esas tres cosas son más importantes que el tamaño de la instancia principal.

Operar sin observabilidad en un ecommerce de producción es operar a ciegas. Los tres instrumentos mínimos son: logs estructurados con un nivel de severidad claro (info para flujos normales, error para excepciones, warn para situaciones inesperadas pero recuperables), métricas de latencia y error rate en los endpoints críticos, y alertas que notifiquen cuando el error rate sube o el tiempo de respuesta del checkout supera un umbral.

Datadog, Grafana Cloud y Axiom son opciones viables con tier gratuito suficiente para empezar. Lo importante no es la herramienta; es el hábito de revisar los logs después de cada deploy y tener alertas configuradas antes de recibir el primer pedido real.