Your CTO proposes "migrating to microservicesWhat is microservices?An architecture where an application is split into small, independently deployed services that communicate over the network, each owning its own data.." A consultant recommends "going serverlessWhat is serverless?A hosting model where individual functions run on demand and the platform handles all server management, scaling, and uptime for you.." An AI tool generates an architecture diagram with twelve services for a product that has zero users. How do you evaluate these recommendations?
There's no universally "best" architecture. Netflix's thousands of microservices would be a disaster for a 3-person startup. Architecture choice depends on team size, product maturity, growth trajectory, and budget.
Team size and expertise
Small teams (1-5 developers)
Start with a monolithWhat is monolith?A software architecture where the entire application lives in a single codebase and deploys as one unit. Simpler to build and debug than microservices.. MicroservicesWhat is microservices?An architecture where an application is split into small, independently deployed services that communicate over the network, each owning its own data. require distributed systems expertise, add coordination overhead, and make debugging harder. Small teams need to focus on product, not infrastructure.
Medium teams (6-20 developers)
Consider modular monolith or limited microservices. Pain points emerge: developers stepping on each other's code, different parts needing different deployment schedules. Consider enforcing clear moduleWhat is module?A self-contained file of code with its own scope that explicitly exports values for other files to import, preventing name collisions. boundaries first, or extracting just the most independent piece (often payments or notifications).
Large teams (20+ developers)
Microservices become attractive. Service boundaries align with team boundaries, teams deploy independently and own services end-to-end. But this requires DevOps expertise, monitoring infrastructure, and automated testing across services.
Product stage considerations
Early stage: Build a monolithWhat is monolith?A software architecture where the entire application lives in a single codebase and deploys as one unit. Simpler to build and debug than microservices.. Ship fast. Validate your product before investing in infrastructure. Teams building MVPs with microservicesWhat is microservices?An architecture where an application is split into small, independently deployed services that communicate over the network, each owning its own data. spend months on plumbing before learning what users actually want.
Growth stage: You've found product-market fit. If one part gets 10x more traffic, or deployments are risky, or teams block each other, extract just the painful piece. Keep the core as a monolith. Repeat only when necessary.
Scale stage: Millions of users. You need specialized services, sophisticated caching, multi-region deployments, and dedicated platform teams.
MigrationWhat is migration?A versioned script that changes your database structure (add a column, create a table) so every developer and server stays in sync.: the strangler fig pattern
Named after a tree that grows around another and eventually replaces it, this pattern gradually migrates functionality from a monolithWhat is monolith?A software architecture where the entire application lives in a single codebase and deploys as one unit. Simpler to build and debug than microservices. to new services.
Step 1: Build new service alongside monolith
Step 2: Route some traffic to new service (feature flags)
Step 3: Gradually increase traffic to new service
Step 4: Remove code from monolith
Step 5: RepeatShopify followed this path: started as a Rails monolith (2006), extracted critical services like payments (2016), and today runs a hybrid, monolith for core commerce, 50+ supporting services. Their insight: "Don't break apart what doesn't need breaking."
Etsy tried microservicesWhat is microservices?An architecture where an application is split into small, independently deployed services that communicate over the network, each owning its own data., reversed course back to a monolith, optimized it instead, and only later extracted specific services. Lesson: "Sometimes better code, caching, and infrastructure gives you what you need."
Total cost of ownership
| Architecture | Servers to Monitor | Deployment Complexity | Debugging Difficulty |
|---|---|---|---|
| Monolith | Low | Simple | Straightforward |
| Microservices | High | Complex | Hard |
| Serverless | None (managed) | Simple | Medium |
Your architecture also affects hiring: monoliths are easier to hire for (most developers understand single apps), microservicesWhat is microservices?An architecture where an application is split into small, independently deployed services that communicate over the network, each owning its own data. need distributed systems experience (expensive, hard to find), and serverlessWhat is serverless?A hosting model where individual functions run on demand and the platform handles all server management, scaling, and uptime for you. needs cloud-specific skills.
Warning signs you've chosen wrong
MicroservicesWhat is microservices?An architecture where an application is split into small, independently deployed services that communicate over the network, each owning its own data. too early: Spending more time on infrastructure than features. Simple changes require deploying 5 services. Can't debug issues across service boundaries.
MonolithWhat is monolith?A software architecture where the entire application lives in a single codebase and deploys as one unit. Simpler to build and debug than microservices. too long: One small change requires testing everything. Teams constantly blocking each other. Can't scale one component without scaling all of them.
ServerlessWhat is serverless?A hosting model where individual functions run on demand and the platform handles all server management, scaling, and uptime for you. not working: Cold starts hurt user experience. Functions became too complex and interdependent. Vendor costs surprisingly high at scale.
The most important factor
Architecture matters less than execution. A well-built monolithWhat is monolith?A software architecture where the entire application lives in a single codebase and deploys as one unit. Simpler to build and debug than microservices. beats a poorly implemented microservicesWhat is microservices?An architecture where an application is split into small, independently deployed services that communicate over the network, each owning its own data. architecture every time. Clean code, good tests, and clear documentation matter more than which pattern you chose.
Start simple, evolve deliberately, and remember: the best architecture is the one your team can build, maintain, and evolve. Everything else is secondary.