I'm tempted to post links to some of the posts I've seen on this site.
If you want an especially cut and dried example, there are ways to do sharding such that only a low number of shards can be used. Not as a matter of some kind of consensus or consistency algorithm or something understandable like that, but by writing a sharding function that can only make 64 possible permutations.
Or try this, a "copy over centralize" approach to scaling, where we just take our application's architecture and copy it wholesale any time we need more capacity. Web frontend taking too much load? New pod! Monitoring sidecar having issues due to some idiotic way of handling UDP sockets from syslog? New pod!
This way, if any one part of the application is under load, all the other parts get copied whether they needed to or not! Let's do this with 50 sidecars now. Because the AWS bill is somebody else's problem.
Or here's a good one: 20 different ****ing microservices that all handle identities differently, depending on local accounts. If you rotate the credentials on one of the damn things, you guess what happens next.
Or what about designing an analytics engine that has 2 different bespoke webservers hard coded into it and handles TLS using a private key committed to the ****ing source code?
We're a place where coders share, stay up-to-date and grow their careers.
We strive for transparency and don't collect excess data.