Cobrar os bancos de dados pelo que eles realmente usam

Todo app da Mythex que precisa armazenar dados ganha seu próprio banco Postgres, e o uso do banco de um app publicado sai do mesmo saldo de créditos usado para construir. Até o fim de setembro, nós estimávamos esse uso a partir de quanto tempo o servidor do app ficava ligado. A estimativa se mostrou errada de um jeito que importava, então a substituímos: cada banco agora é cobrado pela computação que o próprio provedor mediu, uma hora concluída por vez, e cada hora só pode ser cobrada uma única vez.

Como os bancos funcionam

Cada banco roda em Postgres serverless que escala para zero: depois de alguns minutos ociosos, ele dorme, e acorda na próxima consulta. Enquanto está acordado, pode aumentar e diminuir sua computação conforme a carga. É isso que torna viável “um banco por app”: a maioria dos apps fica quieta na maior parte do tempo, e um banco dormindo custa quase nada.

Isso também significa que o custo de um banco depende de duas coisas que não conseguimos ver de fora: por quanto tempo ele ficou acordado e quão grande ele estava enquanto acordado.

O que a estimativa errava

Nosso medidor original fazia uma suposição: para cada hora em que o servidor de um app publicado estava rodando, cobrar um banco no menor tamanho de computação.

Isso estava errado de três maneiras:

1. O tamanho estava errado. Os bancos na verdade rodavam em um tamanho padrão maior do que a estimativa supunha.
2. Os bancos escalam automaticamente. Sob carga, eles crescem, e a estimativa nunca percebia.
3. Os bancos não seguem o servidor do app. Um banco permanece acordado sempre que qualquer coisa o consulta — o app, um job agendado, um script que faz polling — esteja ou não o servidor do app no ar.

O efeito líquido: a estimativa cobrava dos usuários cerca da metade do que os bancos realmente custavam. Isso não é sustentável para nós, e também fazia com que os números de uso no app não significassem o que as pessoas achavam que significavam.

Medir em vez de adivinhar

Nosso provedor de banco informa, para cada projeto, as unidades de computação-segundo por hora, ou seja, quanta computação foi de fato usada, incluindo o tamanho. Então o medidor agora funciona assim:

1. Para cada app publicado com banco, busca o uso medido de cada hora concluída desde que o app entrou no ar.
2. Converte esse uso em custo pelo preço do provedor, aplica a taxa do plano e cobra dos créditos do dono do app.
3. Olha para trás até um dia a cada execução, para que as horas perdidas enquanto nossa API estava reiniciando ainda sejam cobradas depois.

O armazenamento é cobrado à parte, pelo tamanho, porque não depende de atividade.

Nunca cobrar a mesma hora duas vezes

Um medidor de cobrança que roda em mais de um servidor, e que pode travar e tentar de novo, precisa ter cuidado para não cobrar em dobro. Cada hora de cada banco é reservada na própria linha do banco de dados antes de ser cobrada, com uma restrição de unicidade sobre o par (banco, hora). Se dois servidores, ou uma nova tentativa, tentarem cobrar a mesma hora, apenas uma reserva tem sucesso.

Também fizemos uma escolha deliberada para o caso raro de falha: se o processo travar entre reservar uma hora e cobrá-la, aquela hora fica reservada e não cobrada. Perder uma fatia pequena de receita em uma queda rara é melhor do que cobrar alguém duas vezes.

E quando a cobrança medida foi ativada, ela começou a partir da próxima hora cheia. As horas anteriores já tinham sido cobradas pela estimativa antiga; cobrá-las de novo a partir de dados medidos teria cobrado esse trecho duas vezes.

O que isso significa se você constrói na Mythex

• A conta do seu banco agora reflete o que o seu banco fez. Um app pouco usado custa muito pouco; um app que consulta o banco constantemente o mantém acordado e custa mais.
• A maior alavanca é como o seu app usa o banco. Fazer polling no banco a cada poucos segundos o mantém acordado o tempo todo. Pedir à IA que busque dados sob demanda, ou armazená-los em cache, deixa o banco dormir. Nosso guia sobre o que é um banco de dados cobre o básico.
• Os planos Pro pagam metade da taxa do Free por hospedagem, bancos de dados e armazenamento. Os detalhes estão nos documentos de créditos.

O que tiramos disso

• Estimativas de custos baseados em uso se distanciam da realidade. Quando o provedor a montante consegue dizer o que foi usado, cobre a partir disso.
• Torne a cobrança idempotente na menor unidade que você cobra. Para nós, isso é uma hora de banco de dados.
• Quando for preciso falhar, falhe a favor do cliente.