Microservices vs Monolithic Architecture

The Architecture Question, Answered Honestly

Should you build one application or many small services?

The internet will tell you microservices are modern and monoliths are legacy. That framing has cost a lot of companies a lot of money, because the honest answer for most Malaysian SMEs is: start with a monolith, and you may never need anything else.

Here's the reasoning.

What Each Term Means

A monolith is one application, one deployment, usually one database. All the code lives together and calls itself directly.

Microservices split the system into independent services, each with its own deployment and typically its own data. They communicate over the network.

Crucially: monolith doesn't mean badly organised. A well-structured monolith has clear internal boundaries between modules. It simply keeps them in one deployable unit.

Why Microservices Are So Appealing

The pitch is genuinely attractive:

• Teams work independently without stepping on each other
• Scale only the parts under load
• One service failing doesn't take everything down
• Use the right technology for each job
• Deploy small pieces frequently and safely

All true — at sufficient scale, with sufficient engineering maturity.

What the Pitch Leaves Out

Every one of those benefits arrives with a cost.

The network is now part of your application. A function call that couldn't fail becomes a network call that can time out, retry, arrive twice, or arrive out of order. Every service boundary is a new class of failure.

Data becomes hard. Updating a customer and their order inside one database is a transaction. Across two services it's a distributed problem requiring compensating logic. This is where most microservice projects at SME scale run into serious trouble.

Debugging spans machines. One user action touches six services. Finding which one broke requires distributed tracing and centralised logging, which are infrastructure projects in their own right.

Operations multiply. Twelve services means twelve deployment pipelines, twelve monitoring configurations, twelve sets of credentials.

Local development gets slow. A developer needs the whole system running to work on one part. Teams end up building tooling just to start the application.

What It Costs at SME Scale

For a Malaysian SME with three to six developers:

Well-structured monolith

• Infrastructure: RM200 - RM1,200 per month
• Deployment: one pipeline
• Debugging: read one log
• Time to onboard a developer: 1-2 weeks
• Operational overhead: minimal

Microservices (eight to twelve services)

• Infrastructure: RM1,500 - RM6,000 per month
• Deployment: a pipeline per service, plus orchestration
• Debugging: requires tracing and log aggregation to be built first
• Time to onboard a developer: 4-8 weeks
• Operational overhead: often close to a full-time role

The rough rule: microservices add 30-50% to development cost and multiply infrastructure spend, in exchange for benefits that only materialise above a certain team size.

When Microservices Genuinely Make Sense

They're the right answer when:

You have enough people. The original argument for microservices is organisational — letting many teams deploy independently. With fewer than about twenty engineers, you don't have that problem. You're paying the cost of a solution to a problem you don't have.

Parts of the system have very different scaling profiles. If image processing needs ten machines and everything else needs one, separating it's rational.

Genuine isolation requirements exist. Payment card handling isolated for compliance, for instance.

Different technology is genuinely needed. A machine learning component in Python alongside a business application in TypeScript.

A single component fails often and must not take the system down. A flaky third-party integration is a good candidate for isolation.

Notice that "we want to be modern" isn't on the list.

The Approach We Recommend

Build a modular monolith.

One deployment, one database, but internally organised into clear modules with defined boundaries. Orders, inventory, billing, and notifications each live in their own area, and they talk to each other through explicit internal interfaces rather than reaching into each other's data.

You get:

• Simple deployment and debugging
• Low infrastructure cost
• Fast local development
• Clear boundaries

And critically: when you genuinely do need to extract a service, the boundary already exists. Pulling the billing module out into its own service becomes a contained piece of work rather than an archaeology project.

This is the pattern several well-known companies adopted after trying microservices too early and moving back.

How to Know It's Time to Split

Extract a service when you can point at a specific problem:

• One module needs to scale independently and you can prove it with metrics
• One area changes far more often than the rest and deployments are becoming a bottleneck
• A team has grown large enough that coordination is genuinely costly
• A compliance requirement demands isolation

Extract that one piece. Not everything. Repeat only when the next specific reason appears.

Common Mistakes

Splitting by database table. A "customer service", an "order service", an "address service". These end up needing constant conversation with each other. Split by business capability, not by data structure.

Shared databases between services. If two services write to the same tables, you have a distributed monolith — all of the cost, none of the benefit.

Starting with microservices before the domain is understood. You don't yet know where the boundaries belong. You'll draw them wrong, and moving a boundary between two deployed services is far harder than moving one inside a single codebase.

Underestimating the operations work. Someone has to run all this. In a small team, that someone is a developer who is now not building features.

The Short Version

For most Malaysian SMEs, a well-structured modular monolith is the correct architecture — and it will remain correct for longer than you expect.

Microservices solve organisational problems that arrive with organisational scale. Adopt them when you have that scale and can name the specific problem you're solving. Until then, they're a cost with no matching benefit.

Planning a new system and unsure how to structure it? Talk to us — we'll give you a straight recommendation based on your team size and actual requirements, not on what's fashionable.