A vendor once proposed a microservices architecture, eight services, three message queues, a separate deployment pipeline for each, for an internal inventory app serving 40 warehouse staff. The company had one backend developer. Monolith vs microservices for small business shouldn't even be a real debate at that scale, but I see this pitch constantly, usually from teams who want an interesting resume line more than they want your problem solved.
Here's the uncomfortable truth: microservices solve organizational problems, not technical ones. They exist so that large engineering teams can work on different parts of a system without stepping on each other, and so that different components can scale independently under genuinely different load. If you have one team, or even three teams, and traffic that doesn't spike ten times differently across features, you don't have that problem. You have a business that needs software to work reliably, ship quickly, and not require a platform team to maintain.
This is permission to say no the next time someone quotes you for distributed architecture on a system that fits comfortably in one well-organized codebase.
Microservices solve organizational problems, not technical ones.
Ervandra Halim
What Justifies Splitting a System Into Microservices?
Splitting a system into microservices is justified only under specific, checkable conditions: team size, genuinely different scaling profiles, independent release cadence, or real polyglot needs. If none of these conditions apply to your business, stop reading vendor proposals that assume they do, because the complexity tax buys you nothing at your scale.
- Team size crosses roughly 15-20 engineers working on the same product, where a shared codebase creates constant merge conflicts and deployment coordination overhead.
- Genuinely different scaling profiles. Your checkout service gets 50x the traffic of your admin reporting panel, and you need to scale them independently rather than paying to over-provision the whole app.
- Independent release cadence is a real business need. One team needs to deploy daily, another touches code once a month, and coupling their releases actually slows the business down.
- Polyglot requirements. You genuinely need a different language or runtime for one component (a machine learning service in Python bolted onto a Node.js app, for example).
Notice what's missing: "it's more scalable" and "it's the modern way to build software" are not on this list. They're marketing language, not engineering justification.
What's the Real Cost Nobody Quotes You On?
The real cost nobody quotes you on is operational surface area, and it multiplies with every microservice you add. Each new service needs service discovery, network reliability handling (timeouts, retries, circuit breakers), distributed tracing to debug a request that touches four services, a separate CI/CD pipeline, and version compatibility with services that evolve independently.
For a team of two or three developers, this overhead isn't a one-time cost, it's a permanent tax on every feature you ship. A bug that would take twenty minutes to trace in a monolith (read the stack trace, find the function) can take half a day in a distributed system (which service logged the error, was it a timeout or a real failure, which version was deployed at the time).
I've watched a 500-user internal finance tool get rebuilt as microservices, and the team went from shipping features weekly to shipping monthly, not because the business got more complex, but because every change now touched three repositories and two deployment pipelines instead of one.
What Does a Well-Built Monolith Actually Look Like?
A well-built monolith looks organized internally, not tangled, and that internal organization is what actually separates it from the monoliths people complain about. The common complaint against monoliths is usually really a complaint against badly organized ones, not against the monolith pattern itself. A well-built monolith has:
- Clear internal module boundaries. Your billing logic, inventory logic, and user management live in separate folders or modules with defined interfaces between them, even though they deploy together.
- A single, fast test suite that runs in minutes, not hours, so developers get quick feedback.
- One deployment pipeline that ships the whole app reliably, which is dramatically simpler to reason about than coordinating multiple services.
- A database schema that reflects real business boundaries, even if it's one database, tables and access patterns can still be cleanly separated by domain.
This structure, sometimes called a "modular monolith," gives you almost all the organizational clarity of microservices with none of the network complexity. And critically, if you ever do cross the team-size or scaling threshold that justifies splitting, a well-modularized monolith splits cleanly. A tangled one doesn't, regardless of whether it started as a monolith or microservices.
How to Tell If Your Vendor Is Selling Complexity
Ask these three questions when someone proposes a distributed architecture for your business:
- "How many engineers will be working on this in year one?" If the answer is under five, ask them to justify the split concretely.
- "What specific scaling problem does this solve that a single well-indexed database and app server can't?" Vague answers about "future scale" are a red flag.
- "What's the added operational cost, in hours per month, of running this versus a monolith?" If they can't answer, they haven't thought about who maintains this after launch.
This same instinct, checking whether a proposal matches your actual scale rather than your vendor's ambitions, applies broadly. If you're evaluating whether a full website redesign is worth it or vanity, the same discipline applies: match spend to a checkable business need, not to what sounds impressive in a pitch deck.
When You Should Actually Consider Splitting
If your team has genuinely grown past 15-20 engineers on one product, or one specific component has a scaling profile ten times different from the rest of your system, start by splitting out that one component, not by rearchitecting everything at once. Extract the piece under real strain (often a search service, a notification service, or a heavy reporting job) and leave the rest as the monolith. This incremental approach is how most successful microservice adoptions actually happened, not as a big-bang rewrite, but as pressure-tested extraction over time.
The Practical Takeaway
Monolith vs microservices for small business comes down to one question: does your team size or scaling need actually justify the operational tax of distributed systems? For the overwhelming majority of SMEs I work with, the honest answer is no, not yet, and possibly not ever. Build one well-organized application, keep your module boundaries clean, and resist any proposal that adds distributed complexity without a specific, checkable reason. If a vendor can't name that reason in one sentence, they're selling you their portfolio, not solving your problem.
