This content originally appeared on DEV Community and was authored by 7Sigma
Monoliths, Microservices, and the Middle Ground
Architecture is about tradeoffs, not trends. Many teams ship faster and safer with a monolith. Some teams need service boundaries for scale, compliance, or org size. This guide helps you choose what fits your team, stage, and product.
This is not an anti microservices manifesto. It is a field guide to match architecture to reality.
Clear Definitions First
Monolith
A single deployable unit that contains most of the system’s business logic. It can be clean and modular inside. It can talk to external services. It can expose multiple APIs. It still deploys as one core application.
Modular monolith
A monolith with strong internal boundaries. Modules communicate through explicit interfaces, not by reaching into each other’s tables. You keep one deployable, but you design like separate domains. This makes later extraction possible without starting complex.
Microservices
Multiple independent deployables. Each owns its data and lifecycle. Each has its own CI, monitoring, scaling profile, and on call surface area. Flexibility improves, operational overhead increases.
Reference: Martin Fowler, Monolith First.
Architecture vs Project vs Components vs Runtime
Teams often talk past each other because these layers get mixed up. Here is the map.
Architecture
How the system is shaped. Monolith, modular monolith, or microservices. Where the boundaries live, who owns data, how parts communicate.
Project structure
How the code is organized in git. You can have one repo, a monorepo with many packages, or many repos. Any of these can still produce one deployable monolith.
Components and libraries
Shared packages, SDKs, UI kits, schema modules. These can live in separate repos or a monorepo. They can be versioned and published. They are still part of one deployed app if you bundle them into the core.
Runtime topology
What runs in production. One main app can run next to an API gateway, a background worker pool, a job queue, a cache, and a reporting batch. You can also call out to managed services, or an automation layer like n8n, or a payment provider. You still have a monolith if the core business logic deploys as one unit.
Key point
One deployable core with clean internal boundaries is still a monolith, even if:
- You put an API gateway in front.
- You split UI and API into separate build artifacts that ship together.
- You publish SDKs for other teams.
- You run workers, schedulers, and a reporting job next to the app.
- You call external services like search, payments, or n8n flows.
Microservices begin when those domain pieces become separately deployable systems with their own lifecycles and ownership.
The Expensive Mistakes We Have Seen
The microservices death spiral
- Team reads a big company post.
- Decides they need services for scale.
- Splits a 10,000 user app into 15 services.
- Now there are 15 pipelines, 15 dashboards, and 15 failure modes.
- Eighty percent of time goes to infra, twenty percent to features.
- A competitor on a modular monolith ships faster and wins.
The myth of monoliths that do not scale
Many large platforms scaled far on monoliths. Shopify and Basecamp are well known examples. Monoliths hurt when they are poorly structured or when business needs demand isolation, for example a compliance heavy module or a hot path that must scale independently.
When Monoliths Win
The 95 percent rule
Start with a monolith, often stay there.
Pre product market fit
- Risk is adoption, not technical scale.
- Small team, fast change.
- Domain boundaries are still forming.
Human, not technical scale
- Users and throughput fit on one database server.
- Work is mostly about product, not infra.
Low DevOps maturity
- No dedicated SRE yet.
- Limited on call capacity.
- Little distributed systems experience.
When Microservices Make Sense
Genuine technical boundaries
Different scaling or hardware needs, for example GPU workloads vs CRUD vs billing with strict compliance.
Organizational boundaries
Many teams that ship on different cadences and tech stacks, with clear domain ownership.
Regulatory isolation
Domains that must be separated by policy, for example PHI, PCI, or data residency rules.
The Middle Ground: Modular Monolith
A single deployable with strict module boundaries:
- One app, many domains inside.
- Modules talk through public interfaces.
- No cross module table access.
- Later extraction is possible, not mandatory.
This model gives productivity of one deployable and clarity of separated domains.
Migration Patterns That Work
Monolith to services, only when needed
Use a strangler pattern. Identify a real bottleneck, build a service next to the monolith, route a slice of traffic, grow confidence, then remove old code.
Services back to monolith
Consolidate when services are always deployed together, are chatty, or create more orchestration code than business value.
Practices That Matter Either Way
Design for future extraction
- Clear domain boundaries.
- No cross module queries.
- API style contracts.
- Independent tests per module.
Invest in developer experience
- One command local setup.
- Fast and trustworthy tests.
- Useful logs, tracing, and metrics.
- Short, current docs and decision records.
Measure what matters
- Lead time to production.
- Change failure rate.
- Mean time to recovery.
- Developer satisfaction.
Key Takeaways
- Pick a monolith first, make it modular from day one.
- Add services only when data shows real pain or required isolation.
- Keep architecture, project structure, components, and runtime topology separate in your thinking.
- A monolith can still have gateways, side services, SDKs, workers, and automation layers. The difference is one core deployable vs many independent ones.
- Optimize for developer velocity and customer outcomes, not architectural fashion.
Originally published at 7Sigma Blog
Don't scale your team, scale your thinking.
Authored by: Robert Christian, Founder at 7Sigma
© 2025 7Sigma Partners LLC
This content originally appeared on DEV Community and was authored by 7Sigma
7Sigma | Sciencx (2025-08-28T14:34:09+00:00) Don’t Copy Netflix; How to Pick an Architecture That Actually Fits Your Team in 2025. Retrieved from https://www.scien.cx/2025/08/28/dont-copy-netflix-how-to-pick-an-architecture-that-actually-fits-your-team-in-2025-3/
Please log in to upload a file.
There are no updates yet.
Click the Upload button above to add an update.