brandon_20831

[hollow salmon]

To add some more context, we're currently pretty far from the 20 invoice item limit (most customers sit at around 3-4 invoice items max) so that concern is more future facing

[keen bough]

@hollow salmon when you say

switching to a subscription per product model
You mean that your Customer can have multiple separate parallel Subscriptions?

[hollow salmon]

In the model we're considering, yes

Currently customers can only have a single subscription though

[keen bough]

my colleague @grand stone is going to take over and help with this!

[grand stone]

👋

[hollow salmon]

Sounds good, thanks!

[grand stone]

updating multiple products simultaneously would be pretty unperformant due to require an API call per subscription change
Under what circumstances would you be updating multiple products simultaneously?

[hollow salmon]

Our current checkout flow allows for updating all of our products at once, so a customer can have multiple upgrades, downgrades (or both) across the products that are currently subscription items

Let's say our products are Books, Newspapers, and Songs if that makes talking about it easier

[grand stone]

Ah, got it. As far as I know, there isn't really a workaround for doing batch updates like that. Operations on the Customer object are easy enough, since a single Customer update would affect all that Customer's Subscriptions, but when it comes to Subscription updates there's not really a way to lump them all into a single API call

And I'm not sure of a good workaround aside from the one you already found, if you want to have flexible billing cycles, >20 products, etc.

[hollow salmon]

Gotcha, thanks. That sounds like what we'd seen

Let's say we didn't support updates across multiple products, what particular considerations would you typically anchor on for recommending a multiple subscription vs subscription item model?

[grand stone]

That's a bit of a nebulous question. It sounds like you already found some of the major considerations, so it really just comes down to what you're trying to accomplish.

[hollow salmon]

Very fair, overly broad question. Just curious if you had particular recommendations you tend to rely on, but I appreciate the input on the batch subscription udpates

[grand stone]

All good! The only thing I think is definitely worth considering is scalability. Like, if you do batch updates, there are API rate limits: https://stripe.com/docs/rate-limits

So you if you spin-up a batch update system and then expand to reach a critical mass of customers, you may eventually run into API rate limits without a dynamic queueing system

[hollow salmon]

Thank you, appreciate the help!