Monolith

The enterprise application architecture that's simultaneously declared dead and quietly powering most of the world's critical business systems.

Despite a decade of industry enthusiasm for microservices, an estimated 60-70% of enterprise workloads still run as monoliths — single, unified applications that handle all business functions in one codebase. The global market for modernising legacy monolithic applications exceeded $25 billion in 2025. For C-suite leaders, the monolith is not a dirty word: it is the pragmatic starting point for most software projects and remains the optimal architecture for many business scenarios. Understanding when to maintain, modernise, or decompose a monolith is a critical technology leadership skill.

What It Is

A monolithic application is one where all the business logic, user interface code, database access, and supporting functions are built, deployed, and run as a single unit. Think of it as an all-in-one appliance: a combination printer, scanner, copier, and fax machine. It works well when you need all functions together, but if the scanner breaks, the entire machine goes in for repair. The monolith is the original software architecture — virtually every application was built this way until the microservices movement gained traction in the mid-2010s.

In a monolithic architecture, the user authentication module, order processing engine, reporting system, and customer management functions all share the same codebase, the same database, and the same deployment pipeline. When you update one function, you redeploy the entire application. When one function needs to scale — say, order processing during a flash sale — you scale the entire application, even though the reporting module does not need additional capacity. This is both the simplicity and the limitation of the monolith: it is easy to develop and deploy initially, but becomes increasingly difficult to manage as the codebase grows.

It is important to distinguish between a "big ball of mud" — an unstructured, poorly written monolith — and a well-architected monolith with clean internal module boundaries. Companies like Shopify and Basecamp (now 37signals) have demonstrated that a well-structured monolith can serve millions of users effectively. Shopify's original application was a monolith that powered the entire e-commerce platform, and the company only began extracting specific services when clear performance or scaling bottlenecks emerged.

Why It Matters for Business

The monolith vs. microservices debate often obscures a more important business question: what architecture delivers the best return on investment for your specific situation? For early-stage products, internal tools, and applications with stable demand patterns, a monolith is typically 2-5x faster to develop and 50-70% cheaper to operate than an equivalent microservices architecture. Stack Overflow, one of the most visited websites in the world with over 100 million monthly users, runs on a monolithic architecture served by just 11 physical servers. The simplicity of this setup allows a small team to maintain it whilst delivering exceptional performance and reliability.

The business risk of monoliths emerges at scale. As the codebase grows and more teams work on it, coordination overhead increases. Every deployment carries risk because any change can potentially affect any part of the system. A bug in the reporting module can crash the checkout process. Scaling a single high-demand component requires scaling the entire application, wasting infrastructure resources. These challenges are what drive organisations toward microservices — but the transition is expensive, time-consuming, and risky if done prematurely or without clear business justification.

The key insight for executives is that the monolith is not inherently bad — it is a tool with specific strengths and limitations. The most successful organisations treat architecture as an evolutionary process: they start with a monolith, identify components that genuinely benefit from independent scaling or deployment, and extract those selectively. This "extract what hurts" approach avoids the expensive over-engineering that plagues many microservices initiatives. Research by ThoughtWorks suggests that organisations that decompose monoliths incrementally — rather than in big-bang rewrites — succeed 3x more often in their modernisation efforts.

Enterprise Use Cases

Basecamp (now 37signals) famously operates its project management platform — serving millions of users — as a single monolithic Ruby on Rails application. Founder David Heinemeier Hansson has been a vocal advocate for the monolith approach, arguing that the simplicity of a single codebase allows a team of just 50 engineers to maintain and enhance a product that generates over $100 million in annual revenue. The company has been able to ship features consistently for over 20 years without the operational complexity of microservices.

Shopify's original platform was a Ruby on Rails monolith that powered the entire e-commerce experience from storefront rendering to payment processing to inventory management. At its peak, this monolith served over 1 million merchants and handled billions of dollars in transactions. Shopify only began extracting services — beginning with the payment processing component (which became Shopify Payments) and later the shopping cart and search services — when specific scaling bottlenecks emerged that could not be addressed within the monolith. Even in 2026, the core of Shopify's platform remains a well-structured monolith with selective microservice extractions for the highest-scale components.

Many of the world's most critical systems remain monoliths. SWIFT, the global financial messaging network that processes over $5 trillion in transactions daily, runs on core systems that are decades-old monoliths. Airlines' reservation systems — including those used by American Airlines and Lufthansa — trace their roots to monolithic mainframe applications from the 1960s and 1970s, carefully maintained and incrementally modernised over decades. These systems demonstrate that a well-maintained monolith can provide decades of reliable service.

Vendor Landscape

The vendor landscape for monolith-related tooling overlaps significantly with general application development. Frameworks commonly used for monolithic applications include Ruby on Rails, Django (Python), Spring Boot (Java), ASP.NET (C#), and Laravel (PHP). All are open-source with no licence fees. For organisations modernising existing monoliths, the "strangler fig" pattern — progressively replacing monolith components with new services — is supported by tools such as AWS Application Migration Service, Azure App Service, and open-source API gateways. Legacy modernisation consultancies including Accenture, Deloitte, and ThoughtWorks provide strategic guidance on monolith evolution, with engagement costs typically ranging from $200,000 for assessment and strategy to $5-20 million for full modernisation programmes. Low-code platforms — OutSystems, Mendix, and Microsoft Power Apps — offer an alternative path, enabling organisations to build monolithic applications rapidly for internal and customer-facing use cases without deep engineering teams.

Strategic Considerations

Resist the urge to rewrite your monolith unless there is a clear, quantifiable business case. Big-bang rewrites have a failure rate estimated at 60-70%, often taking 2-3x longer and costing 3-5x more than projected. Instead, adopt the strangler fig approach: identify the components of your monolith that cause the most pain (slow to change, frequent failures, scaling bottlenecks), extract those first, and leave the rest. When starting a new product, default to a well-structured monolith with clean internal boundaries — you can always extract services later, but you cannot easily undo premature decomposition. If your monolith is stable, well-understood, and meeting business needs, there is no shame in maintaining it. The best architecture is the one that serves your business most effectively, not the one that generates the most excitement at technology conferences.