This is something I preach often, even at FAANG. Often engineers feel comfortable and in-the-zone when solving for a process. One saying I often delivery is: Engineers often think their job is to build things. That's not the whole story, they build things for _people_. Nobody cares what your code looks like. Nobody cares what your architecture looks like. As engineers we should worry about creating forgettable experi…
Nobody cares what your code looks like. Nobody cares what your architecture looks like. … until it breaks. Nobody cared how the FAA NOTAM database was implemented either, until it went down. Part of being a professional engineer is thinking about these things, so your users won't have to.
I work with a product that sees a massive difference in use between the low end customers and the very highest end of customers. For the low end customers it doesn't matter what your architecture is at all. Could be a single small machine in a closet and it would suffice.
For our large customers it matters 100%. They are doing throughput 4 to 5 orders of magnitude higher than our most basic customers per day. They will push NAS and database performance to the limit. Every time we think "eh, no one is going to do that much" our customers come back and prove us wrong. Databases expand to billions and billions of rows. Query performance falls apart. Design decisions lead to lack of ability of horizontal scaling.
And when the systems get to this size the costs of operating the system add up quickly, and if your competitors choices lead to much lower operational costs, then expect to lose customers to them, especially as your product equalizes in capability, or at least meets their set of needs.