Monolith vs Microservices

Analogy categoryAnalogies

A monolith is a single deployable unit: one codebase, one build pipeline, one running process (or a small fixed set of identical processes behind a load balancer) that contains all the application's modules, such as catalog, checkout, and user-accounts, compiled and shipped together. A microservices architecture splits those same modules into separately deployable services, each with its own codebase, build pipeline, and runtime. Both approaches can implement identical business logic; the difference is entirely about how that logic is packaged, deployed, and operated.

🏏

Cricket analogy: A monolith is like a single all-rounder batting, bowling, and fielding all match; microservices are like a full XI where each player has one specialized role, both can win the match but the coordination model differs completely.

Deployment and Scaling

In a monolith, deploying any change, even a one-line fix to the checkout module, means rebuilding and redeploying the entire application; scaling means running more copies of the whole thing, even if only checkout is under load. In microservices, checkout-service can be redeployed and scaled to 30 replicas on its own while catalog-service stays at 3 replicas, because they are separate deployable units with separate resource footprints.

🏏

Cricket analogy: In a monolith model, if the wicketkeeper is injured the whole team's playing eleven must be re-submitted for approval; in microservices, you substitute just the keeper without touching the rest of the lineup.

Data Management

A monolith typically uses one shared database with tables for orders, users, and products all queryable via joins in a single transaction, which makes cross-entity consistency easy (a single ACID transaction can update an order and decrement inventory atomically). Microservices split data per service, so an order that needs inventory information can't just JOIN two tables; it has to call inventory-service's API or rely on eventually-consistent data replicated via events, trading transactional simplicity for service independence.

🏏

Cricket analogy: A shared scorebook kept by one scorer for the whole match is simple to reconcile at any moment, like a monolith's single database; separate scorebooks kept by each team's own scorer need to be reconciled afterward, like eventual consistency between services.

sql

-- Monolith: single database, one ACID transaction across both tables
BEGIN;
  UPDATE inventory SET qty = qty - 1 WHERE sku = 'SKU-123';
  INSERT INTO orders (sku, qty, status) VALUES ('SKU-123', 1, 'CONFIRMED');
COMMIT;

-- Microservices: order-service publishes an event; inventory-service
-- consumes it asynchronously and updates its own database independently
// order-service
await eventBus.publish('OrderPlaced', { sku: 'SKU-123', qty: 1 });

// inventory-service (separate process, separate DB)
eventBus.subscribe('OrderPlaced', async (event) => {
  await inventoryDb.query(
    'UPDATE inventory SET qty = qty - $1 WHERE sku = $2',
    [event.qty, event.sku]
  );
});

Splitting a monolith's shared database prematurely is one of the most common microservices mistakes. If two 'services' still need cross-table joins or shared transactions to function correctly, they are not truly independent — merge them back or redesign the boundary before splitting the deployment.

Team Structure Fit

A monolith fits a single team (roughly 5-15 engineers) who can hold the whole codebase in their heads and coordinate releases through one shared branch and CI pipeline. As an organization grows past that size, multiple teams touching one shared codebase start blocking each other with merge conflicts and coupled release trains; splitting into microservices, each owned by one team, removes that cross-team coordination bottleneck at the cost of needing platform investment (CI/CD per service, observability, API contracts).

🏏

Cricket analogy: A club-level team of 11 can manage with one informal captain calling all the shots; a national cricket board with dozens of teams (age-group, women's, T20, Test) needs separate selection committees per team to avoid gridlock.

A monolith is one deployable unit with one codebase and typically one shared database.
Microservices split the same functionality into independently deployable units, each with its own data store.
Monolith deployments and scaling apply to the whole application at once; microservices deploy and scale per service.
Monoliths get easy ACID transactions across entities; microservices trade that for eventual consistency and API-based access.
Splitting a shared database before service boundaries are proven correct is a common and costly mistake.
Monoliths fit small teams; microservices help larger organizations avoid cross-team coordination bottlenecks.
Neither approach is universally better — the right choice depends on team size, deployment cadence, and consistency needs.

Practice what you learned

1. What is the primary structural difference between a monolith and a microservices architecture?

2. Why is cross-entity data consistency easier in a monolith than in microservices?

3. What is a common mistake teams make when adopting microservices?

4. What organizational factor most influences whether a monolith or microservices architecture fits better?

Was this page helpful?

What Are Microservices?

When to Use Microservices

Related Study Notes in Software Engineering

Browse all study notes

Software Engineering

Testing & TDD Study Notes

Software Testing · 30 topics

Software Engineering

Design Patterns Study Notes

Software Design · 30 topics

Software Engineering

Software Engineering Study Notes

Python · 40 topics

Software Engineering

Git & Version Control Study Notes

Bash · 40 topics

Software Engineering

System Design Study Notes

Architecture · 40 topics

Topics covered

#SoftwareArchitecture#MicroservicesStudyNotes#SoftwareEngineering#MonolithVsMicroservices#Monolith#Microservices#Deployment#Scaling#StudyNotes#SkillVeris

Monolith vs Microservices