An observer that keeps a search index in step works perfectly until somebody writes a query builder update, at which point the rows change and nothing notices.
// fires saving, saved, updating, updated
$order->update(['status' => 'shipped']);
// fires nothing at all
Order::where('placed_at', '<', $cutoff)->update(['status' => 'archived']);
// nor does this
Order::where('status', 'cancelled')->delete();
// (unless the model uses SoftDeletes, where it is a mass update)This is documented and still catches people, because the two lines look equivalent and one of them bypasses the entire model layer. The mass version is often the right tool — hydrating fifty thousand models to change one column is absurd — so the answer is not to forbid it but to dispatch whatever the observer would have done, explicitly, next to the query. Anything that must never be missed belongs in a database trigger or a separate reconciliation job rather than in an observer.