UI Layer
Business Logic
Data Access
🗄️ Single DB
Characteristics
- Single deployment unit
- Shared codebase
- Simple to debug
Best For
- Early-stage products
- Small teams (2-8 devs)
- Simple domains
Trade-offs
✓ Simple, fast development, easy testing
✗ Scaling limitations, tech lock-in, risky deploys
Case Study: Basecamp
Basecamp has famously run as a monolithic Ruby on Rails application for 20+ years, serving millions of users. Their team argues that monoliths are ideal when a small team owns the entire product and values development speed over independent scaling.
User Svc
Order Svc
Payment Svc
Enterprise Service Bus
🗄️ Shared DB
Characteristics
- Service-based decomposition
- ESB communication
- Shared databases possible
Best For
- Enterprise systems
- Legacy modernization
- Large organizations
Trade-offs
✓ Modular, reusable services
✗ ESB complexity, shared DB coupling
Case Study: Enterprise Banking
Many large banks adopted SOA in the 2000s to modernize COBOL mainframes. Services for accounts, transactions, and compliance communicate via an ESB, allowing gradual migration while maintaining shared data consistency.
Characteristics
- Independent deployment
- Own databases per service
- Direct API communication
Best For
- Large teams, complex domains
- High-scale products
- Frequent independent releases
Trade-offs
✓ Independent scaling, tech flexibility, team autonomy
✗ Operational complexity, distributed debugging
Case Study: Netflix
Netflix migrated from a monolith to 700+ microservices to handle 200M+ subscribers globally. Each service (recommendations, streaming, billing) scales independently, enabling teams to deploy thousands of times per day.