Monolith vs Microservices: Complete Guide for Indonesian CTOs

Every year, thousands of development teams in Indonesia face the same question: should we stick with our working monolith, or migrate to microservices that everyone is talking about?

The answer isn't black and white. This decision impacts development speed, infrastructure costs, team structure, and operational complexity for years to come.

This article provides a complete framework for deciding the right architecture for your business, with real data, cost calculations, and decision matrices you can apply immediately.

What Is Monolith Architecture?

A monolith is an application built as a single cohesive unit. All components—UI, business logic, database access, background jobs—run in one codebase and are deployed as one unit.

Monolith Characteristics:

• Single codebase for entire application
• Shared database for all modules
• All-or-nothing deployment (one deployment for all features)
• Tight coupling between components

Technology Examples:

• Ruby on Rails application
• Django/Flask monolith
• Laravel PHP application
• Express.js monolith

When Monoliths Work:

Monoliths aren't legacy architecture to be avoided. Many Indonesian unicorns like Tokopedia and Gojek started with monoliths and still use them for certain parts today.

Monoliths are excellent for:

• Early-stage startups: Need fast MVP, quick iteration
• Small teams: <10 developers who need simplicity
• Bounded domain: Applications with clear scope that won't scale extremely
• Tight integration: Features requiring consistent transactions

What Is Microservices Architecture?

Microservices break applications into small independent services. Each service focuses on one business capability, has its own database, and can be deployed independently.

Microservices Characteristics:

• Multiple codebases (one per service)
• Database per service (data decentralization)
• Independent deployment
• Loose coupling via APIs/message queues

Example Breakdown:

E-commerce with microservices:

• User Service: Authentication, profile management
• Product Service: Catalog, inventory
• Order Service: Cart, checkout, order tracking
• Payment Service: Payment processing, refunds
• Notification Service: Email, SMS, push notifications

Each service has its own team, codebase, database, and deployment schedule.

When Microservices Work:

Microservices aren't a silver bullet. There's significant cost in complexity, infrastructure, and team coordination.

Microservices make sense for:

• Large teams: >20 developers who need to work in parallel
• High scale requirements: Certain parts need independent scaling
• Multiple domains: Distinct and complex business logic
• Polyglot needs: Different tech stacks for different services

Head-to-Head Comparison

1. Development Speed

Monolith - Winner for Early Stage:

• • Project setup: 1-2 days
• • Add new feature: 1-3 days (directly edit, test, deploy)
• • Refactoring: Easy, full IDE support
• × Bottleneck when team >10 developers

Microservices - Winner for Scale:

• × Project setup: 2-4 weeks (infrastructure, service mesh, monitoring)
• • Add new feature: 2-5 days per service (but parallel)
• × Refactoring: Complex (breaking changes affect multiple services)
• • No bottleneck, teams work independently

Verdict: Monolith wins for first 0-2 years. Microservices win after scale and team size increase.

2. Infrastructure Cost

Monolith Cost (1 year):

• Server: $1,300/year (single instance + backup)
• Database: $1,000/year (managed PostgreSQL)
• Load balancer: $300/year
• Monitoring: $200/year
• Total: $2,800/year

Microservices Cost (1 year, 5 services):

• Servers: $3,900/year (12 instances, HA per service)
• Databases: $3,200/year (5 databases)
• API Gateway: $800/year
• Service mesh: $1,000/year (Istio/Linkerd)
• Message queue: $650/year (RabbitMQ/Kafka)
• Monitoring: $1,200/year (distributed tracing, log aggregation)
• Total: $10,750/year

Cost multiplier: 3.8x

Verdict: Monolith is far cheaper. Microservices cost is justified only if scale benefits outweigh the cost.

3. Deployment & Rollback

Monolith:

• • Simple deploy process (single pipeline)
• • Easy rollback (revert to previous version)
• × Downtime required (or blue-green deployment)
• × One bug affects entire app

Microservices:

• • Zero-downtime deployment per service
• • Bug isolated to one service
• × Complex orchestration (Kubernetes, service dependencies)
• × Risky rollback (version compatibility across services)

