Cuando construyes una plataforma de e-commerce que necesita manejar tráfico real, el enfoque de monolito naive se rompe rápidamente. Así es como abordé la arquitectura para un sistema que sirve miles de sesiones concurrentes.
Modelo de datos: PostgreSQL como fuente de verdad
El catálogo de productos, pedidos y cuentas de usuario viven en PostgreSQL. La decisión clave fue usar una columna JSONB para los atributos del producto — esto evita la pesadilla de las migraciones de esquema cuando los merchants tienen estructuras de producto muy diferentes, manteniendo limpio el modelo relacional central.
CREATE TABLE products (
id UUID PRIMARY KEY DEFAULT gen_random_uuid(),
merchant_id UUID NOT NULL REFERENCES merchants(id),
slug TEXT NOT NULL,
price_cents INTEGER NOT NULL,
attributes JSONB DEFAULT '{}',
created_at TIMESTAMPTZ DEFAULT now()
);
CREATE INDEX ON products USING GIN (attributes);
Redis para sesiones y bloqueos de inventario
Los dos sitios donde Redis se gana su sitio: almacenamiento de sesiones (lecturas sub-milisegundo) y reserva de inventario. Cuando un usuario añade un artículo al carrito, un lock de Redis retiene el inventario durante 15 minutos. Esto evita el sobreventa sin requerir una transacción de base de datos en cada vista de página.
El despliegue
La app corre en Kubernetes con un horizontal pod autoscaler atado a CPU y profundidad de la cola de peticiones. El pool de conexiones de PostgreSQL (vía PgBouncer) es el principal cuello de botella de escalado — algo que abordaría con réplicas de lectura en un despliegue de producción.
La arquitectura correcta para una plataforma de e-commerce es la más simple que maneja tu tráfico real, no tu tráfico aspiracional.