[ctvo]

The folks over at SO picked a stack (C#, SQL Server, IIS), and optimized the heck out of it to keep this "simplicity". Much of SO is custom built from the ground up to push performance and stay within the purity of the canonical .net stack.

It isn't clear to me this is a model that would work elsewhere, or should be held up as something to be replicated.

Did they save time? Did they save money? Did this help make SO a wildly successful company? Did it allow them to deliver features to customers faster?

[Yeroc]

It's worth reminding people what is actually possible with a relatively simple architecture. There's a vast number of websites and services with a very small fraction of the traffic of Stack Overflow with a much more complicated architecture simply because everyone thinks you need Kubernetes etc to scale out.

[inhumantsar]

That's the point though. If you want to focus your engineering time on optimization and code quality, then of course you can scale to SO's size with 9 servers and a simple architecture.

If you're still growing and more interested in delivering tons of features quickly, and/or don't have the ability to attract world leading talent, then a more complicated architecture with clear boundaries is often a better call than delivering relatively few features with obsessive rigor in a monolithic codebase.

[Yeroc]

You'll only need the expertise to perform in-depth optimization if you're scaling to the level of Stack Overflow though. For the vast majority of sites it won't be a concern. The simpler architecture should be the default because local method calls are easily 2 orders of magnitude faster than a network roundtrip (yes I know that's not the whole story). I'm not sure how or why creating clear boundaries without the RPC crutch suddenly became insurmountable.