Best practices can slow your application down
There is a big difference between developers who know their hardware stack, and those who don&#x27;t. Performance efficiency is often an order of magnitude out of whack for companies that prefer a horizontal-first scaling approach (i.e. lots of containers in the cloud, k8s, etc.). As an extreme example, consider Plaid, which at one point had 4000 Node containers [1] running in parallel to handle just as many requests per second. My guess is they could&#x27;ve easily done with a few beefy baremetal machines, if they knew their hardware well, and architected it sensibly from the beginning.<p>Money wasn&#x27;t a problem for them because they were able to just throw $350k a year at AWS to make it work (and millions more at their dev team). But money isn&#x27;t the only thing. This sort of approach sacrifices real-time latency (which is felt by the user), reliability (Plaid is notorious for having a ~20% fail rate for requests), flexibility (Plaid is notoriously slow at fixing bugs), developer costs (a dedicated DevOps team), agility (very slow deployment times), not to mention the priceless value of simplicity, a system that can fit in the mind of a single experienced developer, so they can write and test performant code on their own machine.<p>But hey, Plaid is now a unicorn, so who cares about efficiency.<p>[1] <a href="https:&#x2F;&#x2F;plaid.com&#x2F;blog&#x2F;how-we-parallelized-our-node-service-by-30x&#x2F;" rel="nofollow">https:&#x2F;&#x2F;plaid.com&#x2F;blog&#x2F;how-we-parallelized-our-node-service-...</a>