An application design where all code and features exist in a single codebase and deploy together.
A monolith is an application where all code lives in one codebase and deploys as a single unit. User management, payments, products, notifications - everything is together.
Think of it as a single building containing all departments versus separate buildings for each department (microservices).
One codebase, one database, one deployment. When you make changes, you deploy the entire application.
Simplicity: One codebase is easier to understand than dozens of services.
Easy Development: Run entire application locally. No complex service orchestration.
Simple Deployment: Deploy one thing, not coordinating multiple services.
No Network Overhead: Functions call each other directly, not over network.
Easier Testing: Test entire application without mocking services.
Great for Small Teams: Two developers can build and maintain a monolith easily.
Startups: Focus on building features, not infrastructure.
Small Teams: Managing microservices requires DevOps expertise.
No related topics found.
Clear Requirements: When you know what you are building and do not need independent scaling.
MVPs: Get to market fast without complex architecture.
Deployment Risk: Small change requires deploying everything. One bug can break the entire app.
Scaling: Cannot scale individual features. Must scale entire application.
Team Coordination: Large teams step on each other working in the same codebase.
Technology Lock-in: Entire app uses one language/framework. Cannot easily try new tech.
Shopify: Started as a monolith, still runs core features as monolith.
Etsy: Massive monolith with millions of users. Works fine with good practices.
Stack Overflow: Serves millions with a monolithic architecture.
Monolith: Simpler, easier to start, better for small teams, single deployment.
Microservices: Complex, better for large teams, independent scaling, complicated deployment.
Most companies start with monoliths and only split into microservices when growth demands it.
Best of both worlds - one codebase but organized into clear modules with boundaries. Easier to eventually split into services if needed.
Do Not Migrate Prematurely: Microservices add massive complexity. Migrate only when monolith causes actual problems.
Signs You Need Microservices: Different teams blocking each other, different scaling needs per feature, deployment takes too long.
"Monoliths Do Not Scale": False. Stack Overflow handles millions of users with a monolith.
"Microservices Are Always Better": False. They solve specific problems at the cost of complexity.
Monoliths are not legacy or outdated. They are the right architecture for most applications. Start with a monolith, keep it organized, and only migrate to microservices when you have clear reasons.
Many successful companies run monoliths and do not need microservices. Simple is often better.
