rafal/fix-slow-multistream-delete

[leszko]

We have a problem with PATCH/DELETE multistream target. The issue is that when user has a lot of streams, then this becomes a very DB-heavy request.

The proposed workaround is to skip notifying Catalyst about the multistream update in case of not passing by the user a helper streamId or playbackId as query param. So it will work right now this way:

1. If user does not change anything in their API usage, then the Catalyst will not be notified about the multistream delete or patch => Then their multistream will be refreshed only after 30s (instead of instant refresh)
2. If user updates their API call to include streamId or playbackId in the query params, then it will work as before.
   • Now: DELETE /api/multistream/target/fabb8085-5d71-4807-919e-abd7410f051b
   • After: DELETE /api/multistream/target/fabb8085-5d71-4807-919e-abd7410f051b?streamId=abcdef

The root cause is our studio DB architecture and the design decision that 1 multistream can be related to multiple streams. This with comparison with storing everything as JSON and multiple target in a single stream creates the issue: we can only use GIN index, which happens to be too slow with the number of streams users have.

[vercel]

The latest updates on your projects. Learn more about Vercel for Git ↗︎

Name	Status	Preview	Comments	Updated (UTC)
livepeer-studio	✅ Ready (Inspect)	Visit Preview	💬 Add feedback	Apr 7, 2025 0:31am

[leszko]

Closing this one, since @victorges found a better solution here: #2333