These are the very arguments I get all the time.

1) I want to invalidate caches, I want to know that these systems work. I want to know that my software properly handles this situation.

2) if I have lazy clients. I want to know. And I want to motivate them on updating sooner or figure out how to force update them. I don’t want to not update because some people are slow. I want the norm to be it is updating, so when there is a reason to update, like a zero day, I can have some notion that the updates will work and the lazy clients will not be an issue.

I am not talking about fake or dry runs that go through some portion of motions, I want every aspect of the process to be real.

Performance means nothing if your stuff is down. And any perceived performance gained by not doing proper hygiene is just tweaking the numbers to look better than they really are.

It's very hard to do a representative dry run when the most likely potential points of failure are highly load-dependent.

You can try and predict everything that'll happen in production, but if you have nothing to extrapolate from, e.g. because this is your very first large live event, the chances of getting that right are almost zero.

And you can't easily import that knowledge either, because your system might have very different points of failure than the ones external experts might be used to.

I like all of these considerations, although I also imagine for every context there is some frequency at which it is worthwhile to invalidate the caches to ensure that all parts of the system are still functioning as expected (including the rebuilding of the caches).

What I’m seeing in large organizations is tracking dependencies within a team’s scope is better than dependencies between teams, because so many developers between teams are punting on tracking dependencies upon other teams’ artifacts if there isn’t a formal system already in place at the organization to establish contracts between teams along these dependency routes, that automatically handle the state and notifications when changes announcing the intended state change are put through the system. Usually some haphazard dependency representation is embedded into some software and developers call it a day, expecting the software to auto-magically solve a social-technical logistical problem instead of realizing state transitions of the dependencies are not represented and the software could never deliver what they assume.