Should i move destroying a high number of records in a background process?

Question

I have an activity stream that show users activities, imagine that one user update his avatar, then 1000 persons likes this activity, the result is 1 activity that shows the user updated his avatar, and 1000 other activities like this : person_1 likes photo of user x, person_2 likes photo of user x ..... person_1000 likes photo of user x

if the user update his avatar again the first one will be replaced by the new one and all of the 1000 "like" activities should be destroyed because the first avatar doesn't exist anymore, so i have a method called update_avatar like this :

 def update_avatar
     if @user.update(avatar_param)
         # ---------- destroy old activities -----------------
         # destroy the 1000 likes
         # destroy the initial activity : user added a new avatar
         # --------------------------------------------------------
         # create new activity for the new avatar
         ....
     end
 end

here when user update his avatar, i destroy all the old activities related with the old avatar, if the number of these activities is high (1000 in this example and can be more) i think this will take some time to destroy all of them ! should i run the part of code "destroy old activities" in a background process ?

thank you for help

Answer 1

You should generally run any slow process in a separate background job process - and lots of DB activities certainly qualifies.

This allows you to also insert other actions in the job later if you discover you want to add hooks for tasks always run before or after the big job.

Batch your DB activities too for performance and you're absolutely going in the right direction.

Id use the observer pattern to call a schedule_for_destruction job and then have that send the appropriate info to the job queue.

Answer 2

The short answer to this is: yes. However, I think this actually points to a design flaw in the program itself.

Perhaps instead of storing the user avatar for each activity, perhaps just store a pointer (foreign key) to the user object it references. That way, whenever the avatar gets updated it will automatically pull the new one.

Essentially, this way, you never will have to destroy 1000x objects because they will all still be valid (ie. the will still point to the same user object which will have the correct picture)