All patterns
Foundational
Monolithic
One deployable unit for the whole application
All business logic, APIs, and UI live in a single codebase and deploy together. Simple to build and operate early on; can evolve into modular monolith before splitting services.
Startup scalelow complexity
Architecture diagram
High-level component relationships
Key components
Presentation layer
HTTP routes, controllers, or server-rendered views
Domain / business logic
Rules, workflows, and use cases in one process
Data access
ORM or queries against a shared database schema
Shared database
Single source of truth for all modules
Data flow
- Client sends request to one API gateway or web server
- In-process calls handle validation, business rules, and persistence
- Response returns from the same process — no network hops between modules
Pros
- Fastest path from idea to production
- Simple debugging, tracing, and local development
- ACID transactions across features are straightforward
- No distributed-system failure modes (network partitions, sagas)
Cons
- Deploy risk: one bug can affect the entire system
- Scaling requires scaling everything together
- Large teams can collide on the same codebase
- Technology choices are locked for the whole app
When to use
- MVP, early-stage products, or internal tools
- Small team with unclear domain boundaries
- Tight deadlines where operational simplicity matters most
When to avoid
- Independent scaling of read-heavy vs write-heavy paths is critical
- Multiple teams need fully independent release cycles
- Regulatory isolation requires hard boundaries between domains
Real-world examples
- Early Shopify
- Many Rails/Django startups
- Internal admin portals
Related technologies
PostgreSQLDjangoRailsSpring BootLaravel