Monolith, Microservices or Serverless: Choosing the Right Architecture for a Business Web App

Key Takeaways

• There is no “best” architecture — only the one that matches your team size, traffic pattern, and how much your product is still changing.
• A monolith is the right default for most first builds, and staying with one longer than your competitors is often an advantage, not technical debt.
• Microservices buy independent scaling and independent deploys. They charge you in operational overhead — usually a DevOps hire you hadn’t budgeted for.
• Serverless suits spiky traffic and gets expensive at sustained high volume. The cost curve inverts somewhere in the middle.
• The costly mistake isn’t picking the wrong pattern. It’s picking a complex one too early, before you have the team to run it.

Two companies set out to build the same customer portal: same feature list, similar budgets, teams of roughly the same size. One launched in four months; the other took eleven and spent most of the gap fighting its own infrastructure instead of building features.

The difference wasn’t developer talent. It was a decision made in week one, in a meeting where nobody wrote any code — the choice of how the system would be structured. It’s worth understanding that decision before you sign off on it, because the architecture for web application projects at this scale sets your hiring plan, your monthly infrastructure bill, and how fast you can ship changes two years from now. Those are business outcomes wearing technical vocabulary.

This guide covers the three patterns you’ll be asked to choose between, what each actually costs, and six questions that point to the right one.

What “Architecture” Actually Means When Someone Says It in a Meeting

Strip away the jargon and every web application does three jobs.

It shows things to people — screens, buttons, forms. It decides things — who can see what, whether a payment goes through, what happens when a document is uploaded. And it remembers things — the database where users, orders, and documents live.

Developers call these the presentation layer, the business logic layer, and the data layer. Think of a restaurant: the dining room where guests sit, the kitchen where decisions get made about what goes on the plate, and the pantry where ingredients are stored. Every restaurant has all three. What differs is how they’re arranged.

That arrangement is your architecture. Are all three under one roof, sharing one entrance and one staff? Or are there several small kitchens, each cooking one dish, each able to close for renovation without shutting the whole place? Or do you have no kitchen at all — you call in a chef only when an order arrives, and pay them by the dish?

Those three arrangements are the monolith, microservices, and serverless. The layers don’t change. The packaging does—and the packaging determines cost, speed, and how many people you need to keep it running.

The Three Patterns, in Plain English

Monolithic: One Application, One Deployment

A monolith is one codebase deployed as a single unit. All three layers live together. When a developer changes the invoicing logic, they deploy the whole application — including the parts they didn’t touch.

This sounds primitive. It isn’t. For most first builds, it’s the correct choice, and the reasons are practical rather than nostalgic.

Everything is in one place so that a new developer can read the whole system in a week. Testing is straightforward — you run the application, and it behaves the way it will in production. There’s one thing to deploy, one set of logs to read, one database to back up. When something breaks, the search space is small.

The trade-off shows up later, as friction between people rather than a technical failure. When four teams share one codebase, they start queuing behind each other to deploy. One team’s bug blocks another team’s release. And because everything scales together, a single heavy feature — a report that chews through the database, say — forces you to scale the entire application to keep it responsive.

The signal that you’ve outgrown a monolith is organizational: your engineers spend more time coordinating releases than writing code.

There’s also a middle option worth naming, because it rarely comes up in vendor conversations. A modular monolith keeps everything in one deployable application, but enforces strict internal boundaries — billing code can’t reach directly into user records; it has to go through a defined interface, the way it would if the two were separate services. You get the simplicity of one deployment and one database, while drawing the lines you’d split along later. If you take one technical instruction from this article into your next planning conversation, make it this one: ask whether your monolith is modular. It costs almost nothing to build this way at the start and saves months if you ever need to break the system apart.

Microservices: Independent Services, Independent Scaling

Microservices split the application into separate services, each owning one business capability and its own data. Authentication is one service. Billing is another. Notifications is a third. Each is deployed on its own schedule, scaled on its own, and can even be written in a different language.

The appeal is real—the billing team ships without waiting for the notifications team. If document processing is your bottleneck, you scale that service alone and leave the rest at baseline. If one service fails, the others can often keep running in a degraded state rather than taking the whole product down.

What’s less often said is what the pattern demands in return. Those services have to find each other, which means service discovery. A single user action now touches five services. So a request that fails somewhere in that chain has to be traceable—which means distributed tracing and centralized logging, because reading five sets of logs by hand is not a debugging strategy. Data that used to sit in one database is now spread across several, and keeping it consistent becomes an engineering problem you didn’t previously have.

