Um modelo de dados de assinatura SaaS

SaaS (Software as a Service) é um dos três principais componentes da computação em nuvem. Normalmente, os aplicativos SaaS são baseados na Web e podem lidar com muitos usuários diferentes ao mesmo tempo. As soluções baseadas em assinatura são ofertas de SaaS muito populares. Alguns produtos SaaS conhecidos incluem Microsoft Office 365, Amazon Web Services (AWS), Slack, Jira, Stripe e (é claro) Vertabelo! Hoje vamos dar uma olhada em um modelo de dados que nos permitiria gerenciar assinaturas de SaaS.

A ideia

Os produtos SaaS podem ser muito diferentes. Alguns cobram pelos seus serviços regularmente, por ex. mensal ou anual; outros cobram apenas pela quantidade de tempo ou recursos usados (ou uma combinação desses dois). Para manter as coisas simples neste artigo, vou me concentrar apenas nas assinaturas pagas mensais.

Vamos supor que temos algumas soluções SaaS diferentes e precisamos rastrear todos os nossos assinantes em um banco de dados. Esse pode ser o caso quando estamos fornecendo soluções de banco de dados (por exemplo, Amazon DynamoDB), ferramentas de análise (por exemplo, Amazon Athena) ou aplicativos de robótica (por exemplo, AWS RoboMaker). De fato, se olharmos para a Amazon, podemos ver que existem muitos aplicativos diferentes disponíveis. Escolhemos apenas aqueles que realmente precisamos.

Modelo de dados

O modelo consiste em três áreas temáticas:

Users & groups
Software & plans
Subscriptions, plans & payments.

Descreveremos cada uma dessas áreas de assunto na ordem em que estão listadas.

Seção 1:usuários e grupos

O Users & groups área de assunto armazena informações sobre todos os usuários do nosso aplicativo. Vamos supor que os usuários podem ser agrupados, por exemplo. quando uma empresa quer comprar licenças para vários funcionários. Criaremos um grupo mesmo quando apenas um usuário pertencer a ele. Isso nos dará a flexibilidade de adicionar novos membros a esse grupo posteriormente.

A tabela mais importante aqui é a user_account tabela. Vamos usá-lo para armazenar todos os detalhes relacionados às contas de usuário. Esses são:

first_name & last_name – O nome e sobrenome do usuário. Observe que cada usuário armazenado aqui é um indivíduo particular.
user_name – Um nome de usuário (escolhido pelo usuário).
password – Um valor de hash da senha do usuário. (Os usuários definem suas próprias senhas.)
email – O endereço de e-mail do usuário, definido durante o processo de registro.
confirmation_code – O código usado durante o processo de confirmação por e-mail.
confirmation_time – Quando o registro/confirmação foi concluído.
insert_ts – O carimbo de data/hora em que este registro foi inserido inicialmente.

Os usuários podem criar grupos; grupos têm tipos predefinidos. Uma lista de todos os tipos de grupos possíveis é armazenada no user_group_type tabela. Cada tipo é definido EXCLUSIVAMENTE por seu type_name . Também definiremos o número mínimo e máximo de membros do grupo permitidos para cada tipo de grupo. Esse intervalo é definido com dois valores – members_min (o limite inferior) e members_max (o limite superior).

Ao criar uma nova conta, os usuários também selecionarão seu grupo de usuários. Isso criará um novo registro no user_group tabela referenciando o tipo de grupo selecionado e armazenando o timestamp (insert_ts ) quando este registro foi inserido. O customer_invoice_data atributo é uma descrição textual do que imprimiremos na fatura para esse grupo de usuários.

A última tabela nesta área de assunto é o in_group tabela. Para cada grupo, armazenaremos uma lista de todos os seus membros. Além das referências ao grupo de usuários (user_group_id ) e conta de usuário (user_account_id ), também armazenaremos o carimbo de data/hora quando um usuário foi adicionado ao grupo (time_added ) ou removido do grupo (time_removed , que só conterá um valor se o usuário tiver sido removido). Também teremos um sinalizador para indicar se o usuário é o group_admin ou não. Os administradores do grupo podem atualizar os membros do grupo e adicionar novos membros.

Seção 2:Software e Planos

Em seguida, precisamos definir tudo o que vamos oferecer aos nossos (potenciais) clientes. Podemos oferecer apenas um tipo de software, mas há uma grande possibilidade de termos várias ofertas diferentes. Um exemplo comum desse caso é ter uma ferramenta SaaS separada de seu aplicativo de análise, por exemplo, Stripe e Stripe Sigma. Abordaremos esses casos em nosso modelo de dados.

