This is going to be a bit of an oversimplification but when you build things that are easy to delete, then you’re not going to cause unintentional bugs when you delete them. It’s once you over complicate things that everything becomes an interconnected mess where developers don’t know what sort of impact changes will have. There are a lot of ways to fuck this up of course. Maybe you’re following some silly “best practice” principle, maybe you’re doing “micro-services” in a manner where you don’t actually know who/what consumes which service. But then you’ve not build things that are easy to delete.

I think external consumption as you frame it is a good example of this. It’s fair to give consumers a reasonable warning about the depreciation of a service, but if you can’t actually shut it off when you want to, then you’ve not designed your system to let things be easily deleted.

Which is fair. If that works for you, then so things that way. I suspect it may not work too well if you’re relying on tests and observations to tell you if things are breaking. Not that I have anything against tests, but it’s not exactly a great safe-guard if you have to let them tell you if you broke something in a long complicated chain. Not least because you’re extremely unlikely to have test-coverage which will actually protect you.