Microservices vs Monolith: A Practical Decision Framework from a System Architect in Nepal

The microservices conversation comes up in almost every technical planning session I run as a system architect in Nepal. The developer has read the Netflix and Uber blog posts and wants to build their new booking system with 15 independent services from day one.

This guide will save you months of wasted effort. I will explain the real trade-offs, give you a decision framework, and show you the exact service boundaries I use across different product types.

→ The Real Cost of Microservices

Let me be concrete about what adopting microservices actually means for a small team:

Operational complexity that appears overnight:

• 12 services x 3 environments (dev, staging, prod) = 36 deployment targets to manage
• Service discovery: how does Service A find Service B's current address?
• Distributed tracing: when a request fails, the error could be in any of 5 services
• Each service needs its own CI/CD pipeline, container registry, and monitoring
• Schema migrations across services require careful coordination
• Local development requires running all 12 services simultaneously

The latency tax:

• A function call between classes: ~1 nanosecond
• A REST API call between services over the network: ~1-10 milliseconds
• At 1,000 requests/second with 5 inter-service calls: 5,000-50,000ms of added latency per second

For most Nepal-based products at their current scale, this overhead is pure waste with no benefit.

→ When the Monolith is the Right Answer

A well-structured monolith is not technical debt. It is the appropriate default for:

• Teams under 10 engineers
• Products with less than 100k monthly active users
• Products under 2 years old
• Teams without dedicated DevOps engineers

The monolith's advantages are real:

• Atomic transactions — booking + payment + seat reservation as one database transaction. With microservices, you need the Saga pattern (10x more code).
• Simple debugging — one log file, one stack trace
• Zero network latency between components
• Single deployment — not 12 pipelines

→ The Strangler Fig Pattern: Migrate Without Rewriting

Martin Fowler's Strangler Fig pattern describes extracting services one at a time while the monolith continues running:

Phase 1 — Status quo:
  Client → Monolith (handles everything)

Phase 2 — First extraction:
  Client → API Gateway
               ↓              ↓
          Monolith        New Service A (notifications)
          (shrinking)

Phase 3 — Second extraction:
  Client → API Gateway
               ↓        ↓        ↓
          Monolith   Service A  Service B (payments)

Existing clients see no changes — the API contract is preserved throughout migration.

→ Service Boundaries for Nepal Tech Product Types

Ride-sharing application:

Core Service (Laravel)
  — User accounts, ride history, ratings, driver profiles
  — Standard REST API, PostgreSQL

Matching Service (Node.js or Go)
  — Real-time driver-rider matching
  — Needs sub-100ms response time
  — Separate because latency requirements differ from Core

Location Service (Go)
  — Receives GPS coordinates from drivers (high write throughput)
  — Stores in Redis sorted sets for geospatial queries
  — Go chosen for lightweight goroutine concurrency

Payment Service (Laravel)
  — eSewa, Khalti, Stripe integration
  — Separate for PCI compliance isolation

Notification Service (Node.js)
  — SMS via Sparrow SMS, push via Firebase, email via SES
  — Pure event consumer — receives events, sends messages

SaaS CRM platform:

CRM Core (Laravel)
  — Contacts, leads, pipelines, tasks, deals
  — Stays as monolith longest

Identity Service
  — SSO, multi-tenant access control, JWT issuance
  — Extracted early (consumed by every other service)

Reports Service
  — Heavy analytical queries (60s+ report generation)
  — Separate so reports never impact CRM Core performance
  — Reads from dedicated read replica

Email Campaign Service
  — Bulk email sending (thousands queued)
  — Separate because failure must not affect CRM Core

→ Communication Patterns Between Services

Synchronous (REST) — when the caller needs the response to continue:

User submits booking
  → Booking Core calls Availability: "Is slot X free?"
  → Availability responds: "Yes"
  → Booking Core calls Payment: "Charge $50"
  → Payment responds: "Captured, txn: abc123"
  → Booking Core creates the booking record
  → Returns confirmation to user

Asynchronous (Events/Queue) — when eventual consistency is acceptable:

Booking confirmed (Booking Core publishes event)
  → Notification Service: sends confirmation email
  → Analytics Service: increments booking counter
  → Loyalty Service: awards loyalty points
  → Calendar Service: blocks slot in external calendars

In Laravel, async communication uses queues:

// Publish event after successful booking
event(new BookingConfirmed($booking));

// Dispatch to queue for async processing
dispatch(new SendBookingConfirmationJob($booking))
    ->onQueue('notifications')
    ->delay(now()->addSeconds(5));

→ The Saga Pattern: Distributed Transactions

With a monolith, booking creation is trivial:

// Atomic — all or nothing
DB::transaction(function () use ($slot, $payment, $booking) {
    $slot->update(['is_available' => false]);
    $payment->update(['status' => 'captured']);
    $booking->update(['status' => 'confirmed']);
    // If ANY step fails, ALL roll back automatically
});

With microservices, each service has its own database. The Saga pattern handles this with compensating transactions:

Booking Saga:
1. Booking Service: create booking (status: PENDING)
2. Availability Service: reserve slot
   FAIL → Booking Service: cancel booking (compensating transaction)
3. Payment Service: charge customer
   FAIL → Availability: release slot
        → Booking: cancel booking
4. Booking Service: confirm booking (status: CONFIRMED)
5. Notification Service: send confirmation (async)

This is correct but 10x more code than the monolith version. Do not add this complexity without a specific reason.

→ Decision Checklist

Score one point for each "Yes":

• Does this component have significantly different scaling requirements from the rest?
• Does it need to be deployed independently without affecting other components?
• Is it worked on by a separate team that regularly conflicts with others?
• Does it need different technology (Python for ML, Go for low latency)?
• Does it need independent compliance isolation (PCI-DSS for payments)?

0-1 points: Stay monolith.

2-3 points: Consider extracting that one component only.

4-5 points: Genuine microservice candidate.

Most Nepal startups today score 0-1 for most components.