Começaremos com o software tabela. Neste dicionário, armazenaremos uma lista de todas as nossas ofertas de SaaS. Para cada um, armazenaremos:

software_name – Um nome de software EXCLUSIVO.
details – Todos os detalhes que descrevem esse software.
access_link – Um local ou link onde podemos acessar esse software.

Devemos ser capazes de oferecer nossas soluções SaaS em um ou mais planos diferentes. Cada plano contém várias opções. Por exemplo, podemos ter um plano premium que inclua todas as opções que oferecemos e um plano básico que inclua apenas o essencial. Armazenaremos todos os planos distintos no plan tabela. Para cada plano, definiremos:

plan_name – O nome que selecionamos para este plano. Juntamente com a referência ao software (software_id ), isso forma a chave alternativa/ÚNICA desta tabela.
user_group_type_id – Uma referência indicando o tipo de grupo que pode usar este plano. Pode ser um grupo de usuário único ou um grupo padrão. Esta referência também define o número máximo de membros do grupo para esse plano – por exemplo, se nosso plano permitir cinco contas diferentes em uma assinatura, devemos fazer referência ao user_group_type apropriado .
current_price – O preço atual para este plano.
insert_ts – O carimbo de data/hora em que este registro foi inserido.
active – Um sinalizador indicando se este plano está ativo ou não.

Já mencionamos que os planos para o mesmo software virão com opções diferentes. Uma lista de todas as opções distintas é armazenada na option dicionário. Cada opção é definida EXCLUSIVAMENTE por seu option_name .

Para atribuir opções a diferentes planos, usaremos a option_included tabela. Ele armazena referências ao plano relacionado (plan_id ) e opção (option_id ). Este par, junto com o date_added atributo, forma a chave UNIQUE desta tabela. O date_removed O atributo conterá um valor somente se decidirmos remover uma determinada opção de um plano. Isso pode acontecer quando criamos uma nova opção para substituir a antiga ou decidimos não ter mais uma determinada opção porque poucas pessoas a usam.

A última parte desta área temática está relacionada com ofertas especiais ou promocionais. Em geral, essas ofertas oferecem aos clientes mais serviços por menos dinheiro e duram um determinado período de tempo. Eles podem ter como objetivo adquirir novos clientes ou vender atualizações de planos (ou uma gama mais ampla de serviços) para clientes existentes.

Todas as nossas ofertas promocionais são armazenadas na offer tabela. Para cada oferta, precisaremos definir:

offer_name – Um nome EXCLUSIVO que selecionamos para esta oferta.
offer_start_date e offer_end_date – O período de tempo durante o qual esta oferta está disponível.
description – Uma descrição textual detalhada da oferta.
Descontos:precisamos de flexibilidade para ter dois tipos de descontos – um desconto baseado em valor fixo (por exemplo, ganhe US$ 50 de desconto) e um desconto percentual (por exemplo, economize 25%). Se oferecermos um desconto fixo, inseriremos esse valor no discount_amount atributo; se oferecermos um desconto percentual, inseriremos esse percentual no discount_percentage atributo.
Duração:usaremos aqui a mesma lógica que usamos para os descontos. Em alguns casos, as ofertas durarão um número definido de meses (por exemplo, 24 meses após a inscrição dos clientes); nesses casos, definiremos a duration_months valor. Outras ofertas serão válidas até uma determinada data fixa (por exemplo, até 31 de dezembro de 2019); para estes, vamos definir a data e armazená-la em duration_end_date atributo.

Usaremos as duas tabelas restantes nesta área de assunto para definir o que cada oferta contém e quais pré-requisitos ela possui. Para isso, usaremos duas tabelas:include e prerequisite . Eles compartilham a mesma estrutura e contêm o mesmo par ÚNICO de offer_id – plan_id . Algumas ofertas podem não ter nenhum pré-requisito, enquanto outras podem – por exemplo, se estivermos oferecendo um desconto para atualizar para um plano com mais usuários ou uma assinatura de software para usuários de algum outro software.

As ofertas podem ser complexas, então vou dar alguns exemplos.

