Microservices Architecture: When It Helps and When It Hurts
A client came to us once with a system that had eleven services for a product with about four hundred active users. Every deploy meant coordinating changes across three of those services in the right order, a routine feature took two sprints instead of two days because of the cross-service testing overhead, and nobody on their small team could confidently say what would happen if one service went down while another was mid-request. The architecture diagram looked impressive. The actual experience of building on it was closer to wading through mud.
That's the pattern we see most often with microservices: teams adopt them because they read that a company operating at a hundred times their scale uses them, not because their own product has actually hit a problem that microservices solve. This piece is about how we actually decide — not the theory, the decision we make with real client budgets and real small teams on the line.
Microservices Amplify Whatever Architecture You Already Have
This is the part that surprises people: splitting a system into services doesn't fix unclear boundaries, it makes them worse, because now the confusion is happening across a network instead of inside a single process. If you're not sure where billing logic ends and user logic begins in your monolith, distributing that same uncertainty across service boundaries doesn't clarify it — it just adds network latency, a new class of partial-failure bugs, and a debugging session that now spans multiple sets of logs instead of one. You genuinely cannot distribute a system you don't understand well as a single codebase yet. Architecture has to follow understanding of the domain, not precede it.
Where They Genuinely Earn Their Keep
There are real conditions where microservices are the right call, and we've built them for clients who met those conditions. A team large enough that multiple groups need to ship independently without stepping on each other. Domains that are well-understood and stable enough that the boundaries between services won't keep shifting every sprint. A genuine compliance or risk reason that a specific piece of the system needs to be isolated — payment processing being separated from everything else, for instance. Or components with wildly different scaling profiles, like a video processing pipeline that needs to burst to dozens of workers sitting next to a CRUD API that barely moves. Absent most of these conditions, microservices don't speed a team up. They slow it down while looking, on paper, like progress.
The Cost Nobody Puts in the Proposal
What microservices actually introduce, in exchange for that isolation, is a set of ongoing costs that are easy to underestimate from a diagram: function calls become network calls that can now fail in new ways, debugging means piecing together logs across multiple services instead of reading one stack trace, and you need real observability — tracing, correlation IDs — from day one or incidents become genuinely un-investigatable. Deployments across services with dependencies need coordination that a single deploy pipeline never required, and the moment you no longer have one database transaction wrapping an operation, you're solving data consistency problems that used to be free. If a team can't confidently run on-call for a distributed system — trace a request across three services at 2am, understand what a partial failure looks like — that team isn't ready for microservices regardless of how clean the architecture diagram looks in the pitch deck.
What We Actually Start With
For nearly every project, the starting point is a clean, well-organized monolith with strong domain boundaries built in from day one — billing, users, permissions, and so on, each owning its own models and internal structure even though it all deploys together. That structure matters more than it looks like it should, because it means when real pressure eventually shows up, extraction is a clean cut instead of a months-long untangling exercise. We pull a service out when something concrete forces it — a team that genuinely needs independent deploys, a component whose scaling needs have diverged sharply from the rest of the system, a compliance requirement that demands isolation — not because a conference talk made it sound inevitable.
The Middle Ground Most Teams Skip
Between "one monolith holding everything" and "fifteen services with their own deploy pipelines," there's a step that gets skipped surprisingly often: pull out just the one or two pieces that have genuinely different operational needs — a webhook processor that needs to scale independently of the main app, an image or video pipeline that has nothing in common, resource-wise, with the rest of the system — and leave everything else together. That gets most of the real benefit of service separation without paying for a dozen deploy pipelines you don't actually need yet. It's the option that looks less impressive in an architecture diagram and works considerably better in practice.
What an Extraction Actually Looks Like
To make that concrete: a real-time marketplace we built processes a constant stream of order events, driver location updates, and payment webhooks, all inside what's otherwise a single deployed application. The webhook handling — receiving events from a payment provider, verifying signatures, updating transaction state — has a completely different load profile than the rest of the app. It's bursty, it needs to respond fast enough that the provider doesn't consider the endpoint unhealthy, and a slow database migration on the main app has no business affecting whether a payment webhook gets acknowledged in time.
That's the one piece we pulled into its own deployable service, with its own lightweight queue in front of it. Everything else — the customer-facing API, the admin dashboard, the reporting — stayed exactly where it was, in the monolith, sharing one deploy pipeline. The extraction took a few days of focused work because the boundary was already clean inside the monolith; it wasn't a redesign, it was a relocation. That's the entire point of structuring a monolith by domain from the start — the day an extraction actually earns its keep, it's a small, well-understood project instead of an open-ended one.
Reading the Organizational Signals, Not Just the Technical Ones
The decision to split a service is at least as much about team dynamics as it is about load. A few honest questions we ask before recommending an extraction to a client: is there an actual team, not just an individual, whose work is currently blocked waiting on another team's deploy? Has the codebase reached a size where a new engineer needs multiple days just to understand which part of the monolith they're supposed to touch? Does the organization already run a mature on-call rotation, with real incident response practice, for the systems it operates today?
If the answer to all three is genuinely yes, a service boundary probably reflects reality that already exists and formalizing it will help. If the answer is no — if it's one team, a codebase a new hire can still get oriented in within a day, and an on-call process that's mostly "whoever's awake checks Slack" — introducing microservices doesn't create that organizational maturity. It just adds distributed-systems failure modes on top of a team that isn't yet equipped to debug them at 2am, which is a worse position than the one they started in.
Final Thoughts
Good architecture reduces the cognitive load on the team that has to live in it every day. Architecture adopted because it's trendy, without a specific problem it's solving, increases that load without buying anything in return. The right call comes from your team's actual size and your domain's actual shape — not from what a company operating two hundred times your scale happens to be doing this year.