In practice, this adds up to a dedicated operations capability. Most companies that adopt microservices before they have that capability spend the following year building it, rather than building product.

The honest summary: microservices solve a problem caused by having many engineers. If you don’t have many engineers, you don’t have the problem yet.

Serverless: Pay-Per-Execution, No Servers to Manage

With serverless, you write individual functions and the cloud provider runs them on demand—no servers to provision, patch, or scale. When nothing is happening, nothing runs, and you pay nothing.

For the right traffic shape, this is genuinely transformative. An application that’s busy for three hours a day and idle for twenty-one costs a fraction of an always-on server—a seasonal business with a hundredfold spike in December scales automatically without anyone touching a configuration file. Small teams can ship without hiring anyone to manage infrastructure.

The constraints are equally real. A function that hasn’t run recently has to start up cold, and that delay shows up for users on the first request. Long-running jobs hit execution time limits. Debugging is harder because there’s no persistent environment to inspect. And your code ends up shaped around one provider’s specific services, which makes moving later a rewrite rather than a migration.

Then there’s cost. Pay-per-execution is cheap when execution is intermittent. At sustained high volume, the arithmetic reverses — a steady, predictable load is usually cheaper on a server you rent by the month than on functions you pay for by the invocation. The crossover point depends on your workload, so model it against your actual traffic before committing.

Head-to-Head: How the Three Compare

Speed to first launch	Fastest	Slowest	Fast
Cost at low traffic	Low	High (fixed overhead)	Lowest
Cost at sustained high traffic	Moderate	Moderate, predictable	High
Team size that fits	1–15 engineers	20+, split into teams	1–10 engineers
Scaling	All-or-nothing	Per service	Automatic
Operational complexity	Low	High	Low, but opaque
Debugging	Straightforward	Requires tracing tooling	Hardest
Cost of changing later	Moderate — can be split incrementally	High	High — provider lock-in

​Read the bottom row carefully. It’s the one most often ignored during the initial decision, and it’s the one that hurts most in year two. A monolith can be broken apart gradually, one piece at a time, while it keeps serving customers. Reversing out of microservices or off a serverless platform is a much larger project.

That asymmetry is an argument for starting simple. The cheap direction of travel runs from simple to complex, not the other way around.

Three Scenarios, Three Different Answers

Abstractions only get you so far. Here’s how the same decision resolves differently depending on the business behind it.

A B2B SaaS product with six engineers and 300 customers. Traffic is predictable, concentrated in working hours, and the product roadmap changes every quarter as customers ask for things. A monolith — modular, single database, one deployment pipeline — is the clear answer. Splitting into services here would mean six people maintaining infrastructure for a coordination problem that doesn’t exist. Revisit at around twenty engineers.

An events and ticketing platform with four engineers. Traffic is close to zero most of the week, then multiplies by several hundred for the twenty minutes after tickets go on sale. This is the shape serverless was designed for. Provisioning servers for the peak means paying for idle capacity all week; provisioning for the average means falling over at exactly the moment that matters. The trade-off — cold starts, provider lock-in — is worth accepting for a workload this spiky.

A logistics company with forty engineers across five teams. Route optimization is computationally heavy and needs far more resources than anything else in the system. Customer data for European clients must stay in the EU. Five teams are queuing behind each other to deploy. All three signals point the same way, and this is a genuine microservices case — not because the company is large, but because it has the coordination problem, the uneven scaling problem, and the data-residency constraint at the same time.

Notice that team size alone didn’t decide any of the three. Team size combined with traffic shape and constraints did, which is why the six questions below matter more than any single rule of thumb.

The Hidden Costs Nobody Quotes You

Every proposal you receive will estimate the build. Very few will estimate what the architecture costs to own. Four line items go missing most often.

The operations hire. Microservices in production need someone who owns deployment pipelines, monitoring, and incident response. On a small team, that responsibility lands on your best backend developer, who then stops writing features. The cost isn’t just the salary — it’s the output you lose when the engineer is doing infrastructure work instead.

The observability bill. Distributed systems need centralized logging, metrics, and tracing to be debuggable. These tools are priced by data volume, and data volume grows with traffic. It’s a real monthly line item, and it’s rarely in the original budget.

The debugging tax. In a monolith, a bug reproduces on a developer’s laptop. In a distributed system, reproducing it may require running several services together and reconstructing what happened across them. The same defect takes measurably longer to resolve — and that difference compounds across every bug for the life of the product.

The reversal. If the pattern turns out to be wrong, changing it is a multi-month engineering project during which very little new functionality ships. This is the cost that ends the most roadmaps.