Se atualmente usamos o Plano A e temos uma oferta de upgrade para o Plano B, isso é simples.
Se tivermos duas ofertas, “upgrades do plano A para o plano B” e “upgrades do plano B para o plano C”, devemos criar mais uma oferta:“upgrades do plano A diretamente para o plano C”. Isso permite que os usuários atualizem seus planos em uma etapa em vez de duas. Um exemplo desse upgrade é alterar uma assinatura que atualmente permite cinco usuários por grupo para uma que permite 20 usuários por grupo sem parar em um plano intermediário de dez usuários por grupo ao longo do caminho.
Se um grupo usar o Produto A, poderemos ter uma oferta especial para assinar os Produtos B e C a um preço promocional. Também poderíamos ter duas ofertas separadas para assinar apenas o Produto B e apenas o Produto C.

Em geral, devemos ter uma oferta que mudará o plano atual para o plano desejado sem etapas intermediárias e apenas uma oferta para assinar um ou mais novos produtos.

Seção 3:assinaturas, planos e pagamentos

A última área temática conecta as duas áreas mencionadas anteriormente e é o verdadeiro coração deste modelo.

Todas as assinaturas são armazenadas na subscription tabela. Trataremos cada plano diferente como uma assinatura separada, mesmo que essas assinaturas/planos sejam o resultado da mesma oferta. A razão para isso é que poderemos gerenciar assinaturas separadamente – por exemplo, cancelá-los separadamente se quiséssemos. Vamos precisar definir uma série de detalhes aqui:

user_group_id – O ID do grupo que assina este plano. Isso é importante porque os usuários não serão inscritos individualmente; eles são inscritos indiretamente, como parte do grupo.
trial_period_start_date e trial_period_end_date – Os limites inferior e superior do período de avaliação (se houver) para esta assinatura.
subscribe_after_trial – Um sinalizador indicando se a assinatura será renovada automaticamente após o término do período de avaliação (se houver).
current_plan_id – O plano atual para essa assinatura. Se a assinatura não estiver mais ativa, este atributo conterá o valor do último plano ativo.
offer_id – Uma referência à oferta à qual esta assinatura está relacionada. Este atributo conterá um valor somente se esta assinatura for resultado de uma determinada oferta.
offer_start_date e offer_end_date – O limite inferior e superior do período durante o qual esta oferta esteve ativa. Esses atributos serão definidos apenas se esta assinatura for resultado de uma determinada oferta.
date_subscribed – Quando este grupo se inscreveu nesta assinatura.
valid_to – A última data em que esta assinatura é válida. No caso de uma assinatura mensal, podemos esperar que valid_to será definido para o final do mês atual. Se um cliente cancelar a assinatura a qualquer momento durante um mês, ele ainda poderá usar o software até o final desse mês.
date_unsubscribed – A data em que esse grupo cancelou a assinatura desta assinatura. Podemos esperar que esta data seja definida manualmente pelo administrador do grupo quando o grupo decidir não usar mais o serviço. No entanto, também pode ser definido automaticamente, de acordo com critérios predefinidos - por exemplo, cancelar automaticamente a assinatura de um grupo de seu serviço se houver duas ou mais faturas não pagas.
insert_ts – O carimbo de data/hora em que este registro foi inserido.

Os planos de assinatura geralmente mudam com o tempo. Para manter um histórico completo de todos os nossos planos, armazenaremos todas as alterações de plano no plan_history tabela. Para cada registro aqui, precisaremos de:

subscription_id – O ID da assinatura relacionada.
plan_id – O ID do plano relacionado.
date_start e date_end – O período de tempo em que este plano estava ativo.
insert_ts – O carimbo de data/hora em que este registro foi inserido.

A última tabela em nosso modelo armazenará nossas invoices . Para cada fatura, manteremos os seguintes detalhes:

customer_invoice_data – Uma descrição do cliente faturado por esta fatura. Estes serão os dados de user_group.customer_invoice_data no momento em que a fatura foi gerada.
subscription_id – O ID da assinatura relacionada.
plan_history_id – O ID do plano ativo durante este período de fatura.
invoice_period_start_date e invoice_period_end_date – O intervalo de tempo (por exemplo, 1º de janeiro de 2019 a 31 de janeiro de 2019) coberto por esta fatura.
invoice_description – Uma breve descrição textual da fatura.
invoice_amount – O valor do pagamento devido para esta fatura.
invoice_created_ts – Quando esta fatura foi gerada e inserida na tabela.
invoice_due_ts – Quando esta fatura vencer.
invoice_paid_ts – O carimbo de data/hora em que esta fatura foi paga.

Diga-nos o que você pensa sobre o modelo de dados SaaS

Acho que a maioria de vocês conheceu o SaaS, seja como desenvolvedor ou como usuário. Aguardo sua opinião sobre isso e sobre este modelo de dados. Sinta-se à vontade para compartilhar suas experiências e sugestões nos comentários abaixo.