Fakturera databaser efter vad de faktiskt använder

Varje Mythex-app som behöver lagra data får sin egen Postgres-databas, och en publicerad apps databasanvändning dras från samma kreditsaldo som byggandet. Fram till slutet av september uppskattade vi den användningen utifrån hur länge appens server var igång. Uppskattningen visade sig vara fel på ett sätt som spelade roll, så vi ersatte den: varje databas faktureras nu utifrån den beräkningskraft leverantören faktiskt mätte, en avslutad timme i taget, och varje timme kan bara debiteras en gång.

Hur databaserna fungerar

Varje databas körs på serverless Postgres som skalar ner till noll: efter några minuters inaktivitet somnar den, och den vaknar vid nästa fråga. När den är vaken kan den skala sin beräkningskraft upp och ner efter belastningen. Det är det som gör ”en databas per app” överkomligt — de flesta appar är lugna större delen av tiden, och en sovande databas kostar nästan ingenting.

Det innebär också att kostnaden för en databas beror på två saker vi inte kan se utifrån: hur länge den var vaken och hur stor den var när den var vaken.

Vad uppskattningen hade fel på

Vår ursprungliga mätare gjorde ett antagande: för varje timme en publicerad apps server kördes, debiterades en databas till den minsta beräkningsstorleken.

Det var fel på tre sätt:

1. Storleken var fel. Databaserna kördes faktiskt på en större standardstorlek än uppskattningen utgick från.
2. Databaserna skalar automatiskt. Under belastning växer de, och uppskattningen såg aldrig det.
3. Databaserna följer inte appservern. En databas är vaken så länge något frågar den — appen, ett schemalagt jobb, ett skript som pollar den — oavsett om appens server var igång.

Nettoeffekten: uppskattningen debiterade användarna ungefär hälften av vad databaserna faktiskt kostade. Det går inte att driva i längden, och det gjorde dessutom att användningssiffrorna i appen inte betydde vad folk trodde att de betydde.

Mäta i stället för att gissa

Vår databasleverantör rapporterar varje projekts beräkningsenhetssekunder per timme — hur mycket beräkningskraft det faktiskt använde, storleken inräknad. Så mätaren fungerar nu så här:

1. För varje publicerad app med databas, hämta den uppmätta användningen för varje avslutad timme sedan appen gick live.
2. Omvandla användningen till kostnad enligt leverantörens pris, tillämpa planens taxa och debitera appägarens krediter.
3. Titta bakåt upp till ett dygn varje gång, så att timmar som missades när vårt API startades om fortfarande faktureras senare.

Lagring faktureras separat, efter storlek, eftersom den inte beror på aktivitet.

Aldrig debitera en timme två gånger

En faktureringsmätare som körs på mer än en server — och som kan krascha och försöka igen — måste vara noga med att inte debitera dubbelt. Varje timme för varje databas görs anspråk på i en egen databasrad innan den debiteras, med en unikhetsregel på paret (databas, timme). Om två servrar, eller ett nytt försök, försöker debitera samma timme lyckas bara ett anspråk.

Vi gjorde också ett medvetet val för det sällsynta felfallet: om processen kraschar mellan att timmen görs anspråk på och att den debiteras, förblir timmen ett anspråk utan debitering. Att förlora en liten del av intäkten vid en sällsynt krasch är bättre än att någon någonsin debiteras två gånger.

Och när uppmätt fakturering slogs på började den vid nästa hela timme. De timmar som låg före hade redan debiterats av den gamla uppskattningen; att debitera dem igen utifrån mätdata hade debiterat den sträckan två gånger.

Vad detta betyder om du bygger på Mythex

• Din databasfaktura speglar nu vad din databas gjorde. En app som sällan används kostar mycket lite; en app som hela tiden frågar sin databas håller den vaken och kostar mer.
• Den största hävstången är hur din app använder databasen. Att fråga databasen med några sekunders mellanrum håller den vaken dygnet runt. Om AI:n hämtar data när det behövs, eller cachar den, kan databasen somna. Vår guide om vad en databas är går igenom grunderna.
• Pro-planer betalar hälften av Free-taxan för hosting, databaser och lagring. Detaljerna finns i kreditdokumentationen.

Det vi lärde oss

• Uppskattningar av användningsbaserade kostnader glider. När leverantören uppströms kan berätta vad som användes, fakturera utifrån det.
• Gör faktureringen idempotent på den minsta enhet du debiterar. För oss är det en databastimme.
• När du måste misslyckas, misslyckas till kundens fördel.