Application design: When to utilize cascade deletion?

Hello all, I’m curious how you all think about cascade deletion. E.g. when one table belongs_to another table and you specify in the migration “on_delete: delete_all”.

From an application design perspective, when is this the right thing vs wrong thing to do? This question may also relate to GDPR but I’m not sure. For example, I’m developing an education platform where users can take courses. The owner of a course may want to delete that course, but then the students who paid to take it would lose their information related to that course if I did cascade deletion for all the information. So it might be better to “archive” that information in some form to satisfy both parties.

What are your thoughts on striking the right balance?

I like to cascade deletes when deleting an Aggregate Root and having it cascade to the closely related entities encapsulated by the aggregate.

Associations between aggregates don’t need cascading deletes, or even necessarily foreign key constraints between them.

The question I ask myself is “could this group of tables be split off into a separate DB/service in future?” If so, then there can’t be cascading deletes or RI enforced if/when that happens, so try not to rely on it too heavily now.

2 Likes