The naive approach is pattern matching. “This sounds like Uber, so I’ll draw the Uber architecture.” Pattern matching produces architectures that look correct but collapse under questioning because the designer cannot explain why each component exists.
Consider a caching layer added because “caching makes things fast.” When asked whether it uses write-through or write-behind, what the eviction policy is, how it behaves when the cache node fails, or whether consistency is required — the pattern-matched answer cannot respond. At scale, unjustified decisions become production incidents.
The deeper failure: pattern matching treats scale as an afterthought. Real systems grow in non-uniform ways. Read load and write load grow at different rates. User distribution shifts geographically. One feature drives ten times more traffic than expected. An architecture that was not designed for evolution requires a rewrite to accommodate growth.