A pattern worth recognizing: a team of eight engineers splits a working product into a dozen services because it seems like the professional thing to do. Nothing is technically wrong with the result. But eight people are now maintaining twelve deployment pipelines, and the tracing setup needed to debug a checkout failure takes months to get right. Feature delivery slows for roughly a year — not because anyone made a mistake, but because the operational surface area outgrew the team. ⚠ [VERIFY: if a specific client project is cited here, confirm the details and permission to reference it; otherwise keep this as an unnamed illustrative pattern.]

This is why the architecture conversation belongs at the start of a project, not midway through. Serious web app development work settles the pattern before the first sprint, because it’s assumed in every technical decision that follows — and unpicking that assumption later is what turns a feature release into a rebuild.

How to Choose: Six Questions to Answer First

Skip the trend pieces. Answer these instead.

1. How many engineers do you have?

Fewer than fifteen, working as one team? A monolith. More than twenty, split into teams that each own a domain? Microservices start to earn their overhead. Microservices solve a coordination problem — if you don’t have one, you’re buying a cure for a disease you don’t have.

2. Is your traffic steady or spiky?

Predictable daily load? Servers you rent are cheaper. Traffic that’s flat for weeks and then multiplies for a day? Serverless handles it without capacity planning. Look at your last twelve months of traffic, not your best month.

3. Is the product’s scope still changing?

Still discovering what users need? A monolith lets you restructure quickly, because everything is in one place. Requirements settled and stable? Splitting into services is safer. Service boundaries drawn around a product you don’t understand yet are boundaries you’ll redraw.

4. What compliance or data-residency rules apply?

If certain data must be isolated, encrypted separately, or stored in a specific jurisdiction, that requirement may force a split regardless of team size. Compliance is the one factor that can override the team-size answer — settle it before anything else.

5. How fast do you need to launch?

Under six months to a working product? Monolith or serverless. A distributed system needs infrastructure built before the first feature ships. Time-to-market is usually the most expensive constraint in the list.

6. Who maintains this in year three?

Will you still have specialists on staff, or will this be handed to a smaller team, or to an external partner? Optimize for the team you’ll realistically have then, not the one you have during the launch push.

If the answers point in different directions, weight questions 1 and 5 most heavily. Team capacity and launch deadline break more projects than technical elegance saves.

When to Change Architecture — and When to Leave It Alone

Three signals justify re-architecting.

Your teams are blocking each other — deploys queue, releases wait on unrelated work, and coordination consumes more time than building. That’s a genuine microservices problem.

One component needs dramatically more resources than the rest, and you’re scaling the whole application to feed it. Splitting that one component out is a targeted, contained fix.

A compliance requirement demands data isolation you can’t achieve within a single system. That’s not a preference; it’s a constraint.

Notice what isn’t on the list: an unfashionable architecture, a new engineer preferring a different pattern, or a competitor’s engineering blog. Working software that ships features on schedule doesn’t need rescuing.

When you do migrate, don’t rewrite. The strangler-fig approach — named after the vine that grows around a tree and gradually replaces it — extracts one capability at a time into its own service while the original system keeps running. Route traffic to the new service, verify it, move on to the next. The system stays live throughout, and you can stop partway if the benefit doesn’t materialize. Big-bang rewrites, by contrast, run for months with nothing shipping and an ever-present temptation to abandon them halfway.

Most teams that re-architect early wish they’d waited. Very few that waited wish they’d rushed.

Practical Takeaway

Before your next planning cycle, do one thing: write down your current engineer count and your traffic pattern over the last twelve months, then run both through the six questions above.

Most teams find the answer is less exciting than they expected — usually “keep the monolith, tidy the internal boundaries.” That’s not a failure to modernize. It’s the pattern that lets a small team ship, and shipping is the only architecture decision your customers ever notice.

Revisit the answers when your team size changes materially or your traffic shape shifts. Until then, build features.

FAQ

Can we start with a monolith and move to microservices later?

Yes, and it’s the recommended path. Keep the monolith modular — clear internal boundaries between capabilities — and those boundaries become natural seams to split along later.

Is serverless actually cheaper?

For intermittent or spiky workloads, usually yes. For steady high-volume traffic, usually no. Model it against your real traffic pattern rather than accepting the headline claim.

How long does re-architecting take?

For a mid-sized application, plan in quarters, not sprints. Incremental extraction spreads the cost and keeps the product shipping; a full rewrite concentrates it and usually overruns.

Which pattern needs the biggest team?

Microservices, by a clear margin — because of operations, not development. The application code isn’t much larger; the infrastructure around it is.