Serverless, monolith, or microservices: picking the right architecture

Architecture arguments tend to be religious. Someone read that microservices are how serious companies build, or that serverless is the future, or that monoliths are what grown-ups ship. None of that is an answer. The right architecture is the one that matches the shape of your workload, your team, and your budget — and for most projects that is a quieter, more boring choice than the internet suggests.

Serverless: bursty and unpredictable

Serverless functions run only when something calls them, and bill per request. That makes them an excellent fit for work that is spiky or hard to predict: a contact form, a webhook handler, an occasional report, an API that is busy for an hour and quiet for a day. You pay nothing when nothing is happening, and AWS handles the scaling when a thousand requests arrive at once. The cost follows the usage almost exactly, which is the whole appeal.

The trade is that serverless rewards small, independent units of work and punishes long, chatty operations or anything that needs a warm connection held open. Used for what it is good at, it is the cheapest way to add real logic to a site without standing up a server.

A single service: transactional integrity

When several things must happen together or not at all — money moves, inventory decrements, a record updates — a single well-built service is often the simplest correct answer. One codebase, one database, one transaction boundary. You can reason about the whole system in your head, and the database guarantees that operations either complete fully or roll back. A great deal of complexity in distributed systems exists only to recreate, painfully, what one transaction gives you for free.

Most teams do not have a scaling problem. They have a complexity problem they gave themselves.

A monolith is not a slur. For most businesses, a clean, well-organised single service will carry them far further than they expect, and it is dramatically easier to build, deploy, and debug than the alternatives.

Microservices: independent scale and ownership

Microservices earn their place when parts of a system genuinely need to scale, deploy, or fail independently — and when you have the team to own them. A video-processing pipeline that needs heavy compute should not be welded to a login service that needs almost none. Separate teams shipping on separate schedules benefit from separate services. The split is justified by real independence, not by a wish to look modern.

• Choose serverless when load is bursty and the work breaks into small, independent calls.
• Choose a single service when correctness across related operations matters more than independent scale.
• Choose microservices when parts truly differ in how they scale, deploy, or are owned — and only then.

How we actually decide

We start from your workload, not from a preference. What does traffic look like? What has to be correct under load? Who will maintain this in a year? Most projects land on a static front end with a few serverless functions behind it, because that is genuinely the cheapest and simplest thing that works. We reach for more structure only when the workload asks for it — and when we do, we can say in plain words why.