Rails dependent: :destroy Can Silently Cause Timeouts at Scale

In Ruby on Rails, using dependent: :destroy on a parent model triggers individual destroy callbacks for every associated child record, which can cause severe performance issues when data grows large. For example, deleting an Author with 1,000 books fires after_destroy callbacks — such as Elasticsearch reindexing and touch updates — 1,000 times in series. This pattern often goes unnoticed in development but causes production timeouts once real data volumes accumulate. A safer approach is to first use delete_all on child records within a transaction, which bypasses callbacks entirely via a single SQL statement, then destroy the parent. Any expensive operations like search reindexing should be offloaded to an asynchronous background job run once after the transaction completes.