Faturar as Bases de Dados Pelo Que Realmente Usam

Cada app da Mythex que precisa de guardar dados recebe a sua própria base de dados Postgres, e a utilização da base de dados de uma app publicada sai do mesmo saldo de créditos usado para construir. Até ao fim de setembro, estimávamos essa utilização a partir do tempo em que o servidor da app esteve a correr. A estimativa revelou-se errada de uma forma que importava, por isso a substituímos: cada base de dados é agora faturada pelo cálculo que o seu fornecedor efetivamente mediu, uma hora concluída de cada vez, e cada hora só pode ser cobrada uma vez.

Como funcionam as bases de dados

Cada base de dados corre em Postgres serverless que escala para zero: depois de alguns minutos inativa, adormece, e acorda na consulta seguinte. Enquanto está acordada, pode aumentar ou diminuir o seu cálculo conforme a carga. É isso que torna viável "uma base de dados por app": a maioria das apps está parada na maior parte do tempo, e uma base de dados a dormir custa quase nada.

Isto também significa que o custo de uma base de dados depende de duas coisas que não conseguimos ver de fora: quanto tempo esteve acordada e quão grande era enquanto estava acordada.

O que a estimativa errava

O nosso medidor original fazia uma suposição: por cada hora em que o servidor de uma app publicada estava a correr, cobrava uma base de dados ao tamanho de cálculo mais pequeno.

Esse cálculo estava errado de três maneiras:

1. O tamanho estava errado. As bases de dados corriam, na prática, num tamanho predefinido maior do que o que a estimativa assumia.
2. As bases de dados escalam automaticamente. Sob carga, crescem, e a estimativa nunca via isso.
3. As bases de dados não seguem o servidor da app. Uma base de dados fica acordada sempre que qualquer coisa a consulta (a app, uma tarefa agendada, um script que a consulta de tempos a tempos), esteja ou não o servidor da app em funcionamento.

O efeito líquido: a estimativa cobrava aos utilizadores cerca de metade do que as bases de dados custavam de facto. Isso não é sustentável para nós, e também fazia com que os números de utilização da app não significassem o que as pessoas julgavam.

Medir em vez de adivinhar

O nosso fornecedor de bases de dados informa, para cada projeto, os segundos-unidade-de-cálculo por hora, ou seja, quanto cálculo foi realmente usado, incluindo o tamanho. Por isso, o medidor funciona agora assim:

1. Para cada app publicada com base de dados, obtém a utilização medida de cada hora concluída desde que a app foi colocada online.
2. Converte essa utilização em custo ao preço do fornecedor, aplica a tarifa do plano e cobra-a aos créditos do dono da app.
3. Olha para trás até um dia de cada vez, para que as horas perdidas enquanto a nossa API estava a reiniciar sejam faturadas mais tarde.

O armazenamento é faturado à parte, pelo tamanho, porque não depende da atividade.

Nunca cobrar uma hora duas vezes

Um medidor de faturação que corre em mais do que um servidor, e que pode falhar e tentar de novo, tem de ter cuidado para não cobrar em dobro. Cada hora de cada base de dados é reservada na sua própria linha da base de dados antes de ser cobrada, com uma restrição de unicidade no par (base de dados, hora). Se dois servidores, ou uma repetição, tentarem faturar a mesma hora, só uma reserva tem sucesso.

Tomámos também uma decisão deliberada para o caso raro de falha: se o processo falhar entre reservar uma hora e cobrá-la, essa hora fica reservada e não faturada. Perder uma pequena parte da receita numa falha rara é preferível a cobrar alguém duas vezes.

E quando a faturação medida foi ativada, começou na hora completa seguinte. As horas anteriores já tinham sido cobradas pela estimativa antiga; faturá-las outra vez a partir de dados medidos teria cobrado esse período em duplicado.

O que isto significa se construíres na Mythex

• A tua fatura de base de dados reflete o que a tua base de dados fez. Uma app pouco usada custa muito pouco; uma app que consulta a sua base de dados constantemente mantém-na acordada e custa mais.
• A maior alavanca é a forma como a tua app usa a base de dados. Consultar a base de dados a cada poucos segundos mantém-na acordada o tempo todo. Pedir à IA que vá buscar dados quando são necessários, ou guardá-los em cache, deixa a base de dados dormir. O nosso guia sobre o que é uma base de dados cobre o básico.
• Os planos Pro pagam metade da tarifa Grátis por alojamento, bases de dados e armazenamento. Os detalhes estão nos documentos de créditos.

O que retirámos disto

• As estimativas de custos baseados em utilização desviam-se. Quando o fornecedor a montante consegue dizer o que foi usado, fatura a partir disso.
• Torna a faturação idempotente na menor unidade que cobras. Para nós, é uma hora de base de dados.
• Quando tens de falhar, falha a favor do cliente.