🧩 Microservices Principles

What Is a Microservice?

A microservice is a small, independently deployable service that owns one business capability end-to-end — its own code, its own data, and its own deployment lifecycle. A microservices architecture is an application built as a collection of such services that cooperate over the network.

Picture a busy restaurant kitchen. Instead of one chef juggling appetizers, mains, and desserts, there are specialized stations: the grill, the salad prep, the pastry counter. Each station does one job well, talks to the others when it needs something ("two steaks ready for table six"), and can be staffed up independently — three extra salad hands during the lunch rush without touching the grill. Microservices apply that same division of labor to software.

The word "micro" is misleading. The unit of size is not lines of code — it's responsibility. A microservice is as big as one business capability needs it to be. "Small enough that one team can own it, large enough to be worth deploying on its own" is the useful measure.

Monolith vs. Microservices

In a monolith, all the code — UI, business logic, data access — lives in one deployable unit, sharing one process and usually one database. In a microservices system, that same functionality is split across many services, each shipped and scaled on its own.

Neither is "better" in the abstract. They optimize for different things:

Core Principles

Across every successful microservices system, the same handful of principles show up. They all reinforce one goal: services that can change and ship without waiting on each other.

1. Organize around business capability

A service should map to something the business does — "manage the product catalog," "process payments" — not to a technical layer like "the database service." Capability-aligned services change together with the business need they serve, so a feature usually touches one service, not five.

2. Own your data

Each service is the sole owner of its data. Other services ask for it through the API; they never reach into its tables. (Full section below.)

3. Communicate over well-defined APIs

The API is the contract. Version it so you can evolve without breaking callers.

// Product Service — a stable, versioned REST contract
// GET    /api/v1/products          List products (supports ?category & ?limit)
// GET    /api/v1/products/:id      Fetch one product
// POST   /api/v1/products          Create a product
// PUT    /api/v1/products/:id      Replace a product
// DELETE /api/v1/products/:id      Remove a product

// The /v1/ prefix lets you ship /v2/ later WITHOUT breaking existing clients.
app.get('/api/v1/products/:id', async (req, res) => {
    const product = await productRepo.findById(req.params.id);
    if (!product) return res.status(404).json({ error: 'Product not found' });
    res.json(product);
});

4. Deploy independently

Each service has its own CI/CD pipeline. Updating the login flow ships the User service alone — the other 40 services keep running untouched.

5. Design for failure

Networks drop packets and services crash. A resilient service degrades gracefully instead of taking the whole system down with it. Timeouts, retries, and circuit breakers are the standard tools — we cover them in depth in the next lesson.

// A minimal circuit breaker: stop hammering a service that's clearly down.
class CircuitBreaker {
    constructor(action, { failureThreshold = 3, cooldownMs = 10000 } = {}) {
        this.action = action;
        this.failureThreshold = failureThreshold;
        this.cooldownMs = cooldownMs;
        this.failures = 0;
        this.state = 'CLOSED';        // CLOSED = healthy, OPEN = failing fast
        this.openedAt = 0;
    }

    async fire(...args) {
        if (this.state === 'OPEN') {
            // Has the cooldown elapsed? If so, allow ONE trial request.
            if (Date.now() - this.openedAt < this.cooldownMs) {
                throw new Error('Circuit open — failing fast');
            }
            this.state = 'HALF_OPEN';
        }
        try {
            const result = await this.action(...args);
            this.reset();             // success — the service is healthy again
            return result;
        } catch (err) {
            this.recordFailure();
            throw err;
        }
    }

    recordFailure() {
        this.failures += 1;
        if (this.failures >= this.failureThreshold) {
            this.state = 'OPEN';
            this.openedAt = Date.now();
        }
    }

    reset() { this.failures = 0; this.state = 'CLOSED'; }
}

6. Decentralize technology choices

Because services only meet at the API, each team can pick the right stack for its job — Node.js for an I/O-heavy notification service, Python for an ML-driven recommender — without forcing that choice on anyone else. Use this freedom deliberately, though: every extra language is another thing to build, monitor, and hire for.

