Fatturare i database in base a ciò che usano davvero

Ogni app Mythex che deve memorizzare dati ottiene un proprio database Postgres, e l'uso del database di un'app pubblicata viene scalato dallo stesso saldo di crediti usato per la build. Fino a fine settembre stimavamo quell'uso a partire da quanto tempo era in esecuzione il server dell'app. La stima si è rivelata sbagliata in un modo che contava, quindi l'abbiamo sostituita: ogni database viene ora fatturato in base al calcolo che il suo provider ha effettivamente misurato, un'ora completata alla volta, e ogni ora può essere addebitata una sola volta.

Come funzionano i database

Ogni database gira su Postgres serverless che scala a zero: dopo qualche minuto di inattività si addormenta, e si risveglia alla query successiva. Quando è sveglio, può aumentare o ridurre il proprio calcolo in base al carico. È ciò che rende sostenibile "un database per app": la maggior parte delle app è tranquilla per la maggior parte del tempo, e un database addormentato costa quasi nulla.

Significa anche che il costo di un database dipende da due cose che dall'esterno non vediamo: per quanto tempo è stato sveglio e quanto era grande mentre era sveglio.

Cosa sbagliava la stima

Il nostro primo contatore faceva un'ipotesi: per ogni ora in cui il server di un'app pubblicata era in esecuzione, addebitava un database alla dimensione di calcolo più piccola.

Questo era sbagliato in tre modi:

1. La dimensione era sbagliata. I database giravano in realtà a una dimensione predefinita più grande di quella che la stima supponeva.
2. I database scalano automaticamente. Sotto carico crescono, e la stima non lo vedeva mai.
3. I database non seguono il server dell'app. Un database resta sveglio ogni volta che qualcosa lo interroga, l'app, un job pianificato, uno script che lo controlla di continuo, indipendentemente dal fatto che il server dell'app sia attivo.

Risultato netto: la stima addebitava agli utenti circa la metà di quanto i database costavano davvero. Non è sostenibile per noi, e faceva sì che i numeri di utilizzo nell'app non significassero ciò che la gente credeva significassero.

Misurare invece di indovinare

Il nostro provider di database riporta, per ogni progetto, i secondi-unità-di-calcolo per ora, cioè quanto calcolo ha usato davvero, dimensione inclusa. Quindi il contatore ora funziona così:

1. Per ogni app pubblicata con un database, recupera l'utilizzo misurato per ogni ora completata dal momento in cui l'app è andata live.
2. Converti quell'utilizzo in costo al prezzo del provider, applica la tariffa del piano e addebitalo sui crediti del proprietario dell'app.
3. Ogni volta guarda indietro fino a un giorno, così le ore perse mentre la nostra API si riavviava vengono comunque fatturate più tardi.

Lo spazio di archiviazione viene fatturato separatamente, per dimensione, perché non dipende dall'attività.

Non addebitare mai un'ora due volte

Un contatore di fatturazione che gira su più di un server, e che può andare in crash e riprovare, deve stare attento a non addebitare due volte. Ogni ora di ogni database viene rivendicata nella propria riga del database prima di essere addebitata, con un vincolo di unicità sulla coppia (database, ora). Se due server, o un tentativo ripetuto, provano a fatturare la stessa ora, solo una rivendicazione riesce.

Abbiamo anche fatto una scelta deliberata per il raro caso di guasto: se il processo va in crash tra la rivendicazione di un'ora e il suo addebito, quell'ora resta rivendicata e non fatturata. Perdere una piccola parte dei ricavi in un crash raro è meglio che addebitare qualcuno due volte.

E quando la fatturazione misurata si è attivata, è partita dall'ora successiva completa. Le ore precedenti erano già state addebitate dalla vecchia stima; fatturarle di nuovo dai dati misurati avrebbe addebitato due volte quel tratto.

Cosa significa se costruisci su Mythex

• La bolletta del tuo database ora riflette ciò che il tuo database ha fatto. Un'app usata di rado costa pochissimo; un'app che interroga il suo database di continuo lo tiene sveglio e costa di più.
• La leva più grande è come la tua app usa il database. Interrogare il database ogni pochi secondi lo tiene sveglio tutto il giorno. Chiedere all'AI di recuperare i dati su richiesta, o memorizzarli nella cache, lascia dormire il database. La nostra guida a cos'è un database copre le basi.
• I piani Pro pagano la metà della tariffa Free per hosting, database e archiviazione. I dettagli sono nella documentazione sui crediti.

Cosa ne abbiamo ricavato

• Le stime dei costi basati sull'uso si discostano. Quando il provider a monte può dirti cosa è stato usato, fattura da quel dato.
• Rendi la fatturazione idempotente all'unità più piccola che addebiti. Per noi è un'ora di database.
• Quando devi sbagliare, sbaglia a favore del cliente.