Introduction
Most software systems start out as Monolith — and rightly so. But as the system grows, the team expands, and requirements continuously change, the Monolith architecture gradually becomes a bottleneck. This lesson helps you understand the entire journey of software architecture evolution and why Microservices + Micro Frontend is the destination for complex systems.
1. Monolith — Reasonable starting point
1.1 What is Monolith Architecture?
Monolith is an architecture where the entire application is built, deployed and scaled as a single unit. All modules (User, Product, Order...) run in the same process, share the same database, and deploy together.
1.2 Advantages of Monolith
| Advantages | Description |
|---|---|
| Simple | Easy to develop, debug, and initially test |
| Easy to deploy | Just deploy 1 artifact |
| Performance | Call the function internally (in-process) instead of over the network |
| ACID Transactions | Easily perform transactions across modules |
| Easy to refactor | Good IDE support, easy searching and renaming |
1.3 When does Monolith become a problem?
As the system grows, Monolith encounters bottlenecks:
About Development:
- The codebase is too large, new developers need a lot of time to understand
- Build time increased to tens of minutes
- Merge conflicts continuously between teams
- A small bug can crash the entire system
About Deployment:
- Deploy the entire application for 1 small change
- Release cycle lasts (weeks/months)
- Complicated rollback, total impact
About Scaling:
- Must scale completely when only one module needs more resources
- Cannot use different technology for each part
Rule of thumb: If you have less than 5 developers and the system is not too complicated, Monolith is still the best choice.
2. Journey of architectural evolution
2.1 Monolith → SOA → Microservices
Timeline:
2000s 2010s 2015+ 2020+
┌──────┐ ┌──────────┐ ┌──────────────┐ ┌───────────────────┐
│Monolith│ → │ SOA │ → │ Microservices│ → │ Microservices + │
│ │ │Services │ │ │ │ Micro Frontend │
└──────┘ └──────────┘ └──────────────┘ └───────────────────┘
2.2 SOA (Service-Oriented Architecture)
SOA is the first step to separate Monolith into services. However, SOA has some limitations:
- Use centralized ESB (Enterprise Service Bus) → single point of failure
- Services are often not truly independent (shared database, shared libraries)
- Complex protocols (SOAP, WS-*)
2.3 Microservices — SOA done right
Microservices inherit the SOA idea but with core principles:
┌──────────────────────────────────────────────────────┐
│ API GATEWAY │
└──────┬──────────┬──────────────┬─────────────────────┘
│ │ │
┌────┴────┐ ┌───┴────┐ ┌─────┴─────┐
│ User │ │Product │ │ Order │
│ Service │ │Service │ │ Service │
│ │ │ │ │ │
│ ┌─────┐ │ │┌─────┐ │ │ ┌──────┐ │
│ │ DB │ │ ││ DB │ │ │ │ DB │ │
│ └─────┘ │ │└─────┘ │ │ └──────┘ │
└─────────┘ └────────┘ └───────────┘
Mỗi service: Own database, Own deployment, Own team
Compare SOA vs Microservices:
| Criteria | SOA | Microservices |
|---|---|---|
| Communication | ESB (centralized) | Smart endpoints, dumb pipes |
| Data | Popular Shared DB | Database per service |
| Size | Can be very large | Small, focused |
| Deploy | Usually deployed with | Independent deployment |
| Technology | Usually homogeneous | Polyglot |
3. Frontend Monolith — The neglected problem
3.1 Backend has been separated, Frontend is still merged
Many organizations have adopted Microservices for the backend, but the frontend is still one giant SPA application (React/Angular/Vue monolith).
3.2 Consequences of Frontend Monolith
- Code coupling: All teams contribute to the same frontend repo
- Tech lock-in: Cannot gradually upgrade the framework
- Slow builds: Bundle size is getting larger
- Deployment bottleneck: Must deploy the entire frontend
- Team dependencies: Team A waits for Team B to merge the code
3.3 Micro Frontend — solution
┌─────────┐ ┌──────────┐ ┌─────────────┐
│ User │ │ Product │ │ Order │
│ MFE │ │ MFE │ │ MFE │
│ (React) │ │ (Vue) │ │ (React) │
└────┬────┘ └─────┬────┘ └──────┬──────┘
│ │ │
└─────────┬───┴──────────────┘
│
┌─────────┴──────────┐
│ SHELL / CONTAINER │
│ Application │
└────────┬────────────┘
│
┌─────────────┴────────────────────────┐
│ API GATEWAY │
└──────┬──────────┬──────────┬─────────┘
┌────┴────┐ ┌───┴────┐ ┌──┴────────┐
│User µS │ │Product │ │Order µS │
└─────────┘ └────────┘ └───────────┘
4. When should you switch?
4.1 Signals need Microservices
- Team > 10 people working on the same codebase
- Release is blocked by another team
- Uneven Scaling: 1 module needs to be scaled but all must be scaled
- Technology lock-in: want to use new tech but can't
- Failure cascade: 1 bug crashes the entire system
4.2 Signals need Micro Frontend
- Multiple teams develop features on the same frontend app
- Frontend build time > 5 minutes
- Merge conflicts frontend frequently
- Want to upgrade framework but have to change everything
- Independent release for each UI part
4.3 When NOT to?
Don't fix what ain't broken.
- Small team (< 5 devs) → Monolith is enough
- MVP / Startup → Development speed is more important than architecture
- Simple system, few changes → Over-engineering
- Team does not have enough DevOps experience → Microservices increase operational complexity
5. Overview of this series
5.1 Learning Roadmap
Phần 1-3: Backend Foundation → DDD, Service Design, Data Architecture
Phần 4-5: Micro Frontend → Architecture, Implementation, Design System
Phần 6: Integration Layer → BFF, API Gateway, GraphQL Federation
Phần 7-8: Quality & Deploy → Testing, CI/CD, Deployment Strategies
Phần 9: Production → Observability, Performance, Readiness
Phần 10: Real World → Case Study, Migration Guide
5.2 Cross-cutting projects
Throughout the series, we will design a complete E-Commerce Platform:
- 5 Microservices: User, Product, Cart, Order, Payment
- 5 Micro Frontends: Homepage, Product Detail, Cart, Checkout, Account
- Shared: Design System, Auth, API Gateway
Summary
| Architecture | When to use | Main Tradeoff |
|---|---|---|
| Monolith | Small team, MVP, simple system | Easy to start, difficult to scale |
| Microservices | Large team, need to scale independently | Complicating ops & data |
| Micro Frontend | Many FE teams, need to deploy independently | Increase bundle size, need system design |
| Full-stack (MS + MFE) | Large organization, complex products | Need high DevOps maturity |
Read more
- Martin Fowler — Microservices
- Martin Fowler — Micro Frontends
- microservices.io — Pattern Language
- micro-frontends.org
Next article: Lesson 2: Domain-Driven Design — System separation thinking