#neil_webhooks
unkempt breachBOT
👋 Welcome to your new thread!
⏲️ We'll be here soon! Typically we respond in a few minutes, but sometimes we might take a bit longer if the server is busy or if you have a particularly tricky question.
⏱️ We close idle threads, which makes them read-only. Once a thread is closed it won't be reopened, but you can always start a new thread if you have another question.
🔗 This thread will always be available, even after it's closed. You can find it again using Discord's search, or you can save this link: https://discord.com/channels/841573134531821608/1396834365706600640
📝 Have more to share? Add more details, code, screenshots, videos, etc. below.
tulip plaza
so you are sending us older data later. How can we ensure we have up-to-date data?
stoic girder
you have multiple ways of doing this
what we always recommend is not to rely on the object returned in the event but rather to retrieve it back from the API
the second thing would be on how you process your events
if you receive a customer.subscription.* event you can start by looking on whether the subscription is in your DB
if it's not you created
and then if you get a customer.subscription.created event you can just ignore it
because it's already created
tulip plaza
that would work if the first, update event, was committed to the db within 1ms.
which is a bit tight.
(the example events I posted above are 4ms apart, but that gap varies and can go down to 1ms)
stoic girder
this really depends on your architecture to be honest
in all cases retrieving the subscription object from the API would give you the latest version of the object
tulip plaza
hmm we currently rely on webhooks, which have been working great 99% of the time. It's a chunk of work to ignore the body and queue up requests... as we'd still have multiple at the same time.
What architecture do you recommend for this?
We have a fairly standard setup, multiple load-balanced containers to provide a responsive production API for our users.
unkempt breachBOT
timber jacinth
Hi, taking over as my teammate needs to step away. Let me catch up.
tulip plaza
thanks
timber jacinth
After you recieve the event, you can store the information in your database. After you recieve the event, you can look at your dsatabase and then action accordingly. You can also use the API to GET the object to see the latest data.
tulip plaza
The suggestion is to ignore the data in the webhook request, not store it, as it may be stale. Then we need to queue up or buffer and make an API request... that we currently don't do. That's a chunk of work to develop, given that webhooks work great 99% of the time.
It might be easier to make an architecture change, but making the system single-threaded isn't practical in production.
timber jacinth
You can track that 1% on your end and then make the GET call to attain the latest data
tulip plaza
As outlined above that is a chunk of work for us, suprising given how developer friendly Stripe is.
Are all other devs ignoring the webhook data and making GETs in response to each one?
timber jacinth
In that 1% that webhook that our recommendation, https://docs.stripe.com/webhooks#event-ordering
You can track these on your end, and then make the GET request since we do not guraantee the event ordering.
If you make GET requeests each time, you'd run into rate limiting issues as you scale so that is not recommended
You mentioned that it's rare, so I'm trying to provide recommendations for that 1%
tulip plaza
That it is rare does not reduce the amount of new code we will have to write and testing we will have to do to handle it.
Some throttling your end would solve it.
There are old github issues for this with many comments.
timber jacinth
Can you share which github issues you're referring to?
tulip plaza
timber jacinth
I'll share your feedback with the product team. Thank you for the feedback
tulip plaza
It was suggested above that there may be a different architecture that could handle this better... what would you suggest please?
timber jacinth
Are you referring to what my teammate said with 'this really depends on your architecture to be honest'? Or, something else?
tulip plaza
yes. It may be quicker for us to make an architecture change to handle this.