--- title: How do you choose between microservices and monoliths? description: Learn when microservices make sense and when a monolith is the smarter choice. Covers team size, scale, complexity and deployment trade-offs. image: https://weareaffective.com/hubfs/learning-centre-images/how-do-you-choose-between-microservices-and-monoliths.webp --- [Skip to content](https://weareaffective.com/learning-centre/how-do-you-choose-between-microservices-and-monoliths#main-content) [![we\_are\_affective\_logo\_200](https://weareaffective.com/hs-fs/hubfs/we_are_affective_logo_200.png?width=175&height=48&name=we_are_affective_logo_200.png "we_are_affective_logo_200")](https://weareaffective.com) - [Home](https://weareaffective.com) - About Us - [Our Story](https://weareaffective.com/about) - [How We Work](https://weareaffective.com/how-we-work) - Our Services - [App Planning & Strategy](https://weareaffective.com/app-planning-strategy) - [App Design](https://weareaffective.com/app-design-agency) - [App UX Design](https://weareaffective.com/app-ux-design) - [App UI Design](https://weareaffective.com/app-ui-design) - [App Technical Architecture](https://weareaffective.com/app-architecture) - [Existing App Audits](https://weareaffective.com/app-audit) - [Case Studies](https://weareaffective.com/case-studies) - [Pricing](https://weareaffective.com/pricing) - [Learning Centre](https://weareaffective.com/learning-centre) - [Get Started](https://weareaffective.com/get-started) Expert Guide Series # How do you choose between microservices and monoliths? Table of Contents Architecture decisions are rarely made in calm conditions. A product is growing faster than expected, a new feature is blocked by an old coupling, or a developer read a blog post about how Netflix scaled to millions of users and now the team is convinced they need the same approach. The microservices versus monolith question tends to arrive in that kind of heat, which is exactly when it is most likely to go wrong. > The architecture that scaled Netflix is not the architecture your product needs right now. We have been asked this question on products ranging from a holistic mental health and wellness platform to a toll management system with staged API ambitions, and the answer has never been the same twice. What the question actually reveals is [how much a team understands about its own constraints](https://weareaffective.com/learning-centre/what-developer-team-size-works-best-for-your-app-project): its size, its usage patterns, its deployment maturity, and how much organisational complexity it is genuinely ready to carry. This article works through the real considerations behind that choice, including where we have landed on specific products and what drove those decisions. The aim is not to crown a winner. The aim is to give you enough to make the right call for your situation, not someone else's. ## What the microservices versus monolith decision actually involves The framing teams typically start with is a simple comparison: one big thing versus many small things. That framing is accurate at the surface level and misleading at every level below it. The real decision involves at least four separate questions, and answering only one of them correctly while ignoring the others produces an architecture you will be fighting within eighteen months. Those four questions are roughly these. First, how does your system actually get used, and are different parts of it under different load at different times? Second, how many engineers do you have, and can they coordinate across service boundaries without creating more friction than they remove? Third, how mature is your deployment infrastructure, and can you operate independent deployment pipelines without significant new investment? Fourth, how well do you understand your domain boundaries right now, or are you still discovering them? A team that answers all four honestly will often find that the choice is already made for them. The teams that run into trouble are the ones who answer only the first question and pick an architecture that presumes good answers to the other three. ## What a monolith is and when it is the right default A monolith is a single deployable unit where all the application's components live together and run in the same process, and understanding that structure is central to any serious [app architecture design](https://weareaffective.com/app-architecture-design-we-are-affective) process. That sounds like a limitation, and the popular narrative has treated it as one for a decade. The reality is that a monolith is a perfectly sensible architecture for a very wide range of products, particularly ones that are still finding their domain model. The strongest argument for starting with a monolith is that it keeps the cost of changing your mind low. When you are early in a product's life, you are making domain decisions under uncertainty. Where do the boundaries actually belong? Which concepts are genuinely separate concerns and which ones only look separate until you try to split them? A monolith lets you refactor those boundaries cheaply because everything is in one place. Splitting a monolith into services once you understand the domain is a tractable problem. Merging services that turned out to be the wrong split is painful, slow, and demoralising. A monolith also makes local development straightforward, debugging faster, and deployment simpler. For a team of [fewer than ten engineers](https://weareaffective.com/learning-centre/what-developer-team-size-works-best-for-your-app-project), these represent hours of productivity per week per person, compounded across every sprint. Before reaching for microservices, map your domain boundaries on a whiteboard. If the lines keep moving, you are not ready to commit them to separate deployable services. ## Start your app project the *right* way We deliver the complete blueprint before a line of code is written. User research, psychology-driven design and full technical specifications. You choose who builds it. [See how we work](https://weareaffective.com/how-we-work) [Get started](https://weareaffective.com/get-started) No commitment ## What microservices are and what they genuinely require Microservices split an application into independently deployable services, each responsible for a narrow slice of the domain. The appeal is real: a team can deploy a change to the payments service without touching the notifications service, and a spike in image processing load can be handled by scaling only the image processing service rather than the whole application. But those benefits only materialise when the supporting conditions exist. Microservices require each service to communicate over a network, which means latency, serialisation overhead, and the possibility of partial failures that do not exist inside a single process. They require independently managed databases, or at least independently managed schemas, which means cross-service data consistency becomes a problem you have to solve deliberately. They require a deployment pipeline capable of handling multiple independent services without creating confusion about which version of what is running where. > Microservices move complexity from your code into your infrastructure and your organisation. That last point is the one most often underestimated. Microservices do not eliminate complexity. They redistribute it. The complexity that used to live inside a single codebase now lives in service contracts, network topology, deployment orchestration, and observability tooling. If your team is not equipped to manage that redistribution, the architecture will cost more than it returns. ## The hidden complexity cost of microservices Every service boundary is a contract, and every contract needs to be versioned, documented, and maintained. When that service is owned by a separate team with its own roadmap and its own priorities, the contract becomes a coordination problem. A change to the API of one service requires the consumers of that service to update their code, and those consumers may have no particular reason to prioritise that work right now. Distributed tracing is another cost that surfaces quickly. When a request fails in a monolith, the stack trace tells you where it failed. When a request fails in a microservices system, the failure may have occurred in any one of five services, and correlating the logs from all five requires tooling that must be built, maintained, and understood by every engineer on the team. Testing is harder too. An integration test in a monolith runs inside a single process. An integration test in a microservices system either requires every dependent service to be running locally (which is slow and complex) or uses mocks (which may not reflect the actual behaviour of the real service). None of this means microservices are the wrong choice. It means the operational overhead is real, and it must be funded from somewhere. [CNCF, 2025](https://dev.to/fuadhusnan_f44f3e13/monolith-vs-microservices-when-to-choose-when-to-reject-5aaa) found that 42% of microservices adopters have recombined services back into monolithic or modular structures, which suggests the overhead is being underestimated regularly enough to force a reversal at scale. ## How team size and structure should shape your architecture Conway's Law, the observation that systems tend to mirror the communication structures of the organisations that build them, is a practical constraint. A team of five engineers building a microservices system will spend a disproportionate amount of time on service coordination that a larger team could distribute across dedicated owners. The rough mental model is that a service wants an owner, and an owner wants to have enough work to justify the maintenance burden of that ownership. When you have three engineers maintaining eight services, either the services are too numerous or the engineers are stretched. Neither is sustainable. #### Matching architecture to org structure | Team size | Recommended starting point | Reason | | --- | --- | --- | | 1 to 5 engineers | Modular monolith | Coordination overhead outweighs deployment independence | | 5 to 20 engineers | Monolith with selective extraction | Extract only where load or team boundaries genuinely demand it | | 20+ engineers | Microservices with strong ownership model | Independent deployment becomes a genuine productivity multiplier | The structure of the team matters as much as its size. If a single team owns the whole product, a monolith keeps everyone in sync with minimal process. If three product teams own different product surfaces, a service boundary between those surfaces lets each team deploy independently without stepping on each other's work. The architecture should serve the team structure, and the team structure should reflect the product's actual domain boundaries. ## How usage patterns and scale affect the choice The most commonly cited reason for choosing microservices is scale, and it is also the most commonly misapplied one. Scale is a legitimate driver of architectural change, but only when specific parts of your system face different load profiles at the same time, and only when your current architecture genuinely cannot handle the volume. If your product receives steady, uniform load across all its features, a monolith can be scaled horizontally with multiple instances behind a load balancer. That is a sensible and proven approach. The microservices advantage emerges when, say, your video processing pipeline is under sustained heavy load while your user authentication service is mostly idle. Scaling the whole monolith to serve the video pipeline wastes resources on the authentication service. Scaling only the video processing service solves the actual problem. Look at your actual load profile before assuming you need independent scaling. If all your services would scale together anyway, you are paying the microservices tax without collecting the microservices dividend. Usage patterns also affect latency tolerance. A service that handles one request per user per day can absorb a few hundred milliseconds of additional network overhead. A service that handles a hundred interactions per session cannot. That distinction matters when deciding whether a logical separation should become a physical one. ## Why a staged approach often beats committing early Committing to a full microservices architecture before you understand your domain is a way of multiplying the cost of every wrong decision you are about to make. When you split the domain incorrectly in a monolith, you move some code. When you split the domain incorrectly in a microservices system, you change service contracts, update consumer code across multiple repositories, run dual-version APIs during the transition, and then merge or re-split after the fact. We saw a version of the staged approach work well on the toll management product. The original ambition included live API integrations with established toll operators to pull in real-time balance data. We had to work through with the client why a brand-new, unproven platform would struggle to negotiate data-sharing agreements with incumbent operators who had no reason to prioritise an unknown product. The smarter path was to launch using a preloaded credit model and build credibility first. Once the platform had demonstrated traction, the conversations with toll operators would be different ones. The client accepted that approach, and it preserved the architecture's simplicity at launch without foreclosing the more connected version later. A staged approach is a way of deferring architectural decisions until you have the information needed to make them well. Start with the simplest architecture that serves your current scale and team size, build clean module boundaries inside it, and extract services when a genuine forcing function appears: a team boundary, a load profile that diverges, a deployment cadence that cannot be reconciled. ## When a monolith with queues outperforms a distributed system One of the more instructive decisions we made was on a holistic mental health and wellness product, a full 360-degree platform covering mental health, eating habits, exercise, and wellness. We evaluated serverless architecture early in the process. The problem was the endpoint usage pattern. Serverless functions handle load spikes well, but they carry cold-start latency when they have been idle. Without a steady, consistent stream of requests hitting the same endpoints, that cold-start penalty would have surfaced at precisely the worst moments: when [a user opens the app after a few days away](https://weareaffective.com/learning-centre/what-makes-people-remember-your-app-when-they-need-it) and needs a responsive experience. We recommended and built a monolithic service with message queues and a small number of separate services for specific workloads. That combination gave us the reliability of a persistent process for the core user-facing interactions, with the flexibility to handle background jobs and asynchronous processing through queues without forcing everything into the same synchronous request cycle. #### What message queues solve that services do not A queue lets you decouple the timing of a task from the timing of the request that triggered it. A [user submits a wellness check-in](https://weareaffective.com/learning-centre/5-user-testing-methods-that-will-save-your-app-from-failure), and the processing that follows, scoring, trend analysis, notification generation, happens in the background without making the user wait. That separation is often enough. Many products that reach for microservices because they want async processing would get the same result from a well-placed queue inside or alongside a monolith, with far less operational overhead. Amazon Prime Video's own engineering team made a version of this same discovery when they moved their video quality analysis service from a distributed architecture to a single-process monolith, reporting a [90% reduction in infrastructure costs](https://dev.to/fuadhusnan_f44f3e13/monolith-vs-microservices-when-to-choose-when-to-reject-5aaa) as a result. The distributed system had solved a problem the single-process approach handled more cheaply. ## How deployment tooling changes the microservices calculus Five years ago, running a microservices system meant building and maintaining a significant amount of deployment infrastructure by hand. Container orchestration, service discovery, secrets management, log aggregation, each of these required engineering effort before any business logic could be shipped. That cost made microservices a meaningful investment that only larger teams could justify. The tooling has moved considerably. On a serverless project, one of the things that genuinely surprised us was how simple modern deployment tooling has become. Something can be deployed within minutes from a standing start. Storing infrastructure as code inside the repository means [a new environment for QA or user testing](https://weareaffective.com/learning-centre/5-user-testing-methods-that-will-save-your-app-from-failure) can be spun up quickly, consistently, and without relying on a single person who remembers how it was configured last time. That flexibility and consistency is something a manual deployment process cannot match. That shift in tooling lowers the operational threshold for microservices, but it does not eliminate it. The tooling reduces the cost of running services independently. It does not reduce the cost of designing service boundaries correctly, managing inter-service contracts, or debugging distributed failures. The infrastructure problem is largely solved. The organisational and design problems are not. If your team has not yet run a production microservices deployment end to end, spend a sprint standing up the tooling before you commit the architecture. The gap between "we could do this" and "we have done this and know what it costs" is significant. ## The questions to ask before you decide Rather than a checklist, these are the questions that have actually changed the answer on real products. Work through them honestly, and the architecture tends to reveal itself. 1. Do different parts of your system face genuinely different load profiles at the same time? If yes, independent scaling has a real case. If no, horizontal scaling of a monolith is simpler and cheaper. 2. Do you have more than one team that needs to deploy independently without coordinating releases? If yes, service boundaries can genuinely help. If no, they add coordination overhead without removing it. 3. How confident are you in your domain boundaries right now? If the answer is "we are still discovering them", a monolith with clean internal modules keeps your options open. 4. Does your team have operational experience running independent deployment pipelines, distributed tracing, and inter-service debugging in production? If no, that investment needs to be factored into the decision. 5. Are there specific workloads, background processing, media handling, [third-party integrations, that have genuinely different non-functional requirements](https://weareaffective.com/learning-centre/the-hidden-complexity-of-delivery-apps-what-every-business-owner-should-know) from the rest of the product? Those are the candidates for extraction, not the whole application. The goal is not to arrive at the most architecturally ambitious answer. The goal is to arrive at the answer that lets your team ship reliably, change quickly, and avoid fighting the infrastructure instead of building the product. ## Conclusion The microservices versus monolith decision is mostly a question of honest self-assessment. Teams that choose microservices because a conference talk made it sound like the correct answer, or because a job advert said it was required, tend to spend the next year paying for that assumption. Teams that choose a monolith because it is easier tend to do well until they grow past its natural limits, at which point the extraction work is tractable if the internal module boundaries were kept clean. What we have found across different products, the wellness platform, the toll management system, the serverless experiments, is that the architecture that performs best is the one chosen in response to actual constraints rather than anticipated ones. Start with the simplest thing that serves your current team and your current load. Build clean boundaries inside it. Extract when a real forcing function appears, and do it deliberately rather than under pressure. The staged approach is a recognition that architectural decisions made under uncertainty cost more to reverse than ones deferred until the picture is clearer. Build what you understand. Extract what you need. And keep the operational cost of your architecture honest against the team that has to carry it. If you are working through this decision on a specific product and want to think it through with people who have been in it, [let's talk about your architecture](https://weareaffective.com/get-started). ## Frequently Asked Questions How do I know which architecture is right for my product? The decision comes down to four honest questions about your system: how it gets used under load, how many engineers you have, how mature your deployment infrastructure is, and how well you understand your domain boundaries. A team that answers all four clearly will often find the choice makes itself. The trouble starts when teams focus only on usage patterns and assume everything else will fall into place. Is a monolith a sign that a product is technically immature? Not at all. A monolith is a perfectly sensible architecture for a wide range of products, particularly those still discovering their domain model. The popular narrative has treated it as a limitation for years, but that framing ignores the genuine strengths a monolith offers, especially early in a product's life. Why is starting with a monolith often the safer choice for new products? A monolith keeps the cost of changing your mind low, which matters enormously when you are still working out where your domain boundaries actually belong. Refactoring a monolith into services once you understand the domain is a tractable problem. Merging services that turned out to be the wrong split is painful, slow, and demoralising. Does the fact that Netflix uses microservices mean my product should too? No. The architecture that scaled Netflix reflects Netflix's specific team size, usage patterns, deployment maturity, and organisational complexity at a particular point in time. Applying that approach to a product at a much earlier stage, with a much smaller team, is likely to create more friction than it removes. Your product needs the architecture that fits your actual constraints, not someone else's. What goes wrong when teams choose microservices too early? The most common problem is splitting the domain before it is properly understood, which produces service boundaries that turn out to be wrong. Incorrect boundaries in a microservices architecture are expensive to fix because changes ripple across independent deployments and teams. Teams that ignore questions about engineering coordination and deployment infrastructure tend to find themselves fighting the architecture within eighteen months. Does team size genuinely affect which architecture I should choose? Yes, it is one of the four core questions worth answering honestly before making any decision. Coordinating across service boundaries requires real engineering overhead, and a small team can easily spend more effort managing that coordination than it gains from the separation. Microservices work well when you have enough engineers to own and operate services independently without creating constant friction. What does deployment maturity mean, and why does it matter here? Deployment maturity refers to how capable your infrastructure and team are at running independent deployment pipelines reliably. Microservices require each service to be deployed, monitored, and scaled separately, which is a significant operational commitment. If that capability is not already in place, adopting microservices means building it at the same time as building the product, which adds considerable risk and cost. Can I start with a monolith and move to microservices later? Yes, and for many products this is the more sensible path. A well-structured monolith allows you to learn your domain properly before committing to service boundaries, which means any future split is based on real understanding rather than early assumptions. The key is keeping the monolith well organised internally so that extracting services later remains a manageable task rather than an archaeology project. ## Related Articles [![We Are Affective](https://weareaffective.com/hubfs/we_are_affective_logo_mark.svg)](https://weareaffective.com) 20-22 Wenlock Road London, N1 7GU United Kingdom +44 20 4572 8062 [hello@weareaffective.com](mailto:hello@weareaffective.com) Services [App planning & strategy](https://weareaffective.com/app-planning-strategy) [App design](https://weareaffective.com/app-design-agency) [App UX design](https://weareaffective.com/app-ux-design) [App UI design](https://weareaffective.com/app-ui-design) [App technical architecture](https://weareaffective.com/app-architecture) [Existing app audits](https://weareaffective.com/app-audit) Legal [Privacy policy](https://app.termly.io/policy-viewer/policy.html?policyUUID=b8fa9921-7518-4fb5-8ddd-9dc7f5977ed2) [Terms](https://app.termly.io/policy-viewer/policy.html?policyUUID=8b6a6ad5-91bd-4176-a5f7-6d36b0398f70) Case studies [TravAI](https://weareaffective.com/case-studies/travai) [Meditech](https://weareaffective.com/case-studies/harley) [WorkingWeight](https://weareaffective.com/case-studies/workingweight) [SkinSync](https://weareaffective.com/case-studies/skinsync) [Three Lochs](https://weareaffective.com/case-studies/three-lochs) [Drift](https://weareaffective.com/case-studies/drift) About us [Our Story](https://weareaffective.com/about) [How We Work](https://weareaffective.com/how-we-work) Guides [Creating an app](https://weareaffective.com/how-to-create-an-app) [Building an MVP](https://weareaffective.com/building-an-mvp) [Cost and budgeting](https://weareaffective.com/app-development-cost) [App technology](https://weareaffective.com/app-development) [Planning and strategy](https://weareaffective.com/app-planning-strategy) [User research](https://weareaffective.com/app-user-research) [Onboarding design](https://weareaffective.com/app-onboarding-design) [User psychology](https://weareaffective.com/user-psychology-app-design) [Launch and growth](https://weareaffective.com/app-launch-growth) Copyright © 2026, weareaffective.com. All rights reserved.