There is a version of system design that is mostly performance theater. The diagram is large, every box has a fashionable technology name, and the architecture looks ready for a scale event that may never arrive. It can be intellectually satisfying, but it often leaves behind a system that is harder to reason about than the product requires.

Simple systems age better because they are easier to debug, easier to hand off, and easier to reshape. They give you fewer hiding places for ambiguity. When a service exists, it should have a real reason to exist. When an asynchronous step is introduced, it should solve a clear reliability or latency problem rather than simply making the design look modern.

I do not think good system design is anti-scale. I think it is pro-clarity. If you can make the invariants obvious, the ownership lines sharp, and the failure modes visible, the system has a much better chance of surviving real product growth than one that began as an architectural flex.