Las traducciones son generadas a través de traducción automática. En caso de conflicto entre la traducción y la version original de inglés, prevalecerá la version en inglés.

Amazon ElastiCache (Valkey) para aplicaciones de comercio electrónico

Una aplicación de comercio electrónico se beneficia de una capa de caché en memoria entre los servidores de aplicaciones y la base de datos. Amazon con ElastiCache Valkey proporciona una latencia de lectura inferior a un milisegundo para los datos a los que se accede con frecuencia (entradas del catálogo de productos, recuentos de inventario, resultados de búsqueda y sesiones de usuario), lo que reduce la carga de la base de datos y mejora los tiempos de respuesta en caso de picos de tráfico.

Configuración del clúster

Elija un tipo de clúster en función del volumen de datos, los requisitos de rendimiento y las preferencias operativas.

Para la mayoría de las aplicaciones de comercio electrónico que se están iniciando, Serverless proporciona la ruta más sencilla hacia la producción. Migre a clústeres basados en nodos cuando tenga líneas de base de tráfico predecibles y necesite más control sobre la topología de los clústeres, los tipos de nodos y el comportamiento de escalado.

Diseño clave para los datos del producto

Diseñe las claves de caché para que sean predecibles, se puedan depurar y tengan un alcance específico para evitar colisiones entre los tipos de datos.

Mejores prácticas clave de diseño:

Estrategia de TTL por tipo de datos

Establezca valores de TTL (tiempo de vida útil) en función de la frecuencia con la que cambian los datos y de su obsolescencia sin afectar a la experiencia del cliente.

Cache-aside patrón

El patrón de almacenamiento en caché (también denominado carga diferida) es la estrategia de almacenamiento en caché más común para las aplicaciones de comercio electrónico. La aplicación comprueba primero la caché y solo consulta la base de datos si no se encuentra en la memoria caché.

Ruta de lectura (pseudocódigo)

FUNCTION getProduct(productId):
    cacheKey = "product:" + productId

    // Step 1: Check the cache
    cachedValue = cache.GET(cacheKey)

    IF cachedValue exists:
        RETURN deserialize(cachedValue)    // Cache hit — sub-millisecond

    // Step 2: Cache miss — query database
    product = database.query("SELECT * FROM products WHERE id = ?", productId)

    IF product not found:
        RETURN null

    // Step 3: Write to cache with TTL
    cache.SET(cacheKey, serialize(product), EXPIRE = 300)    // 5 minutes

    RETURN product

Ruta de escritura (pseudocódigo)

FUNCTION updateProduct(productId, updatedFields):
    // Step 1: Update the database (source of truth)
    database.update("UPDATE products SET ... WHERE id = ?", updatedFields, productId)

    // Step 2: Invalidate the cache (don't update it)
    cache.DELETE("product:" + productId)

    // Next read will trigger a cache miss and repopulate from database

Cómo gestionar los errores de caché

FUNCTION getProductWithFallback(productId):
    TRY:
        RETURN getProduct(productId)    // Normal cache-aside path
    CATCH cacheConnectionError:
        // Cache is unavailable — fall back to database directly
        RETURN database.query("SELECT * FROM products WHERE id = ?", productId)
        // Log the error, trigger an alarm, but don't fail the request

Diseñe su aplicación de manera que los errores de la caché reduzcan el rendimiento (respuestas más lentas) pero no interrumpan la funcionalidad. La base de datos sirve como respaldo.

Estrategias de invalidación de caché

La invalidación garantiza que los usuarios vean los datos actuales después de las actualizaciones. Elija una estrategia en función de la rapidez con la que deben ser visibles los cambios.

En el caso de las aplicaciones de marketplace que también utilizan Amazon CloudFront como capa de CDN, coordine la invalidación en ambos niveles: elimine la ElastiCache clave y envíe una invalidación de la caché (o una invalidación de las etiquetas de CloudFront caché) para que los usuarios vean el contenido actualizado tanto en la capa de aplicación como en la capa perimetral.

Administración de conexiones

Métricas clave que se deben supervisar

Preguntas frecuentes

¿Cuándo debo usar sin servidor y cuándo usar uno basado en nodos?

Usa Serverless cuando tu tráfico sea impredecible (nuevos mercados, picos estacionales), cuando quieras evitar la planificación de la capacidad o cuando tu equipo no tenga experiencia en operaciones de almacenamiento en caché. Cambie a la tecnología basada en nodos cuando sus patrones de tráfico sean estables, necesite un control detallado de la fragmentación o cuando su rendimiento sostenido haga que la tecnología basada en nodos sea más rentable.

¿Debo usar Valkey o Redis OSS?

Use Valkey para nuevas implementaciones. Valkey es el motor predeterminado para los ElastiCache clústeres nuevos, es totalmente compatible con los comandos y las estructuras de datos de Redis OSS y está en continuo desarrollo. Los clústeres de Redis OSS existentes siguen funcionando: migre a Valkey cuando sea conveniente mediante la actualización local del motor.

¿Qué ocurre cuando la memoria caché no está disponible?

La aplicación debe tratar la memoria caché como una optimización, no como una dependencia. Si la caché no está disponible, vuelva a consultar la base de datos directamente. Los tiempos de respuesta serán más altos, pero la aplicación seguirá funcionando. Cuando Multi-AZ está habilitada, la falta total de disponibilidad de la caché es poco frecuente; la conmutación por error a una réplica normalmente se completa en menos de 30 segundos.

¿Cómo calculo la memoria que necesito?

Calcule: (número de elementos únicos para almacenar en caché) × (tamaño promedio por elemento) × (factor de sobrecarga de 1,2 para las estructuras de datos de Valkey). La sobrecarga varía según el tamaño del objeto y el tipo de datos; los objetos más pequeños tienen una sobrecarga proporcionalmente mayor. Por ejemplo, 100 000 productos de 2 KB cada uno con una sobrecarga de 1,2 veces = aproximadamente 240 MB. Agregue datos de sesión, resultados de búsqueda y recuentos de inventario. Comience con el margen de ampliación (utilice el 60% de la memoria disponible como objetivo) y supervise la DatabaseMemoryUsagePercentage métrica para ajustarla.