4 ms·
Hi Kurt! We do the same metrics type thing at Inngest, and we share the exact same thoughts as you. We 'solved' it by, well, using Inngest to charge for Innge
by tonyhb 3y ago
Hi Kurt! We do the same metrics type thing at Inngest, and we share the exact same thoughts as you. We 'solved' it by, well, using Inngest to charge for Inngest.
We track everything as metrics, then hook up functions to read from the TSDB each billing period. How it works:
- One Inngest function runs each billing period (scheduled), and "fans out" by creating an event for each user we want to charge.
- A billing function reacts to these individual user events, queries metrics, queries our plans, and then generates a stripe invoice
- This is then charged by stripe.
- We have other functions that respond to other billing events and do dunning like flows.
We only have to focus on the small amount of billing code required. We don't have to handle scheduling, state, retries, or the event flows — that's built into Inngest.
I'd really like to make this more robust. We had to put in the work on emails, billing, and dunning, even if it is simple function code. It would be nice to have someone "productize" this. I feel your pain.
In general, it definitely makes sense to read from our own metrics stores to charge for our products. Very much agree with everything you've said. There's not the most joy in billing.
- hekike 3y agoVery cool, thanks for sharing. I like this reporting approach, once you have the usage data aggregated somewhere a state machine is a great way to report usage to Stripe. Do you trigger the Inngest billing fan out end of the month CRON style or when Stripe changes billing period and triggers a webhook to Inngest?