Quentin

[main star]

Hello! We don't guarantee the order of Event delivery. Do the created timestamps on each Event occur in the order you expect? Or are you making rapid changes to the Subscription within the same second?

[rich kettle]

Thanks! The created timestamps are in the right order, but they are only 2ms apart, so the first one doesn't have time to be in the database when the second one is processed, and as I use a remote database like supabase, I can't access the database instantly, and so I can't control the order of the events in 2ms
What is the best practice? This must happen frequently

[main star]

Generally we recommend you put incoming Events into a queue and then process the queue serially based on the timestamps. Another approach is that if you hit a *.updated Event for an object you don't have a record of yet you can either fetch that object from the API or wait for/process the *.created Event before coming back to the *.updated Event.

[rich kettle]

Thanks for your response ! For the queue my problem is that I use a serverless function and therefore it is intended to have a very short execution time, I can not make it wait I think (maybe yes)

[mild raptor]

The architecture here is up to you. A short-life serverless function could acknowledge the delivery and enqueue for processing using either a queueing system or a DB table etc, then another period job does the processing.

[rich kettle]

Ok I see, do you have any example code snippets of a queue system for stripe events by chance?