Modular Monolith Case Studies: Shopify, GitHub & StackOverflow

Answer-first: The Modular Monolith case study matrix evaluates how industry leaders—including Shopify, GitHub, Segment, Etsy, and Stack Overflow—scale core systems using monolithic architecture. These real-world production benchmarks prove that co-locating domains reduces infrastructure expenses, deployment friction, and network latency while maintaining high development velocity.

Pillar Architecture Guide: This article is part of the Architecting 21-Service E-commerce with Golang & DDD series and Composable E-Commerce Migration guide. Please refer to the original article for a detailed technical overview of the architecture.

Prerequisite: Before reading this part, please review Part 7: Extraction Pattern.

Part 8: Case Study Matrix – The Monuments of the Modular Monolith

What You’ll Learn That AI Won’t Tell You:

• GitHub & Etsy Scale Tactics: How GitHub routes 100M+ repositories via Spokes RPC and Etsy deploys PHP 50x daily.
• Empirical Performance Metrics: Quantitative breakdown of p99 latency, cost savings %, and deployment velocity across 7 production platforms.
• Real-World Failure Modes: Analysis of Distributed Monoliths, DB lock contention, and premature boundary extraction.
• 5-Level Modularity Maturity Scorecard: Operational scorecard to determine whether your application is ready for microservices extraction.

Numerous debates about architectural design often lead to dead ends due to a lack of quantitative, real-world numbers. There is a common misconception that: “Only Microservices can withstand web-scale loads.”

This section examines the Case Study Matrix – a compilation of the greatest Modular Monolith systems, ranging from massive e-commerce platforms to billion-user chat applications.

The diagram below summarizes key monolithic architecture benchmarks across enterprise engineering organizations.

graph TD
    subgraph Modular Monolith Titans
        SO["Stack Overflow: 9 Web Servers for 1.3B Views"]
        SH["Shopify: 284M Requests/Min on Rails Monolith"]
        GH["GitHub: 100M+ Repos via Ruby Monolith + Go RPC"]
        ET["Etsy: 90M+ Buyers on PHP/V8 Monolith"]
        NO["Notion: 200B Data Blocks via Monolithic Sharding"]
        WA["WhatsApp: 2M Concurrent TCP Hops on 1 Node"]
        37["37signals: $1.5M Cloud Savings via Bare-Metal Monolith"]
    end

1. Enterprise Production Case Studies & Empirical Metrics

Answer-first: Real-world case studies prove modular monolith scalability: Stack Overflow serves 1.3B monthly views on 9 web servers, Shopify handles 284M req/min on Rails, GitHub manages 100M+ repos via Spokes RPC, Etsy handles 90M+ buyers on PHP, and 37signals saved $1.5M/year via cloud exit.

Stack Overflow: 1.3 Billion Monthly Page Views on 9 Web Servers

Stack Overflow is the ultimate demonstration of the efficiency of vertical hardware scaling paired with monolithic architecture.

• The Infrastructure Spec: Stack Overflow operates its entire primary web traffic on only 9 web servers running IIS and .NET C# code, paired with 2 primary Microsoft SQL Server instances (one active, one failover). Each web server features 64 CPU cores and 256 GB of RAM, running at CPU utilization rates consistently under 15%.
• How They Scale: Instead of distributing microservices across Kubernetes clusters, Stack Overflow caches almost everything in local web server RAM using custom L1/L2 data structures and Redis. SQL queries use pre-compiled execution plans, and static assets are served directly via edge CDNs.

Shopify: 284 Million Requests/Minute with Ruby on Rails

When discussing the Monolith, one cannot ignore Shopify.

• The Numbers: Handled over 173 billion requests during Black Friday/Cyber Monday, peaking at 284 million requests/minute.
• Architecture: The entire core of Shopify remains a massive Ruby on Rails Modular Monolith application (over 3 million lines of code).
• How they Scale: Protected code boundaries using Packwerk to enforce strict modular encapsulation. Invested heavily in YJIT (Ruby JIT compiler) to accelerate CPU performance by 15%. The MySQL database tier is horizontally sharded by merchant store ID to distribute write contention.

GitHub: 100M+ Repositories on a Monolithic Ruby/Go Platform

