Considerações sobre design

Tratamento de erros: se o cache ficar indisponível por qualquer motivo, o aplicativo deve proceder como se todos os itens estivessem perdidos. A existência da camada de cache não deve adicionar fragilidade a um aplicativo.

TTL: é possível configurar um único valor de TTL para todas as entradas de cache ou usar valores de TTL diferentes dependendo da entrada (por exemplo, get_itemquery, ou scan cache). Também é possível ter um valor de TTL diferente para entradas de cache negativas (solicitações que não retornaram itens).

Capacidade consumida: ao retornar uma resposta em cache, recomendamos que você ajuste as ConsumedCapacity métricas na resposta para indicar consumo zero de leitura.

Remoção dos metadados da resposta: você também deve remover a ResponseMetadata seção na resposta. Isso evita o risco de alguém ver um RequestId e pensar que é atual quando, na verdade, era horas antes.

Adição de metadados de cache: é útil adicionar uma CacheMetadata seção à resposta. Esta seção pode relatar a hora em que o valor foi armazenado (útil para medir a obsolescência) e a biblioteca cliente e a versão que armazenaram o valor (o que pode ser útil ao realizar uma atualização perfeita de uma versão para outra em que o formato é alterado).

Determinando o esquema da tabela: para determinar a chave primária de uma operação de gravação para invalidação do cache, você deve conhecer o esquema da tabela. Você pode obter essas informações usando uma describe_table chamada e um cache de longo prazo ElastiCache no primeiro uso (somente uma vez) para cada tabela.

Aceitar em vez de construir os clientes: uma vantagem de aceitar as instâncias do cliente DynamoDB e Redis no construtor (em vez de criá-las dentro do shim com base em parâmetros passados) é que isso permite que o chamador do construtor determine detalhes, como se devem ser definidos. read_from_replicas=True

Recurso de namespace: pode ser conveniente oferecer suporte a um namespace opcional no construtor que isola todas as leituras e gravações de cache nesse namespace. Usar um namespace é ideal para testes, pois cada execução com um namespace diferente parece começar com um cache vazio e não tem efeitos colaterais de execuções anteriores. Você também pode simular o esvaziamento de todo o cache na produção apenas alterando o namespace. Isso pode ser implementado adicionando automaticamente um prefixo a cada chave de pesquisa.

Cache de escaneamento: é difícil saber se as scan chamadas devem ser armazenadas em cache. Ao realizar uma varredura única de tabela completa, você não quer preencher o cache com páginas grandes de dados digitalizados que não serão lidos pela segunda vez. Por outro lado, muitas cargas de trabalho fazem varreduras repetidas, especialmente em tabelas menores, para fornecer os dados completos mais recentes da tabela a vários consumidores posteriores. Um compromisso seria implementar um sistema em que sejam necessárias duas chamadas, e cada chamada tenha a mesma assinatura (dentro do período TTL), para que a resposta de verificação resultante seja armazenada em cache. Isso evita o preenchimento do cache durante uma única varredura completa da tabela, ao mesmo tempo em que permite ciclos de varredura restritos para obter o benefício do armazenamento em cache. A primeira verificação coloca um pequeno espaço reservado no cache para marcar a solicitação como tendo sido feita uma vez. A segunda varredura substitui o valor do token pela carga real, que pode chegar a 1 MB.