performance considerations - many shares write of activites

Steps to reproduce

1. create a group "test" with ~100 users (use a slower setup like hdd-database / ~16 users starting already to get recognisable for e.g. creating a comment in a deck-card)
2. share a entity like a "folder" or a "deck board" with this group
3. every save action in the frontend on this enties are now delayed and the frontend is not efficiently usable.

Actual behaviour

For me it seems that on every save action 100 entries needs to get calculated and written to the activity table.
It seems that this is happening blocking on the frontend calls and not done afterwards/in the background.

Expected behaviour

Could this be done afterwards by let the frontend call finishing fast and store only one entry there which then get populated by a follow up non-blocking ghost process? could the maybe existing redis be used as a queue?

To keep that in perspective, our activity table has some million entries and it is blazing fast in showing/selecting the activities.
We only have this issue for the writes and only if we have many activites on a specific operation (cause of many shares).

We are wondering if we are the first who have/had this issue.
We are really open for tipps (without disable the app or make smaller shares)

No implementation files or tests are named. Start by tracing the save path that writes activity rows and reproduce it with a roughly 100-user group; done means frontend saves no longer wait on hundreds of activity writes while the resulting activity data remains available.