GitHub demonstrates how a major developer platform handles massive scale through a central monolith backed by RPC storage satellites.

• The Numbers: Serves over 100 million active repositories and billions of daily API requests.
• Architecture: Core GitHub platform operates as a Ruby on Rails Monolith backed by custom RPC micro-satellites (Spokes/Solum) written in Go.
• How They Scale: GitHub keeps user authentication, issue tracking, pull requests, and web UI inside the core Ruby monolith. Heavy Git storage operations are routed over custom RPC interfaces to Spokes, a specialized file-system router that manages Git repository routing across bare-metal storage clusters.

Etsy: 90M+ Active Buyers on a PHP/V8 Monolithic Core

Etsy proves that developer velocity and high-volume e-commerce can thrive on a monolithic PHP engine.

• The Numbers: Manages over 90 million active buyers and $13B+ Gross Merchandise Sales.
• Architecture: Operates a unified PHP Monolith engine deploying via Deployinator.
• How They Scale: Etsy relies on vertical server scaling, aggressive local caching, and custom C/C++ PHP extensions. Rather than adopting microservices, Etsy enforces module boundaries at the directory structure level and utilizes real-time monitoring to deploy the monolith binary to production up to 50 times per day.

Notion: Sharding Postgres (200 Billion Blocks) on a Node.js Monolith

Notion is clear proof that “The bottleneck is always in the Database tier, not the Application Logic layer.”

• The Numbers: Stores over 200 billion data blocks, representing tens of Terabytes of unstructured document data.
• Architecture: Monolithic Node.js / TypeScript backend service.
• How they Scale: When a single PostgreSQL master instance hit CPU and I/O saturation, Notion avoided splitting backend services into microservices. Instead, they focused on Application-Level Database Sharding, partitioning Postgres across 96 physical database instances using a deterministic hashing formula: $$\text{Shard ID} = \text{workspace_id} \pmod{480}$$ The monolithic Node.js application remained completely intact, managing cross-shard routing through internal database drivers.

WhatsApp: 2 Million Concurrent Connections on ONE Physical Server

In 2014, WhatsApp served over 450 million active users with an engineering staff of just 50 engineers.

• The Numbers: Maintained 2 million concurrent TCP connections per physical server node running Erlang BEAM.
• Architecture: Monolithic Erlang / FreeBSD server architecture.
• How they Scale: By tuning FreeBSD kernel socket buffers (sysctl network parameters) and customizing the Erlang BEAM virtual machine emulator, WhatsApp eliminated thread context-switching overhead, holding millions of active WebSocket/TCP connections inside a single monolithic process.

37signals (HEY/Basecamp): Saving $1.5 Million USD via Bare-Metal Monoliths

• The Cloud Exit Event: 37signals executed a high-profile “Cloud Exit,” migrating their monolithic Rails applications (Basecamp, HEY) off AWS EC2/EKS and back onto dedicated bare-metal servers in co-located datacenters.
• How They Executed: Utilized Kamal (open-source deployment tool) to push Docker containers directly to physical servers. By dropping AWS managed service overhead, Kubernetes control planes, and cross-AZ data egress fees, 37signals reduced infrastructure costs by $1.5 million USD per year while improving CPU throughput.

Segment: Merging 140 Destination Microservices Back into 1 Monolith

Segment initially broke their event processing pipeline into 140 separate microservices (one per integration destination). As destination services multiplied, infrastructure complexity exploded: worker queues stalled, AWS billing costs soared, and managing 140 deployment pipelines consumed 70% of engineering bandwidth.

• The Remedy: Segment consolidated all 140 microservice repositories back into a single Go Monolithic Worker pool. All destination integrations execute inside a single binary process. Result: Infrastructure expenses decreased by $250,000 in Year 1, and developer deployment velocity increased 5x.

Production Monolith Empirical Metrics Matrix

The empirical metrics matrix below compares key operational indicators—p99 latency, infrastructure cost savings, deployment velocity, and team autonomy score—across major modular monolith implementations.

For concurrency patterns, compare this with our High-Concurrency Systems C10M Guide.

2. Technical Performance: In-Memory Tagged Cache Implementation in Go