Verdict: Depends on use case. Microservices better for high-availability requirements.

4. Testing & Quality Assurance

Monolith:

• • Straightforward unit testing
• • Integration testing in one codebase
• • Simple E2E testing (single application)
• × Slow test suite as codebase grows

Microservices:

• • Fast, isolated unit testing per service
• × Complex integration testing (mock external services)
• × E2E testing nightmare (coordinating 5+ services)
• × Contract testing required between services

Real Example:

Testing checkout flow:

• Monolith: 1 test suite, 50 test cases, runs in 5 minutes
• Microservices: 5 test suites, 150 test cases (overlap), mock 4 external services, runs in 15 minutes

Verdict: Monolith easier to test for small-medium apps. Microservices require significant testing infrastructure investment.

5. Team Structure & Conway's Law

Monolith Team:

• Structure: Feature teams (horizontal)
• Communication: Daily standup, shared codebase
• Onboarding: 2-4 weeks (learn entire codebase)
• Best size: 5-15 developers

Microservices Team:

• Structure: Service teams (vertical, full-stack per service)
• Communication: API contracts, async
• Onboarding: 1-2 weeks (learn one service)
• Scales to: 50+ developers

Conway's Law:

"Organizations design systems that mirror their communication structure."

If team structure doesn't match architecture, there will be friction.

Example Mismatch:

× Bad: Microservices with centralized ops team

• Deployment bottleneck
• Slow iteration
• Defeats the purpose

• Good: Microservices with autonomous teams

• Each team owns service end-to-end
• Fast deployment
• True independence

6. Scalability

Monolith Scaling:

• Vertical: Add CPU/RAM (limited by single machine)
• Horizontal: Clone entire app (wasteful)
• Cost per 100K users: $1,000/month

Example:

E-commerce monolith:

• Product catalog: 10% CPU
• Search: 60% CPU (bottleneck)
• Checkout: 20% CPU
• Admin: 10% CPU

Scale entire app to handle search load → 70% wasted capacity.

Microservices Scaling:

• Selective: Scale only bottleneck services
• Independent: Different services, different resources
• Cost per 100K users: $1,200/month (but optimal allocation)

Example:

E-commerce microservices:

• Product service: 2 instances
• Search service: 10 instances (bottleneck)
• Checkout service: 3 instances
• Admin service: 1 instance

Scale only what's needed → optimal resource usage.

Verdict: Microservices win for selective scaling needs. Monolith OK if load distribution is even.

7. Technology Flexibility

Monolith:

• × Stuck with one tech stack
• × Risky upgrade (all-or-nothing)
• • Easy consistency (same language, framework, libs)

Microservices:

• • Polyglot: Python ML service + Go API service + Node.js real-time service
• • Incremental upgrade (migrate one service at a time)
• × Consistency nightmare (10 different logging libraries)

Real Scenario:

Startup with Ruby on Rails monolith:

• Need ML recommendation engine
• Monolith: Build Ruby wrapper around Python (awkward)
• Microservices: Standalone Python ML service (clean)

Verdict: Microservices better for heterogeneous requirements. Monolith better for consistency.

8. Operational Complexity

Monolith Operations:

• Monitoring: 1 application, simple APM
• Debugging: Complete stack trace
• Logs: Single log stream
• Ops team size: 1-2 engineers

Microservices Operations:

• Monitoring: Distributed tracing (Jaeger, Zipkin)
• Debugging: Correlation IDs across 5+ services
• Logs: Log aggregation (ELK stack)
• Ops team size: 3-5 engineers (SRE)

Failure Scenarios:

Monolith:

• Service down → entire app down
• Recovery: Restart, fast

Microservices:

• One service down → partial degradation
• Cascade failure risk (service A → B → C)
• Recovery: Complex (which service? dependency health?)

Verdict: Monolith drastically simpler operationally. Microservices require high DevOps maturity.

Decision Matrix

Scoring:

Calculate score for each architecture:

• Monolith: +1 if criteria matches
• Microservices: +1 if criteria matches
• Multiply by weight (High=3, Medium=2, Low=1)

