Monolith vs Microservices

• Monolith : a single deployable application where all modules run in one process and share one codebase and database.
• Microservices : independently deployable services, each owning its data and communicating over the network.
• Saga pattern : a sequence of local transactions where each step has a compensating action that undoes it if a later step fails.
• Service mesh : infrastructure layer (Istio, Linkerd) that handles service-to-service communication, retries, and observability.

What is a monolith?

A monolith keeps all functionality in one process and usually one database. The advantages early on are significant: a single codebase is easy to understand, a single deployment is simple, calls between modules are fast in-process method calls, and a transaction can span the whole system.

package com.bank.monolith;

import java.math.BigDecimal;
import org.springframework.transaction.annotation.Transactional;

public class MonolithTransferService {
    @Transactional
    public void transfer(String from, String to, BigDecimal amount) {
        accountModule.debit(from, amount);    // same process
        accountModule.credit(to, amount);      // same transaction
        auditModule.record(from, to, amount);  // all commit together
    }
}

What are microservices?

Microservices split the system by business capability, each independently deployable with its own database, communicating over the network.

package com.bank.microservice;

import java.math.BigDecimal;

public class MicroserviceTransferService {
    public void transfer(String from, String to, BigDecimal amount) {
        accountClient.debit(from, amount);      // network call
        accountClient.credit(to, amount);        // no shared DB transaction
        eventBus.publish("transfer.completed"); // async audit
    }
}

When is a monolith better?

For a small team or early-stage product, the monolith's simplicity and speed are exactly what you want. You ship faster, test easier, and debug simpler. Premature microservices are a classic mistake.

When are microservices needed?

Microservices become the right answer at scale and with many teams. They enable independent scaling, independent deployment, fault isolation, and team autonomy.

What are the costs of microservices?

No distributed transaction across services by default, so you need sagas. Network calls fail and add latency. Data is spread across services, complicating queries. You need mature operations: service discovery, centralized logging, tracing, and CI/CD per service.

package com.bank.saga;

import java.math.BigDecimal;

public class TransferSaga {
    public void execute(String from, String to, BigDecimal amount) {
        try {
            accountService.debit(from, amount);     // step 1
            accountService.credit(to, amount);       // step 2
        } catch (Exception e) {
            accountService.compensateDebit(from, amount); // undo step 1
            throw new SagaFailedException(e);
        }
    }
}

What is the recommended migration path?

Start with a well-modularized monolith. When a specific scaling or deployment pain appears, extract that module as a service along a clear seam. This is safer than starting distributed from day one.

How do you handle transactions across microservices?

Use the saga pattern: each step has a compensating action. If the audit service is down, the saga rolls back the debit and credit. This replaces the single ACID transaction of the monolith.

What should a senior engineer know?

A senior engineer knows that a well-modularized monolith first, with services extracted along clear seams only when pain actually appears, is almost always wiser than starting distributed. They also know about the strangler fig pattern for gradual migration.