Overview

Picture the store as a single Spring Boot application: login, catalogue, orders and payments in one codebase, one database, one deployable .jar. On Black Friday only checkout is overloaded, but the only way to scale it is to run more copies of everything. A bug in the catalogue page takes login down with it. Three teams now share the codebase, and every release needs all of them to agree on the same day. Nothing is wrong with the code — the shape of the system no longer fits the organisation.

The microservices style is a response to this specific problem: as teams and codebases grow, a single monolith becomes increasingly expensive to change — a modification to one module requires understanding and testing the entire system, and a deployment requires coordinating across the whole organisation.

Microservices is an architectural style that structures an application as a collection of small, autonomous services, each modelled around a specific business domain⁵². Rather than building one large deployable unit (a monolith), the system is composed of independently deployable pieces that collaborate through well-defined APIs.

Roadmap

1. This page — why and when to split, Conway's Law, principles, data ownership, synchronous vs asynchronous communication, the store's services.
2. Domain-Driven Design — the vocabulary and techniques to find good service boundaries.
3. Architecture & Components — load balancer, gateway, identity provider, discovery, configuration, broker, observability, and the course's reference architecture.

Slides

Click the slides and use ← → to move through them; F goes full screen and P opens the presenter view, with the notes. Open the slides in a new tab

Monolith vs. Microservices

flowchart LR
    subgraph mono [Monolith]
        direction TB
        ui_m[UI]
        biz_m[Business Logic\nOrders · Auth · Payments · Inventory]
        data_m[Single Database]
        ui_m --> biz_m --> data_m
    end
    subgraph micro [Microservices]
        direction TB
        gw[API Gateway]
        s1[Orders\nService]
        s2[Auth\nService]
        s3[Inventory\nService]
        db1[(Orders DB)]
        db2[(Auth DB)]
        db3[(Inventory DB)]
        gw --> s1 & s2 & s3
        s1 --> db1
        s2 --> db2
        s3 --> db3
    end

Neither style is universally better. The right choice depends on team size, domain complexity, and operational maturity:

Two terms in the table deserve a definition. An ACID transaction (Atomicity, Consistency, Isolation, Durability) lets the monolith change orders and stock in one database operation that either fully happens or not at all. Across services there is no shared transaction: each service commits its own data, and the system becomes consistent a moment later — eventual consistency (see CAP Theorem).

The middle ground: a modular monolith. One deployable unit, but internally split into modules with explicit interfaces and no shared tables — each module could become a service later. It gives the team practice with boundaries before paying for the network, and it is often the right answer for a small team.

Conway's Law

"Any organisation that designs a system will produce a design whose structure is a copy of the organisation's communication structure." — Melvin Conway, 1967⁶

Service boundaries and team boundaries converge over time. The simulation below shows how an initially unified codebase fragments into services that mirror the communication patterns of the teams that built it:

The law also works in reverse, which is how organisations use it on purpose: the inverse Conway maneuver shapes the teams first (one team per business capability) so that the architecture follows.

Key principles

How small is "micro"? Not a number of lines. A service is the right size when one team can own it end to end, it can be deployed without coordinating with others, and it maps to one business capability. Services that are too small ("nanoservices", e.g. one service per table) spend more time talking to each other than doing work.

The store, decomposed

The course builds one platform step by step. Each service owns one capability and its own data⁴:

Note decentralised governance in action: the exchange and notification services are written in Python, the others in Java — the contract is HTTP/JSON or a Kafka event, so the language does not leak.

Owning the data

Database-per-service means that no service reads or writes another service's tables. It does not require one database server per service. In the hands-on, a single Postgres container hosts several schemas, and each service is the only one that touches its own (the account service sets hibernate.default_schema: accounts and runs its own Flyway migrations):

flowchart LR
    subgraph pg ["one Postgres server"]
        s1[("schema accounts")]
        s2[("schema products")]
        s3[("schema orders")]
    end
    account["account-service"] --> s1
    product["product-service"] --> s2
    order["order-service"] --> s3
    order -->|"GET /products/{id}"| product
    order -.-x|"no direct SQL"| s2

When the order service needs a product's price, it asks the product API, never the product table. That keeps the product team free to change its schema. Two consequences follow:

• Queries across services become API calls (or a local copy of the data, kept up to date by events — see CQRS).
• Business transactions across services cannot use one ACID transaction. They become a sequence of local transactions coordinated by events, with compensating actions when a step fails — the saga pattern⁴.

Inter-service communication

Services in a microservice system communicate in two fundamentally different ways, each with distinct trade-offs:

sequenceDiagram
    participant Client
    participant Gateway
    participant Order Service
    participant Inventory Service

    Client->>+Gateway: POST /orders
    Gateway->>+Order Service: create order
    Order Service->>+Inventory Service: reserve items
    Inventory Service-->>-Order Service: reserved ✓
    Order Service-->>-Gateway: 201 Created
    Gateway-->>-Client: 201 Created

sequenceDiagram
    participant Order Service
    participant Message Broker
    participant Inventory Service
    participant Notification Service

    Order Service->>Message Broker: OrderPlaced event
    Note over Order Service: continues immediately
    Message Broker->>Inventory Service: OrderPlaced
    Message Broker->>Notification Service: OrderPlaced
    Inventory Service->>Message Broker: InventoryReserved

In the store, the order service calls the product service synchronously (it needs the price to compute the total before answering), and publishes an OrderCreated event to Kafka asynchronously so that the notification service can send the e-mail without slowing the customer down (Hands-on 9).

Topics covered

Key takeaways

• Microservices trade operational complexity for independent deployment, scaling and team autonomy — worth it only when those are real problems.
• Start with a (modular) monolith; split along stable domain boundaries found with DDD³, or you get a distributed monolith.
• Conway's Law: service boundaries mirror team communication — design both together.
• Each service owns one capability and its data; others use its API, never its tables.
• Synchronous calls are simple but couple availability; events decouple producers from consumers.

Connections

• Why the network makes this hard: Distributed Systems.
• The contracts between services: API.
• Build the platform: Hands-on 1 — CRUD, Hands-on 2 — Gateway, Hands-on 3 — Security.
• Inside one service: Software Architectures (clean and hexagonal).
• Asynchronous integration: Event-Driven Architecture and Hands-on 9 — Kafka.