Example:

Fintech startup, 8 developers, budget $5K/year:

• Team size: Monolith (+3)
• Dev speed: Monolith (+3)
• Budget: Monolith (+3)
• Scale: Monolith (+2)
• Domain: Monolith (+2)
• DevOps: Monolith (+3)
• Tech: Tie (0)

Total: Monolith 16, Microservices 0 → Clear monolith

Hypothetical Scenarios: 3 Businesses, 3 Decisions

Scenario 1: E-learning Startup (6 Months, 3 Developers)

Context:

• MVP e-learning platform for SMEs
• Development budget: $13K
• Target: Launch in 3 months, 10K users first year
• Team: 3 full-stack developers

Decision: Monolith

Why:

• Speed to market critical
• Small team, coordination overhead kills productivity
• 10K users don't need microservices complexity
• Limited infrastructure budget

Tech Stack:

• Next.js monolith (API routes + frontend)
• PostgreSQL database
• Vercel hosting ($130/month)

Result: Launched on time, scaled to 50K users still OK with monolith.

Scenario 2: Logistics Platform (2 Years, 25 Developers)

Context:

• Real-time tracking for 5,000 vehicles
• Multiple modules: dispatch, route optimization, payment, driver app
• 3 teams: Backend (10), Mobile (10), Data (5)
• Current: Rails monolith, slow deployment, blocking

Decision: Gradual Migration to Microservices

Why:

• Team size causing merge conflicts
• Route optimization CPU-intensive, needs separate scaling
• Mobile apps need stable API contracts
• Mature DevOps team (Kubernetes ready)

Migration Strategy:

• Year 1: Extract route optimization service (Python, CPU-bound)
• Year 2: Extract payment service (compliance isolation)
• Year 3: Extract notification service (high throughput)
• Core: Keep monolith for business logic

Result: Best of both worlds—complexity only where needed.

Scenario 3: B2B SaaS (500 Tenants, Compliance Requirements)

Context:

• Multi-tenant SaaS for enterprise
• Compliance: ISO 27001, data residency requirements
• Some tenants in Indonesia, some Singapore
• Team: 40 developers across 5 feature teams

Decision: Microservices with Tenant Isolation

Why:

• Data residency → per-tenant deployment
• Easier compliance audit with service boundaries
• Feature teams want autonomy
• Scale per tenant varies wildly (10 users vs 10K users)

Architecture:

• Shared services: Auth, billing, notification
• Tenant services: Application logic (per region)
• Infrastructure: Kubernetes multi-cluster (Jakarta + Singapore)

Result: Compliance met, flexible scale, autonomous teams.

Indonesia Market Context

Budget Reality

According to survey of 100+ Indonesian tech companies (2025):

• Startup (<50 employees): $3K-13K/year infrastructure
• Scale-up (50-200): $13K-32K/year
• Enterprise (>200): $32K-130K/year

Microservices investment realistic only for scale-ups and enterprises.

Talent Availability

Monolith expertise (abundant):

• Laravel, Rails, Django, Express.js: Plentiful
• Hiring mid-level: $800-1,300/month

Microservices expertise (limited):

• Kubernetes, service mesh, distributed systems: Rare
• Hiring senior (required): $1,600-2,600/month
• Training cost: $3K-6.5K per team

Implication: Microservices require higher budget for talent.

Regulatory Considerations

PP 71/2019 - Data Localization:

Certain sectors must store data in Indonesia:

• Financial services
• E-commerce >$6.5M revenue/year
• Healthcare

Architecture Impact:

Monolith:

• Deploy single instance in Indonesian data center
• Simple compliance

Microservices:

• Service mesh across regions
• Data residency per service
• Complex compliance audit

Recommendation: If data residency required, design for multi-region from start.

Cloud Provider Landscape

Indonesian Market (2026):

• AWS Jakarta (ap-southeast-3): Full services
• Google Cloud Jakarta: Growing
• Local providers: Biznet Gio, CBN

Cost comparison (per month):

