One Thursday morning, a logistics app in Surabaya suddenly started rejecting every incoming order. After two hours of investigation, the cause was found: a small update to the WhatsApp notification module had broken the payment module. The two had nothing to do with each other. The entire application went down because one component failed. The owner heard the word "microservices" for the first time that day — and wondered whether it was the answer.
"Microservices or monolith?" is one of the most consequential and most misunderstood architecture decisions in software development. On one side, many development teams in Indonesia treat microservices as a magic jargon: the more "micro," they say, the more modern. On the other side, many businesses pay dearly for complexity they never needed, simply because they were afraid of looking outdated.
This article is an honest guide to deciding: which one fits your business in Indonesia, what it costs, when the right time to switch is, and how to avoid the most common traps.
Two Philosophies of Building Software
Think of your application as a restaurant.
A monolith is a restaurant with one big kitchen. All dishes are cooked in one place, by one team, through one system. Want to add a menu item? Add it to the same kitchen. Kitchen on fire? No one eats. Simple, easy to manage, and for many restaurants, the most sensible choice.
Microservices are a food court full of small stalls, each serving one kind of food. A fried rice stall, a meatball stall, a juice stall. Each stall has its own kitchen and staff. If the meatball stall closes, diners can still eat elsewhere. But running a food court is more complicated: you manage leases, shared-area cleanliness, and coordinating many stalls at once.
Both models have their place. The problem is that many businesses build a food court when they only need one kitchen.
Monolith: One Application, One Codebase
Technically, a monolith is an application where all functions — login, payments, reports, notifications — live in a single codebase, usually deployed and run as one unit. All parts share one database and one process.
A monolith is not a bad word. In fact, for the majority of businesses just starting out, it is the smartest choice. Small teams can build it quickly, it is easy to understand, and operating costs are far lower. Problems only appear as the application grows: the code gets harder to manage, one small bug can take everything down, and teams working in a single codebase constantly collide.
Microservices: Many Small Services Talking to Each Other
Microservices split an application into small, independent services. Each service has a specific responsibility, its own database (or at least its own schema), and can be developed, deployed, and scaled separately.
Services communicate through APIs or message queues. If the payment service is busy, the other services keep running. A team owning one service can deploy a new version without waiting for other teams.
The benefits are real: per-component scaling, fault isolation, and team autonomy. The costs are just as real: far more complex infrastructure, harder cross-service debugging, and much higher initial operating costs.
Why Indonesian Businesses Should Care About Architecture
Architecture decisions are not just a technical matter. They directly affect three things that determine business survival: what it costs to build, what it costs to maintain, and how fast you can change.
Consider the Indonesian context. APJII data shows more than 200 million Indonesians are now connected to the internet, and the majority access it through mobile devices on connections that are sometimes unstable. Applications serving thousands of users at specific moments — flash sales, Lebaran, the new school year — face dramatic traffic spikes. Add the Personal Data Protection Law (UU PDP), which demands careful, documented data management.
This is why architecture becomes a business decision, not just a technical preference. The wrong architecture from day one makes you pay repeatedly: every time a new feature takes weeks because old code is tangled, every time the server goes down in the middle of a peak moment because one component failed.
Head-to-Head: Microservices vs Monolith
| Aspect | Monolith | Microservices |
|---|---|---|
| Ease of initial development | Very easy | Complex |
| Initial operating cost | Low | High |
| Scalability | Whole application | Per service |
| Fault isolation | One bug can take down everything | One service down, others keep running |
| Deployment speed | One app, all teams | Per service, per team |
| Debugging ease | High (single process) | Low (cross-service) |
| Team required | Small (2-5 people) | Larger (specialists per service) |
| Best for early-stage startups | Very much so | Usually overkill |
| Best for large platforms | Increasingly hard as it grows | Excellent fit |
The table simplifies, but it captures the essence of the difference. The key question is not "which is more modern" but "which fits your business stage and team capacity."
When Monolith Is the Right Choice
Monoliths are often looked down upon, yet they are the most sensible choice for most Indonesian businesses — especially those just starting or running small teams. Here is when a monolith is the right call:
Small team, early stage
If your team is under ten people, building microservices from the start is almost always a misstep. Microservices demand expertise in areas that even large teams struggle with: container orchestration, service discovery, cross-service observability, and distributed configuration management. All of this diverts time and energy from what should be your main focus: building features that answer customer needs.
Time to market matters
In the early stage, learning from the market is worth more than architectural elegance. A monolith can launch much faster, and feedback from real users is more valuable than beautiful code structure. Many successful Indonesian businesses — including some major marketplaces — started as monoliths and only migrated years later.
Unknown load patterns
Microservices shine when you know one part of the application will be used far more intensively than others. If you are not yet sure which part will explode, you have no reason to split yet. Premature optimization for scale that does not exist is one of the most common ways to burn a budget.
A team that is not ready
Microservices are not something you can learn on the job without risk. Managing them correctly requires real experience. A team touching containers and orchestration for the first time will make many expensive mistakes early on. Better to build a solid monolith now, while the team learns, than fragile microservices whose owners are unprepared.
When Microservices Deserve Serious Consideration
There comes a point where the monolith starts to feel crowded — and that is where microservices start making sense. Learn the signs:
Large team size
When the team passes 15-20 people and everyone works in one codebase, developer conflicts become routine. Deploys blocking each other, features stalling because they collide, and code that grows harder to understand are symptoms of an overcrowded monolith. Microservices let each team move independently.
Very uneven load
If 90 percent of traffic hits one module while others are rarely used, a monolith forces you to scale everything to handle one part. Microservices let you scale only the busy part. This matters for platforms with extreme seasonal traffic.
Different deployment policies per part
Some parts of an application need to ship faster than others. A marketing module may need daily updates, while a finance module should only change once a month with strict audits. Forcing both into one deployment cycle is a constant source of friction.
Genuinely different technology needs
Sometimes one part of the application is far better built with different technology than the rest. Microservices make that possible. But an honest note: this is the most abused reason of all. "Our team wants to use a new language" is not an architecture reason.
Case Scenario: An FMCG Distributor
To keep this decision concrete, follow two scenarios of the same business at different points.
An FMCG distributor in Bandar Lampung starts with an internal sales application: order entry, stock checks, and daily reports for 30 salespeople. Its team has three developers. A monolith is the obvious choice. The application is finished in three months, monthly operating costs stay under Rp 2 million, and the team adds features as needed.
Two years later, the distributor starts selling online to end customers. Traffic spikes on promo days, and the payment and notification modules face very different pressures. The team has grown to 12 people. Now architecture decisions start being reconsidered — and splitting into microservices begins to make sense: the catalog and payment modules are separated and scaled independently, while the rarely-changing internal module stays in the monolith.
The key point: splitting did not happen at the start. It happened when there was real evidence that the monolith was getting crowded. No one wasted time on premature migration, and no one delayed until the system truly jammed.
Cost Estimates: Monolith vs Microservices
Cost is one factor that makes businesses flinch the most. Here is a realistic comparison for the Indonesian market in 2026:
Development cost
A monolith generally costs 30-60 percent less to build than microservices with the same functionality. The reason is simple: less complexity, less infrastructure, smaller teams. For internal applications or early-stage platforms, the difference can mean tens to hundreds of millions of rupiah.
Monthly operating cost
Microservices require more infrastructure: multiple containers or virtual machines, a service mesh or API gateway, centralized logging, and more sophisticated monitoring. A monolith serving 500 internal users can run on Rp 2-5 million per month. Microservices with similar load can cost three to five times more, because you pay for separation and redundancy.
Team cost
This is the most often forgotten component. Microservices demand rare, expensive skills in Indonesia: Kubernetes, observability, distributed architecture. Developers with these skills command much higher compensation. For a small team, the payroll difference can exceed the entire infrastructure cost.
Migration cost
If you decide to move from monolith to microservices later, budget for a significant migration effort. A full migration of a multi-module application can take 6-18 months and cost hundreds of millions of rupiah, depending on complexity. This is not a reason to never migrate — it is a reason to migrate for the right reasons, not for trends.
| Item | Monolith | Microservices |
|---|---|---|
| Medium application development | Rp 150-400 million | Rp 300-700 million |
| Monthly operations (500 users) | Rp 2-5 million | Rp 8-25 million |
| Team required | 3-5 people | 8-15 people |
| Migration from monolith (if any) | Not applicable | Rp 100-500 million |
These are general estimates, not package prices. Every project is different, and the best way to know the cost is to discuss your specific needs.
How to Move from Monolith to Microservices
If you have decided microservices are the right step, never do it as a "big bang rewrite" — starting from scratch and throwing everything away. This is the most expensive mistake in software engineering history. The right approach is incremental, often called the strangler fig pattern.
1. Identify service boundaries
Determine which parts of the application are truly worth separating. Prioritize by three criteria: load (which parts are busiest), change frequency (which parts change most often), and dependency (which parts depend least on others). Start with the most obvious.
2. Extract one at a time
Take one module, extract it into a standalone service, and reconnect it through an API. The rest of the application keeps running as usual. Never try to split everything at once. Each successful extraction builds confidence and team experience.
3. Prepare supporting infrastructure
Before splitting, make sure the foundations exist: solid CI/CD, centralized logging, monitoring, and a way to debug across services. Without these, microservices are an operational nightmare. This is a non-negotiable prerequisite.
4. Measure, don't assume
After each extraction, measure the impact: latency, operating cost, deployment speed. If a split does not deliver measurable benefit, stop and evaluate. Microservices are not the goal; they are a tool.
Common Traps
Premature microservices
This is the most common and most expensive trap. Teams build microservices from day one to look "modern," when the business is young and the team small. The result: development time doubles, costs balloon, and features that should ship in three months arrive after nine. If you are not sure you need microservices, you almost certainly do not need them yet.
The distributed monolith
Ironically, many teams that "move to microservices" actually build a distributed monolith: services that are technically separate but logically tightly coupled. One small change forces changes across many other services. This is the worst of both worlds: microservices complexity without the benefits. The telltale sign is cross-service deploys that must always happen together.
Underestimated network overhead
Microservices move calls that used to be internal (fast, in one process) onto the network (slow, failure-prone). Latency, timeouts, and partial failures become daily reality. Teams unused to handling this will end up with an application that feels slow and hard to debug.
Data consistency
In a monolith, one transaction can atomically update many tables. In microservices, each service owns its data, and cross-service transactions become much harder. Patterns like event sourcing and sagas replace simple transactions. This is not a small technical detail; it changes how the team thinks about data integrity.
How to Decide Well
If you are still unsure, use this simple decision framework:
- How big is your team? Under 10 people with no fast growth plans? Monolith. Over 15-20 with many specialists? Microservices start making sense.
- How uneven is your load? Modules used relatively evenly? Monolith is enough. One dominant, extreme module? Consider splitting just that module.
- How much does time to market matter? Critically? Monolith. Can you invest more development time for long-term gains? Consider microservices.
- Is your team ready? Real experience with distributed architecture? Then consider it. Not yet? Start with a monolith while the team learns.
- What budget do you have? Microservices are not a cost-saving decision early on. With limited budget, a monolith is almost always the answer.
Most importantly: this decision is not permanent. Many large companies started as monoliths, moved to microservices at some point, and some even moved back (or to something in between, called a modular monolith) after learning from experience. Architecture is a revisable choice, not a life sentence.
The Role of Consultants and Development Partners
A wrong architecture decision can cost hundreds of millions of rupiah, while the right one can save budget and accelerate growth. This is why involving people experienced in architecture — not just people who can code — is a sensible investment.
Architecture discussions also cannot be separated from broader infrastructure decisions. Read our cloud migration guide to understand how architecture choices relate to where your application runs. For businesses designing new systems, our custom software vs off-the-shelf guide helps you decide from a different angle. And if you are unsure when to bring in experts, our IT consultant guide answers that.
Build What Fits, Not What's Trendy
Back to the logistics app in Surabaya. The problem they experienced — one small update taking down the whole application — is real. But the answer is not automatically "move to microservices." The right answer starts with diagnosis: is the problem architecture, deployment process, or weak testing? In many similar cases, the answer turns out to be better process discipline, not an architecture change.
The decision between microservices and monolith should come from questions about your business, not from industry trends. Start with the problem you want to solve, measure costs and benefits honestly, and build the way that makes the most sense for where you are now.
The Kartech. team in Bandar Lampung helps businesses choose the right architecture based on real needs, not jargon. We listen to your problem first, then recommend the structure that makes the most sense — including telling you when microservices are not needed yet. Discuss your needs through our contact page or explore our services to see how we work.
