Design de esquema de pagamentos recorrentes no DynamoDB

Caso de uso de negócios de pagamentos recorrentes

Esse caso de uso fala sobre o uso do DynamoDB para implementar um sistema de pagamentos recorrentes. O modelo de dados tem as seguintes entidades: contas, assinaturas e recibos. Os detalhes do nosso caso de uso são os seguintes:

• Cada conta pode ter várias assinaturas.

• A assinatura tem uma NextPaymentDate quando o próximo pagamento precisar ser processado e uma NextReminderDate quando um lembrete por e-mail é enviado ao cliente.

• Há um item para a assinatura que é armazenado e atualizado quando o pagamento é processado (o tamanho médio do item é de cerca de 1 KB e o throughput depende do número de contas e assinaturas).

• O processador de pagamentos também criará um recibo como parte do processo, que é armazenado na tabela e está definido para expirar após um período usando um atributo TTL.

Diagrama de relacionamento de entidades de pagamentos recorrentes

Este é o diagrama de relacionamento de entidades (ERD) que usaremos para o design do esquema de pagamentos recorrentes.

Padrões de acesso recorrentes do sistema de pagamentos recorrentes

Estes são os padrões de acesso que vamos considerar para o design de esquema do sistema de pagamentos recorrentes.

1. createSubscription

2. createReceipt

3. updateSubscription

4. getDueRemindersByDate

5. getDuePaymentsByDate

6. getSubscriptionsByAccount

7. getReceiptsByAccount

Design de esquema de pagamentos recorrentes

Os nomes genéricos PK e SK são usados para atributos de chave com o objetivo de permitir o armazenamento de diferentes tipos de entidade na mesma tabela, como entidades de conta, assinatura e recibo. O usuário primeiro cria uma assinatura, na qual ele concorda em pagar uma quantia no mesmo dia de cada mês em troca de um produto. Ele pode escolher em qual dia do mês processar o pagamento. Também há um lembrete que será enviado antes do processamento do pagamento. A aplicação funciona com dois trabalhos em lote que são executados todos os dias: um trabalho em lote envia lembretes de vencimento naquele dia e o outro processa todos os pagamentos devidos naquele dia.

Etapa 1: abordar o padrão de acesso 1 (createSubscription)

O padrão de acesso 1 (createSubscription) é usado para criar inicialmente a assinatura, e os detalhes, incluindo SKU, NextPaymentDate, NextReminderDate e PaymentDetails, são definidos. Essa etapa mostra o estado da tabela para uma única conta com uma única assinatura. Pode haver várias assinaturas na coleção de itens, então essa é uma relação de um para muitos.

Etapa 2: abordar os padrões de acesso 2 (createReceipt) e 3 (updateSubscription)

O padrão de acesso 2 (createReceipt) é usado para criar o item de recibo. Depois que o pagamento for processado a cada mês, o processador de pagamentos enviará um recibo de volta à tabela base. Pode haver vários recibos na coleção de itens, então essa é uma relação de um para muitos. O processador de pagamentos também atualizará o item de assinatura [padrão de acesso 3 (updateSubscription)] para atualizar para NextReminderDate ou NextPaymentDate para o próximo mês.

Etapa 3: abordar o padrão de acesso 4 (getDueRemindersByDate)

A aplicação processa lembretes para o pagamento em lotes para o dia atual. Portanto, a aplicação precisa acessar as assinaturas em uma dimensão diferente: data, em vez de conta. Esse é um bom caso de uso para um índice secundário global (GSI). Nesta etapa, adicionamos o índice GSI-1, que usa NextReminderDate como a chave de partição do GSI. Não precisamos replicar todos os itens. Esse GSI é um índice esparso, e os itens de recibo não são replicados. Também não precisamos projetar todos os atributos, apenas incluir um subconjunto dos atributos. A imagem abaixo mostra o esquema de GSI-1 e fornece as informações necessárias para que a aplicação envie o e-mail de lembrete.

Etapa 4: abordar o padrão de acesso 5 (getDuePaymentsByDate)

A aplicação processa os pagamentos em lotes para o dia atual da mesma forma que faz para lembretes. Nesta etapa, adicionamos GSI-2, e ela usa a NextPaymentDate como a chave de partição do GSI. Não precisamos replicar todos os itens. Esse GSI é um índice esparso, e os itens de recibo não são replicados. A imagem abaixo mostra o esquema de GSI-2.

Etapa 5: abordar os padrões de acesso 6 (getSubscriptionsByAccount) e 7 (getReceiptsByAccount)

A aplicação pode recuperar todas as assinaturas de uma conta usando uma consulta na tabela base que tem como alvo o identificador da conta (o PK) e usa o operador de intervalo para obter todos os itens em que o SK começa com “SUB#”. A aplicação também pode usar a mesma estrutura de consulta para recuperar todos os recibos usando um operador de intervalo e obter todos os itens em que o SK começa com “REC#”. Isso nos permite cumprir os padrões de acesso 6 (getSubscriptionsByAccount) e 7 (getReceiptsByAccount). A aplicação usa esses padrões de acesso para que o usuário possa ver suas assinaturas atuais e os recibos anteriores dos últimos seis meses. Não há nenhuma alteração no esquema da tabela nesta etapa e podemos ver abaixo como consideramos apenas os itens de assinatura no padrão de acesso 6 (getSubscriptionsByAccount).

Todos os padrões de acesso e a forma como o design do esquema os aborda estão resumidos na tabela abaixo:

Padrão de acesso	Tabela base/GSI/LSI	Operation	Valor da chave de partição	Valores de chave de classificação
createSubscription	Tabela base	PutItem	ACC#account_id	SUB#<SUBID>#SKU<SKUID>
createReceipt	Tabela base	PutItem	ACC#account_id	REC#<RecieptDate>#SKU<SKUID>
updateSubscription	Tabela base	UpdateItem	ACC#account_id	SUB#<SUBID>#SKU<SKUID>
getDueRemindersByDate	GSI-1	Consulta	<NextReminderDate>
getDuePaymentsByDate	GSI-2	Consulta	<NextPaymentDate>
getSubscriptionsByAccount	Tabela base	Consulta	ACC#account_id	SK begins_with “SUB#”
getReceiptsByAccount	Tabela base	Consulta	ACC#account_id	SK begins_with “REC#”

Esquema final de pagamentos recorrentes

Veja aqui os designs do esquema final. Para baixar esse design de esquema como arquivo JSON, consulte DynamoDB Examples no GitHub.

Tabela base

GSI-1

GSI-2

Como usar o NoSQL Workbench com esse design de esquema

Você pode importar esse esquema final para o NoSQL Workbench, uma ferramenta visual que fornece atributos de modelagem de dados, visualização de dados e desenvolvimento de consultas para o DynamoDB, se quiser explorar e editar ainda mais seu novo projeto. Para começar, siga estas etapas:

1. Baixe o NoSQL Workbench. Para ter mais informações, consulte Baixar o NoSQL Workbench para DynamoDB.

2. Baixe o arquivo do esquema JSON listado acima, que já está no formato do modelo NoSQL Workbench.

3. Importe o arquivo do esquema JSON para o NoSQL Workbench. Para ter mais informações, consulte Importar um modelo de dados existente.

4. Depois de importar para o NOSQL Workbench, você pode editar o modelo de dados. Para ter mais informações, consulte Editar um modelo de dados existente.

5. Para visualizar o modelo de dados, adicionar dados de exemplo ou importar dados de exemplo de um arquivo CSV, use o atributo Visualizador de dados do NoSQL Workbench.