• AWS Jakarta: 15-20% more expensive than Singapore
• GCP Jakarta: 10-15% more expensive
• Local: 20-30% cheaper (but limited services)

Microservices implication:

5 services × $650 = $3,250/month vs $1,000 monolith.

Decision: Factor in Indonesia premium when calculating ROI.

When to Migrate from Monolith to Microservices?

Red Flags (Time to Consider Migration):

1. Deployment bottleneck: Deploys went from weekly to monthly due to risk

2. Team blocking: Daily merge conflicts, velocity down 50%

3. Scaling pain: Must scale entire app for 1 bottleneck feature

4. Onboarding >2 months: New developers need >8 weeks to be productive

5. Service outages: 1 bug brings down entire app

Not Red Flags (Stay with Monolith):

• Revenue <$65K/month
• Team <20 developers
• Infrastructure budget <$6.5K/year
• Deployment still smooth (1-2x per week)
• Codebase still manageable

Migration Cost (Real Numbers):

SaaS startup with Rails monolith (50K lines):

• Timeline: 12-18 months (gradual)
• Cost: $52K-78K (development + infrastructure + training)
• Productivity drop: 30-40% during migration
• Break-even: 18-24 months after migration

ROI Calculation:

Before (Monolith Pain):

• Deployment: 1x per 2 weeks (slow releases)
• Downtime: 4 hours/month (revenue loss: $3,200/month)
• Developer velocity: -40% (blocking, merge conflicts)

After (Microservices):

• Deployment: 2-3x per week per service
• Downtime: 30 minutes/month (partial degradation)
• Developer velocity: +60% (autonomous teams)

Net benefit: $10K/month improvement in velocity + uptime.

Payback period: 8 months ($78K cost / $10K benefit).

Common Mistakes to Avoid

Mistake 1: Premature Microservices

Scenario: Startup with 4 developers builds microservices from day 1.

Result:

• 6 months for MVP (should be 2 months)
• Infrastructure cost 4x budget
• Burnout from operational complexity

Fix: Start monolith. Extract services only when pain is clear.

Mistake 2: Wrong Service Boundaries

Scenario: Split based on technical layer, not business domain.

Bad Split:

• API Gateway Service
• Business Logic Service
• Database Service

Good Split:

• User Service (manage users end-to-end)
• Product Service (manage products end-to-end)
• Order Service (manage orders end-to-end)

Fix: Service boundaries = business domains. Each service can stand alone.

Mistake 3: Shared Database

Scenario: Microservices share one database.

Result: Tight coupling still exists. Defeats microservices purpose.

Fix: Database per service. Communicate via APIs, not direct DB access.

Mistake 4: No API Versioning

Scenario: Service A updates API, Service B breaks.

Result: Cascade failures, deployment coordination nightmare.

Fix: API versioning from day 1. Backward compatibility mandatory.

Mistake 5: Distributed Monolith

Scenario: Tightly coupled microservices. Every request touches 5+ services.

Result: Monolith complexity + microservices cost = worst of both.

Fix: Loose coupling. Services independent 80%+ of the time.

Conclusion

Monolith vs Microservices isn't a choice between "old" vs "new", but between simplicity vs flexibility.

Choose Monolith if:

• Team <20 developers
• Early-stage product (MVP - product-market fit)
• Infrastructure budget <$6.5K/year
• Moderate domain complexity

Choose Microservices if:

• Team >30 developers in multiple teams
• Proven product with clear scale needs
• Infrastructure budget >$10K/year
• High DevOps maturity (CI/CD, Kubernetes, monitoring)

Best Practice:

1. Start monolith: 95% of startups should start with monolith

2. Monitor pain points: Track deployment frequency, merge conflicts, scaling bottlenecks

3. Gradual migration: Extract 1 service at a time when pain is clear

4. Keep core monolith: Many parts don't need to be microservices

Remember: Architecture isn't a permanent decision. Evolve according to growth and team maturity.

At Zeppelin Works, we help Indonesian businesses choose and implement the right architecture—not what's trendy, but what solves actual problems. Want to discuss architecture for your product? Contact us for a free consultation, no sales pitch.