[contingencies]

Yeah, well, the logical reaction to that is to use minimal tools and unix and actually measure a supposed fault before attempting to work on it. First get it working, then get it working well. Usually the overriding business architectural considerations are achieving functionality within reasonable time and money, using existing HR, and without creating too much technical debt. Characteristics of specific components are generally not high on the list. This can be different in high availability systems, safety related systems, long-term stability fault-recovery-required systems and other special use cases. But for 99% of enterprise, HTTP @ 10Mbps + solid tools like the filesystem or sqlite3 will do it. Scaling becomes easy because you're on 100% known interfaces, so swapping any given component out is trivial, ie. future-proofing exists by default. Interfaces before implementation. For more wisdom tidbits try https://github.com/globalcitizen/taoup ;)