Stack Overflow Architecture

is not what you think it is.

In this issue, we talk about:

• Stack Overflow Architecture

• Shopify Architecture

• Levels.fyi Architecture

So, let’s start.

---

In the recent interview with Scott Hanselman, Roberta Arcoverde, Head of Engineering at Stack Overflow, revealed the story about the architecture of Stack Overflow. They handle more than 6000 requests per second, 2 billion page views per month, and they manage to render a page in about 12 milliseconds. We imagine they use a microservice solution running in the Cloud with Kubernetes.

But the story is a bit different. Their solution is 15 years old, a giant monolithic application running on-premise. It is a single application on IIS which runs 200 sites. This single app is running on nine web servers and a single SQL Server (with the addition of one hot standby).

They also use two levels of cache, one on SQL Server with large RAM (1.5TB), where they have 30% of DB access in RAM, and two Redis servers (master and replica). Besides this, they have three tag engine servers and 3 Elastic search servers, which are used for 34 million daily searches.

All this is handled by a team of 50 engineers, who manage to deploy to production in 4 minutes several times daily.

Their full tech stack is:

• C# + ASP.NET MVC

• Dapper ORM

• StackExchange Redis

• MiniProfiler

• Jil JSON Deseliazier

• Exceptional logger for SQL

• Sigil, a .Net CIL generation helper (for when C# isn’t fast enough)

• NetGain, a high-performance web socket server

• Opserver, monitoring dashboard polling most systems and feeding from Orion, Bosun, or WMI.

• Bosun, backend monitoring system, written in Go

Stack Overflow Architecture

If you want to learn more about their architecture, there is a series of articles from Nick Craver, one of the engineers from 2016. This is a bit outdated, but the architecture should be the same.

---

Shopify Architecture

During Black Friday last year, Shopify managed to serve 1.27 million requests per second. And you probably think that such a large amount of requests can be only handled by some fancy microservices. The truth is a bit different.

Shopify uses a modular monolith approach, keeping all its code in one codebase but modularized. Monolithic architecture is the easiest one to understand and implement. Since monolithic design is simple to build and enables teams to move swiftly in the beginning, it can carry an application far to get their product in front of customers earlier.

There are many benefits to centralizing your application deployment and codebase maintenance. All functionality will be accessible in one folder; you only need to manage one repository. Additionally, it implies that one test and deployment pipeline must be maintained, which might save a lot of work. The ability to call into different components rather than relying on web service APIs is among the most alluring advantaged of monolithic architecture over several other services.

Shopify implemented one version of the modular monolith with componentization in Ruby on Rails. They organize a code base around real-world concepts (like orders, shipping, inventory, and billing), making it easier to label code and people who understand it. Each component is a mini Rails app (a module) that isolates business domains from one another. Each component claims sole ownership of the associated data and defines a straightforward, dedicated interface with domain boundaries communicated through a public API.

Check references [1], [2].

Levels.fyi Architecture

This is a story of Levels.fyi, who managed to scale to millions of users with only Google Sheets as a backend. They are a career site for professionals, which has 1-2 million unique user visits every month.

They wanted to move fast and focus on important things when they started, so they needed a backend. They used a no-code approach with Google Forms + Google Sheets (with the addition of AWS Lambda and API Gateway). This also enabled them to save developer time, reduce complexity and save infrastructure costs.

Yet, their architecture worked well for 24 months, but the user base has grown, and they started to have issues, so they decided to move to a new backend with a database and API Server. They duplicated the write query to their new database and read from the new API as that was ready, so Google Sheets was retired.

Check the full story.

Levels.fyi architecture

To learn more about modular monoliths, check here:

Why should you build a (modular) monolith first?

---

🎁 If you are interested in sponsoring one of the following issues and supporting my work while enabling this newsletter to be accessible to readers, check out the Sponsorship Tech World With Milan Newsletter opportunity Tech World With Milan Newsletter.

---