Database per Service

This is the principle beginners break first and regret most. Each service owns its data privately. No other service — and no shared "reporting" job — reads or writes those tables directly. Access goes through the owning service's API, always.

Why so strict? Because a shared database quietly recouples everything you worked to decouple:

• Independent deploys die. If two services share a table, a schema change forces a coordinated release — the exact thing microservices exist to avoid.
• Boundaries blur. Once any service can read any table, business rules leak everywhere and no one owns the data's integrity.
• Freedom of technology returns. The Product service can use MongoDB while Orders uses PostgreSQL, because nothing else depends on either schema.

The same word can even mean different things in different services, and that's fine:

• In the Catalog service, a "Product" is a name, description, images, and category.
• In the Inventory service, a "Product" is a SKU, stock level, and warehouse location.
• In the Order service, a "Product" is the price captured at purchase time and the quantity ordered.

Finding Boundaries with DDD

The hardest question in microservices is not "how do I build a service?" but "where does one service end and the next begin?" Split too finely and you drown in network chatter; split too coarsely and you're back to a monolith. Domain-Driven Design (DDD) gives you a principled way to draw the lines.

The key idea is the bounded context: a boundary within which a particular model and vocabulary are consistent. Inside the "Shipping" context, everyone — code and people — means the same thing by "address" and "delivery." Cross into "Billing" and the same words carry different meaning. Each bounded context is a strong candidate for a service.

Two supporting concepts make bounded contexts practical:

• Ubiquitous language — the shared vocabulary of a context, used identically by domain experts and in the code. When the warehouse team says "pick," the Inventory service has a pick() operation.
• Context map — a diagram of how contexts relate: who calls whom, who publishes events, where translation between models happens.

When (Not) to Use Microservices

Microservices buy you scalability and team autonomy at the price of real operational complexity. That trade is worth it only sometimes.

Good fit

• Large applications where a monolith has become painful to change and deploy
• Clear, stable domain boundaries you actually understand
• Components with wildly different scaling needs (a search service hammered while billing idles)
• Multiple teams that need to ship on independent schedules

Poor fit

• Small apps where the infrastructure overhead dwarfs the benefit
• Early-stage products still discovering what they even are — you don't know the boundaries yet
• Teams without solid DevOps, CI/CD, and observability practices in place
• Domains whose components are so interconnected that every request would fan out to a dozen services

The pragmatic path most teams take is the monolith-first, extract-gradually approach:

Shopify and Amazon both grew this way — starting monolithic and carving out services only where scaling or team boundaries demanded it, keeping plenty in the monolith where it made sense.

Practice & Quiz

Best Practices & Pitfalls

✅ Do

• Start with a modular monolith; extract services once boundaries are stable and the pain is real
• Draw service boundaries around bounded contexts and business capabilities
• Give every service its own private database — no exceptions
• Version your APIs (/api/v1/...) so you can evolve without breaking callers
• Invest in CI/CD, monitoring, and distributed tracing before you have many services

❌ Don't

• Start a greenfield project with microservices "to be safe"
• Let two services share a database or read each other's tables
• Split by technical layer (a "database service," a "logic service") instead of by capability
• Make everything a synchronous call — that creates tight coupling and cascading failures
• Adopt five languages just because you can; each one is an operational tax

Summary

📚 Additional Resources

• microservices.io — Chris Richardson's pattern catalog
• Martin Fowler — Microservices (the foundational article)
• Martin Fowler — Bounded Context
• Martin Fowler — MonolithFirst

🚀 What's Next?

You can now decompose a system into independently deployable services. But services are useless if they can't talk to each other reliably. Next up: Service Communication Patterns — synchronous REST and gRPC, asynchronous events and message queues, service discovery, and the resilience patterns (timeouts, retries, circuit breakers, sagas) that keep a distributed system standing when parts of it fail.