As traduções são geradas por tradução automática. Em caso de conflito entre o conteúdo da tradução e da versão original em inglês, a versão em inglês prevalecerá.

Amazon ElastiCache (Valkey) para aplicativos de comércio eletrônico

Um aplicativo de comércio eletrônico se beneficia de uma camada de cache na memória entre os servidores de aplicativos e o banco de dados. A Amazon que ElastiCache executa o Valkey fornece latência de leitura de menos de um milissegundo para dados acessados com frequência — entradas no catálogo de produtos, contagens de inventário, resultados de pesquisa e sessões de usuários — reduzindo a carga do banco de dados e melhorando os tempos de resposta durante picos de tráfego.

Configuração do cluster

Escolha um tipo de cluster com base em seu volume de dados, requisitos de taxa de transferência e preferências operacionais.

Para a maioria dos aplicativos de comércio eletrônico iniciantes, o Serverless fornece o caminho mais simples para a produção. Migre para clusters baseados em nós quando tiver linhas de base de tráfego previsíveis e precisar de mais controle sobre a topologia do cluster, os tipos de nós e o comportamento de escalabilidade.

Design chave para dados do produto

Crie chaves de cache para serem previsíveis, depuráveis e com escopo definido para evitar colisões entre os tipos de dados.

Principais práticas recomendadas de design:

Estratégia TTL por tipo de dados

Defina valores de TTL (tempo de vida útil) com base na frequência com que os dados mudam e em quão obsoletos eles podem ficar sem afetar a experiência do cliente.

Cache-aside padrão

O padrão cache-aside (também chamado de carregamento lento) é a estratégia de armazenamento em cache mais comum para aplicativos de comércio eletrônico. Seu aplicativo verifica o cache primeiro e só consulta o banco de dados em caso de falha de cache.

Caminho de leitura (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

Caminho de gravação (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

Lidando com falhas de cache

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

Projete seu aplicativo de forma que a falha no cache prejudique o desempenho (respostas mais lentas), mas não prejudique a funcionalidade. O banco de dados serve como substituto.

Estratégias de invalidação de cache

A invalidação garante que os usuários vejam os dados atuais após as atualizações. Escolha uma estratégia com base na rapidez com que as mudanças devem estar visíveis.

Para aplicativos de mercado que também usam a Amazon CloudFront como uma camada de CDN, coordene a invalidação em ambas as camadas: exclua a ElastiCache chave e envie uma invalidação do CloudFront cache (ou invalidação da tag de cache) para que os usuários vejam o conteúdo atualizado nas camadas do aplicativo e da borda.

Gerenciamento de conexões

Principais métricas a serem monitoradas

Perguntas frequentes

Quando devo usar o Serverless versus o baseado em nós?

Use o Serverless quando seu tráfego for imprevisível (novo mercado, picos sazonais), quando quiser evitar o planejamento de capacidade ou quando sua equipe não tiver experiência em operações de cache. Mude para o baseado em nós quando seus padrões de tráfego estiverem estáveis, você precisar de um controle refinado sobre a fragmentação ou quando sua taxa de transferência sustentada tornar a base em nós mais econômica.

Devo usar Valkey ou Redis OSS?

Use o Valkey para novas implantações. O Valkey é o mecanismo padrão para novos ElastiCache clusters, é totalmente compatível com os comandos e estruturas de dados do Redis OSS e recebe desenvolvimento contínuo. Os clusters Redis OSS existentes continuam funcionando — migre para o Valkey quando for conveniente usando a atualização do mecanismo local.

O que acontece quando o cache não está disponível?

Seu aplicativo deve tratar o cache como uma otimização, não como uma dependência. Se o cache não estiver disponível, volte a consultar diretamente o banco de dados. Os tempos de resposta serão maiores, mas o aplicativo permanecerá funcional. Quando Multi-AZ ativado, a indisponibilidade total do cache é rara — o failover para uma réplica normalmente é concluído em menos de 30 segundos.

Como faço para estimar a memória de que preciso?

Calcule: (número de itens exclusivos para armazenar em cache) × (tamanho médio por item) × (fator de sobrecarga de 1,2 para estruturas de dados Valkey). A sobrecarga varia de acordo com o tamanho do objeto e o tipo de dados — objetos menores têm uma sobrecarga proporcionalmente maior. Por exemplo, 100.000 produtos de 2 KB cada um com 1,2x de sobrecarga = aproximadamente 240 MB. Adicione dados de sessão, resultados de pesquisa e contagens de inventário. Comece com espaço livre (use 60% da memória disponível como meta) e monitore a DatabaseMemoryUsagePercentage métrica para ajustar.