The internet pushes “best practices” like microservices as if they were universal truths. In reality, architecture is about tradeoffs. We’ve seen small teams thrive with simple monoliths, and others hit walls without modularity. This guide helps you avoid expensive mistakes and choose the architecture that fits your team, stage, and product.
This isn’t a manifesto against microservices; it’s a field guide for choosing the architecture that matches your reality.
The Expensive Mistakes We’ve Seen
The Microservices Death Spiral
The Pattern:
- Team reads about Netflix’s architecture.
- Decides they need microservices for “scale.”
- Splits their 10,000-user app into 15 services.
- Now has 15 CI/CD pipelines, 15 dashboards, and 15 potential points of failure.
- Spends 80% of time on infrastructure complexity, 20% on features.
- Competitors using monoliths ship faster and win.
Disclaimer: Netflix’s architecture is for Netflix’s org chart, not your startup.
When Monoliths Win
The 95% Rule
Most companies are better off starting, and often staying, with a monolith. Here’s when:
1. Pre-Product-Market Fit
- Your biggest risk is customer adoption, not technical scale.
- You need maximum iteration speed to find what works.
- The team is small (<10 developers).
- The boundaries between different parts of your domain are still emerging.
2. Human, Not Technical Scale
- You have fewer than 100,000 daily active users.
- You handle fewer than 1,000 requests per second.
- The database can comfortably fit on a single, powerful server.
- The primary challenges are business-related, not technical bottlenecks.
3. Low DevOps Maturity
- You don't have a dedicated Site Reliability Engineering (SRE) team.
- Developers are not experienced with the complexities of distributed systems.
- There is no in-house Kubernetes expertise.
- On-call capacity is limited.
When Microservices Make Sense
Real Scenarios That Justify Complexity
1. Genuine Technical Boundaries
Example: A Video Streaming Platform (like Netflix)
- Video Encoding Service: CPU-intensive, scales independently based on upload volume.
- User Service: Standard CRUD operations, minimal resource needs.
- Recommendation Engine: ML workloads requiring GPUs.
- Billing Service: High security and compliance requirements, interacts with third-party payment gateways.
Each of these has fundamentally different scaling, security, and hardware needs.
2. Organizational Boundaries
Example: An Enterprise E-commerce Platform (like Amazon)
- Payments Team: 20 developers, Java experts.
- Product Catalog Team: 15 developers, focused on data ingestion and search, using Python.
- Customer Portal Team: 25 developers, building a rich user interface with React/Node.
When teams are large and operate independently with different tech stacks and release cycles, microservices can reduce coordination overhead.
3. Compliance and Security Isolation
Example: A Healthcare Platform
- Patient Data Service: Must be HIPAA compliant, with data encrypted at rest and in transit, and housed in an isolated network segment.
- Public Marketing Website: Contains no Protected Health Information (PHI) and can live outside the compliance boundary.
- Analytics Service: Operates on fully anonymized data only.
Regulatory requirements often force architectural boundaries to protect sensitive data.
The Middle Ground: Coarse-Grained Services
After years of extremes, many teams find the coarse-grained approach hits the sweet spot.
What It Looks Like:
- A handful of services (not one mudball, not 50+ microservices).
- Boundaries drawn around risk, compliance, or scale (e.g., auth, billing, core app, async workers).
- Shared infrastructure standards (CI/CD, monitoring, logging).
- Each service is coarse-grained enough to be valuable on its own, but simple enough to avoid orchestration theatre.
- Can evolve into more services later only if pain justifies it.
Migration Patterns That Work
Monolith to Microservices (When You Actually Need It)
The Strangler Fig Pattern:
As described by Martin Fowler, this is the most reliable way to migrate.
- Identify the Bottleneck: Measure, don't guess. Find the part of the system under the most strain.
- Build the New Service: Create the new microservice alongside the existing monolith.
- Gradually Redirect Traffic: Use a proxy or feature flags to send a small percentage of traffic to the new service, increasing it as confidence grows.
- Decommission the Old Code: Once the new service is stable and handling all relevant traffic, remove the old code from the monolith.
Success Story: Uber
Uber started as a single monolithic application. As it expanded globally, this architecture became a bottleneck. The company successfully migrated to a microservices architecture to handle the complexity of its worldwide operations, allowing teams to work independently on features like rider matching, payments, and driver onboarding.
Microservices to Monolith (Yes, This Happens)
When to Consolidate:
- Services that are almost always deployed together.
- Services with "chatty" communication that creates high latency.
- Services owned by the same team where the separation creates more work than it saves.
- Services where the orchestration and networking code outweighs the business logic.
Success Story: Segment
As mentioned earlier, Segment's team found that their microservices architecture increased operational overhead and slowed them down. Consolidating back to a monolith allowed them to simplify their system, reduce maintenance, and improve developer velocity.
The Decision Framework
Ask these questions in order, as inspired by Martin Fowler's "Monolith First" principle.
├── Have Product-Market Fit?
│ ├── [No] → Build a Monolith
│ └── [Yes] → Have 50+ Developers Across Multiple Teams?
│ ├── [No] → Build a Monolith
│ └── [Yes] → Do Teams Have Independent Business Domains?
│ ├── [No] → Build a Coarse-Grained Architecture
│ └── [Yes] → Can You Afford a Dedicated DevOps/SRE Team?
│ ├── [No] → Build a Coarse-Grained Architecture
│ └── [Yes] → Do Domains Have Radically Different Tech Needs?
│ ├── [No] → Build a Coarse-Grained Architecture
│ └── [Yes] → Extract Microservices Selectively
Practices That Matter Either Way
1. Design for Future Extraction
- Enforce strict module boundaries.
- Prohibit cross-module database queries.
- Define clear contracts between coarse-grained services (API, RPC, message queues).
- Ensure modules have independent test suites.
2. Invest in Developer Experience
- A one-command local setup is non-negotiable.
- Fast, reliable test suites.
- Excellent logging, monitoring, and tracing.
- Clear, accessible documentation.
3. Measure What Matters
- Feature delivery velocity.
- Time from commit to production.
- Mean Time To Recovery (MTTR) after an incident.
- Developer satisfaction and retention.
Rule of Thumb
For most companies:
- Start with a monolith. Unless there is a clear reason to do otherwise.
- Split into coarse-grained services. Only where it clearly reduces risk or complexity.
- Measure everything. Let data drive your decisions.
- Optimize for developer velocity. Not for architectural purity.
The Exception
If your business is inherently a distributed system from the start (e.g., a banking platform, or an IoT platform managing thousands of devices), starting with a few core services might make sense. But even then, begin with the smallest number of services possible.
Microservices are often a solution to organizational scaling problems, not technical ones. If you don't have the organizational problems of a company like Netflix or Amazon, you don't need their architecture.
The best architecture is the one that lets your team ship value to customers quickly and reliably. For most teams, most of the time, that’s a well-structured monolith. Focus on solving your customers' problems, not Netflix's.
About 7Sigma
7Sigma was founded to close the gap between strategy and execution. We partner with companies to shape product, innovation, technology, and teams. Not as outsiders, but as embedded builders.
From fractional CTO roles to co-founding ventures, we bring cross-domain depth: architecture, compliance, AI integration, and system design. We don’t add intermediaries. We remove them.
We help organizations move from idea → execution → scale with clarity intact.
Don't scale your team, scale your thinking.
Learn more at 7sigma.io
Authored by: Robert Christian, Founder at 7Sigma
© 2025 7Sigma Partners LLC