Answer-first: A thread-safe Go tagged cache maps keys to domain tags in local RAM, invalidating entire groups of cached objects in sub-microsecond execution time without issuing external network RPC calls.

The Go code implementation below demonstrates a thread-safe in-memory tagged cache, enabling microsecond domain cache invalidations without network overhead.

package main

import (
	"fmt"
	"sync"
)

type TaggedCache struct {
	mu    sync.RWMutex
	items map[string]interface{}
	tags  map[string]map[string]struct{}
}

func NewTaggedCache() *TaggedCache {
	return &TaggedCache{
		items: make(map[string]interface{}),
		tags:  make(map[string]map[string]struct{}),
	}
}

func (c *TaggedCache) Set(key string, val interface{}, tags []string) {
	c.mu.Lock()
	defer c.mu.Unlock()

	c.items[key] = val
	for _, tag := range tags {
		if c.tags[tag] == nil {
			c.tags[tag] = make(map[string]struct{})
		}
		c.tags[tag][key] = struct{}{}
	}
}

func (c *TaggedCache) Get(key string) (interface{}, bool) {
	c.mu.RLock()
	defer c.mu.RUnlock()
	val, exists := c.items[key]
	return val, exists
}

func (c *TaggedCache) InvalidateTag(tag string) {
	c.mu.Lock()
	defer c.mu.Unlock()

	if keys, found := c.tags[tag]; found {
		for key := range keys {
			delete(c.items, key)
		}
		delete(c.tags, tag)
	}
}

func main() {
	cache := NewTaggedCache()
	cache.Set("user_123_profile", "John Doe", []string{"users", "user_123"})
	cache.Set("user_123_settings", "Dark Mode", []string{"users", "user_123"})

	cache.InvalidateTag("user_123") // Invalidates both keys in RAM

	_, ok := cache.Get("user_123_profile")
	fmt.Printf("Profile exists after tag invalidation: %v\n", ok)
}

3. Monolith Architectural Breakdown, Failure Modes & Maturity Scorecard

Answer-first: Evaluating monolith health requires understanding real-world failure anti-patterns (such as distributed monoliths and database lock contention) alongside quantitative maturity scorecards ranging from Level 1 Spaghetti to Level 5 Dynamically Extracted services.

Architectural Breakdown Matrix of Monolith Success Stories

The architectural breakdown matrix below summarizes how tech leaders leverage vertical hardware scaling, Packwerk static boundaries, application-level sharding, and monolithic worker pools to achieve web-scale throughput.

Real-World Failure Modes & Anti-Patterns

When transitioning to or maintaining a modular monolith, engineering teams must watch for critical failure modes:

1. The Distributed Monolith Trap: Extracting microservices prematurely while retaining synchronous REST/gRPC calls and shared database dependencies, resulting in worst-of-both-worlds network latency and deployment locking.
2. Shared Database Lock Contention: Allowing multiple internal modules or extracted services to query the same SQL tables directly, creating hidden schema coupling and deadlock vulnerabilities.
3. Premature Boundary Extraction: Splitting a domain into a satellite microservice before business domain boundaries have stabilized, forcing frequent cross-service refactoring and breaking API contracts.
4. Boundary Leakage: Importing internal concrete structures across module boundaries instead of communicating strictly via public interfaces or domain event buses.

5-Level Modularity Maturity Scorecard

The maturity scorecard framework below provides a quantitative metric for evaluating whether a codebase is prepared for microservice extraction or should remain an in-process modular monolith.

Frequently Asked Questions (FAQ)

Answer-first: This FAQ addresses key insights from real-world monolith benchmarks, covering Stack Overflow’s 9-server setup, Notion’s Postgres sharding strategy, Segment’s $250K cost savings, and tagged cache invalidation.

Navigation & Next Steps

Answer-first: Return to the Modular Monolith Architecture Series index or explore related series on Go system design and high-concurrency systems.

• Previous Part: Part 7: Extraction Pattern
• Series Index: Return to Modular Monolith Architecture Series Index
• Related Series: Explore Modular Monolith Architecture and High Concurrency Systems

Need an end-to-end architectural evaluation for your software stack? Get in touch or hire our technical consulting team for system design audits.