Monolith vs Microservices: When to Use Each

Defining both architectures clearly

A monolith is a single deployable unit: all business logic — users, orders, payments, notifications — lives in one codebase, running as one process, usually against one database. Microservices split that same logic into independent services, each with its own codebase, deployment pipeline, and often its own database.

The debate isn't "which is better" — it's "which fits the current stage of this specific product, team, and business." Both are valid, mature, production-proven approaches used by some of the largest platforms in the world.

What a monolith looks like in code

In a monolith, placing an order and sending a notification can be a single function call inside the same process — fast, simple, and easy to debug with a single stack trace.

// orders/service.js — runs in the same process as everything else
const db = require('../shared/db');
const notifications = require('../notifications/service');
const inventory = require('../inventory/service');

async function placeOrder(userId, items) {
  const order = await db.orders.create({ userId, items, status: 'pending' });

  await inventory.reserveStock(items);   // direct function call
  await notifications.send(userId, 'order_created', order.id); // direct call

  return order;
}

module.exports = { placeOrder };

Everything is a direct, synchronous function call. There's no network hop, no serialization, no partial failure between services — if the database transaction commits, the whole operation succeeded or failed as one unit.

What microservices look like in code

The same flow in microservices requires network communication, message queues, and handling for partial failure — each service owns its domain and talks to others through contracts, not direct calls.

// orders-service/handlers/placeOrder.js
const db = require('./db');
const eventBus = require('./eventBus');

async function placeOrder(req, res) {
  const order = await db.orders.create({
    userId: req.body.userId,
    items: req.body.items,
    status: 'pending'
  });

  // Fire-and-forget event — no direct call to other services
  await eventBus.publish('order.created', {
    orderId: order.id,
    userId: order.userId,
    items: order.items
  });

  res.status(201).json(order);
}

module.exports = { placeOrder };

// notifications-service/consumers/orderCreated.js
const eventBus = require('./eventBus');
const notifier = require('./notifier');

eventBus.subscribe('order.created', async (event) => {
  try {
    await notifier.send(event.userId, 'order_created', event.orderId);
  } catch (err) {
    // Must handle retries, dead-letter queues, idempotency
    await eventBus.publishToRetryQueue('order.created', event, err);
  }
});

Notice the shift: the orders service no longer knows (or cares) who consumes its events. That decoupling is powerful for scale and team autonomy — but it also means you now need an event bus, retry logic, idempotency handling, and distributed tracing to debug a single business flow.

When a monolith is the right choice

A well-modularized monolith — organized into clear internal modules with defined boundaries — can scale an organization to hundreds of engineers before fragmentation becomes necessary. Shopify ran a modular monolith at massive scale for years.

When microservices are the right choice

Direct comparison: criteria by criteria

The modular monolith: a middle ground

A modular monolith keeps a single deployable unit but enforces strict internal boundaries between domains — each module has its own folder, its own data access layer, and communicates with others through well-defined interfaces, never directly reaching into another module's internals.

src/
  modules/
    orders/
      service.js
      repository.js
      index.js        ← public interface only
    inventory/
      service.js
      repository.js
      index.js
    notifications/
      service.js
      index.js
  shared/
    db.js
    eventBus.js

This structure gives you most of the clarity benefits of microservices — clear ownership, enforced boundaries, easier future extraction — while keeping the operational simplicity of a single deployment. It's often the best starting point for teams unsure which path they'll need in 2-3 years.

The hidden costs of each approach

Neither architecture is a shortcut to good design. Microservices without domain-driven boundaries just distribute the same mess over a network — with extra operational burden and no real benefit.

Decision framework: a practical flow

Migration path, when it makes sense

Moving from monolith to microservices should never be a rewrite. The safest approach is the Strangler Fig pattern: extract one well-bounded domain at a time, route a slice of traffic to it, and validate stability before touching the next domain.

// api-gateway/router.js
app.use('/api/notifications', (req, res, next) => {
  if (featureFlags.isEnabled('notifications-extracted')) {
    return proxy('http://notifications-service:3001')(req, res, next);
  }
  return proxy('http://monolith:3000')(req, res, next); // fallback
});

This pattern lets you extract gradually, with an instant rollback path if the new service misbehaves — no big-bang cutover, no stopped feature development for months.

Decision checklist

Conclusion

There is no universally correct answer between monolith and microservices — only a correct answer for your current context: team size, domain maturity, scaling needs, and operational readiness. Most teams are better served starting with a well-structured modular monolith and extracting services only when real, consistent friction justifies the added complexity.

The biggest mistake isn't choosing the "wrong" architecture — it's choosing one for the wrong reasons: hype, resume-driven development, or fear of being seen as outdated. Choose based on evidence, not trends.