5 ms·

So what is their stack, or where can I find more about it? A totally custom webserver? Someone commented to this effect the yesterday [1], but I couldn't find m

So what is their stack, or where can I find more about it? A totally custom webserver? Someone commented to this effect the yesterday [1], but I couldn't find much in the way of a good writeup, except this answer from 2009 [2]. 1 https://news.ycombinator.com/item?id=32321726 https://news.ycombinator.com/item?id=32321726 2 https://stackoverflow.com/questions/676326/how-does-stackoverflow-optimise-the-performance-for-the-display-of-the-questions/1464847#1464847 https://stackoverflow.com/questions/676326/how-does-stackove...

brightball 4y ago
I remember hearing that they are a .NET stack with C# and SQL Server. The only reason I know that is because I was working at a company and discussing the issues the company was running into scaling SQL Server and Stack Overflow was used as a counter example of SQL Server scalability. It lead into a long discussion of caching on high read workloads. I'll never touch SQL Server again if I can help it.
bakje 4y ago
Not specifically stackoverflow, but here is an answer on stackexchange [1] listing many of the parts that make up their stack. I'm assuming stackoverflow runs as a part of all this, and not separately. 1 https://meta.stackexchange.com/a/10370 https://meta.stackexchange.com/a/10370
kadonoishi 4y ago
builtwith.com gives a lot of information, although the results page comes back with a "Misleading Technology Profile Warning".
dixie_land 4y ago
https://nickcraver.com/blog/2016/02/03/stack-overflow-a-technical-deconstruction/ https://nickcraver.com/blog/2016/02/03/stack-overflow-a-tech...
- jollyllama 4y ago
  Excellent, thank you. "Stack Overflow: How We Do App Caching - 2019 Edition" is particularly informative.
  - dixie_land 4y ago
    I also just discovered that “new” entry while posting this link and it was indeed quite a good read.
artimaeis 4y ago
Scott Hanselman had an interview with the Stack Overflow Director of Engineering just a few weeks ago. They cover some high-level details there [0]. As I understand it's an .NET Core monolith with a very-large (~1.5 TB RAM) SQL Server backend. [0] https://hanselminutes.com/847/engineering-stack-overflow-with-roberta-arcoverde https://hanselminutes.com/847/engineering-stack-overflow-wit...
- ec109685 4y ago
  One thing about using SQL databases live in production for everything is that the architecture is amazingly simple, almost always performant, but if something goes wrong, it goes catastrophically wrong. Amazon for new critical applications prefers NoSQL solutions for this reason since performance is flatter and not dependent on vagaries of the query optimizer.
  - alexjplant 4y ago
    From what I've gleaned through speaking to current and former Amazon employees you basically have to use DynamoDB for all new services. IMHO the logical progression for applications with typical relational models is starting with an RDBMS in combination with an ORM, breaking out of the ORM when necessary for more complex/slower queries, ditching the ORM altogether when it starts to break, then evaluating sharding or moving domains into a NoSQL solution piecemeal. A well-architected monolith or series of microservices suits this paradigm which allows you to realize the productivity benefits of SQL and only worry about the deduplication, indexing, and consistency issues that come with NoSQL when it becomes actually necessary. Then again if I were Amazon I'd probably plan for scale up front and be jaded by their experience with Oracle too.
pid_0 4y ago

brightball 4y ago

I remember hearing that they are a .NET stack with C# and SQL Server. The only reason I know that is because I was working at a company and discussing the issues the company was running into scaling SQL Server and Stack Overflow was used as a counter example of SQL Server scalability. It lead into a long discussion of caching on high read workloads. I'll never touch SQL Server again if I can help it.

bakje 4y ago

Not specifically stackoverflow, but here is an answer on stackexchange [1] listing many of the parts that make up their stack. I'm assuming stackoverflow runs as a part of all this, and not separately. 1 https://meta.stackexchange.com/a/10370 https://meta.stackexchange.com/a/10370

kadonoishi 4y ago

builtwith.com gives a lot of information, although the results page comes back with a "Misleading Technology Profile Warning".

dixie_land 4y ago

https://nickcraver.com/blog/2016/02/03/stack-overflow-a-technical-deconstruction/ https://nickcraver.com/blog/2016/02/03/stack-overflow-a-tech...

jollyllama 4y ago
Excellent, thank you. "Stack Overflow: How We Do App Caching - 2019 Edition" is particularly informative.
- dixie_land 4y ago
  I also just discovered that “new” entry while posting this link and it was indeed quite a good read.

artimaeis 4y ago

Scott Hanselman had an interview with the Stack Overflow Director of Engineering just a few weeks ago. They cover some high-level details there [0]. As I understand it's an .NET Core monolith with a very-large (~1.5 TB RAM) SQL Server backend. [0] https://hanselminutes.com/847/engineering-stack-overflow-with-roberta-arcoverde https://hanselminutes.com/847/engineering-stack-overflow-wit...

ec109685 4y ago
One thing about using SQL databases live in production for everything is that the architecture is amazingly simple, almost always performant, but if something goes wrong, it goes catastrophically wrong. Amazon for new critical applications prefers NoSQL solutions for this reason since performance is flatter and not dependent on vagaries of the query optimizer.
- alexjplant 4y ago
  From what I've gleaned through speaking to current and former Amazon employees you basically have to use DynamoDB for all new services. IMHO the logical progression for applications with typical relational models is starting with an RDBMS in combination with an ORM, breaking out of the ORM when necessary for more complex/slower queries, ditching the ORM altogether when it starts to break, then evaluating sharding or moving domains into a NoSQL solution piecemeal. A well-architected monolith or series of microservices suits this paradigm which allows you to realize the productivity benefits of SQL and only worry about the deduplication, indexing, and consistency issues that come with NoSQL when it becomes actually necessary. Then again if I were Amazon I'd probably plan for scale up front and be jaded by their experience with Oracle too.

pid_0 4y ago