Microservices

A microservice is a separately deployable application that owns its own data and is reached over a network. Orders is one service with one database. Invoicing is another, with another. Neither reads the other's tables; they talk through an interface published over HTTP or a broker.

The word small in the usual definition is the least useful part of it. What actually changes is deployment: each service is released on its own, so a change to invoicing requires no ordering release and no coordination meeting. Everything gained and everything lost follows from that one property.

// One process. The compiler checks the call, and it cannot half-happen.
public async Task ApproveAsync(int orderId, CancellationToken token)
{
    Order order = await orders.FindAsync(orderId, token)
        ?? throw new OrderNotFoundException(orderId);

    order.Approve(clock.GetUtcNow().UtcDateTime);
    invoicing.Raise(order);                 // in-process call

    await db.SaveChangesAsync(token);       // one transaction covers both
}

// Two processes. Same intent, plus everything the network adds.
public async Task<ApprovalOutcome> ApproveAsync(int orderId, CancellationToken token)
{
    Order order = await orders.FindAsync(orderId, token)
        ?? throw new OrderNotFoundException(orderId);

    order.Approve(clock.GetUtcNow().UtcDateTime);
    await db.SaveChangesAsync(token);       // committed: the order is approved

    var request = new RaiseInvoice(order.Id, order.Number, order.Total, "GBP");

    try
    {
        HttpResponseMessage response = await invoicingApi.PostAsJsonAsync(
            "/invoices", request, token);

        if (response.StatusCode == HttpStatusCode.Conflict)
            return ApprovalOutcome.ApprovedAlreadyInvoiced;

        response.EnsureSuccessStatusCode();
        return ApprovalOutcome.ApprovedAndInvoiced;
    }
    catch (Exception ex) when (ex is HttpRequestException or TaskCanceledException)
    {
        log.LogError(ex, "Order {OrderId} approved; invoicing did not answer.", order.Id);
        await outbox.ScheduleAsync(request, token);
        return ApprovalOutcome.ApprovedInvoicePending;
    }
}

• The first version is checked at build time. Rename a parameter in invoicing and this file stops compiling, which is a defect found in seconds rather than in production.
• The second version cannot share a transaction, so a state exists that the first version could not reach: approved, not invoiced. That state needs a name, a screen that shows it, and someone who chases it. Notice the return type had to grow to express it.
• The 409 branch is there because a retry can land on a request invoicing already processed. That obliges the other team to make their endpoint idempotent, which is a contract you now have to agree and test with them.
• The catch covers three situations that are indistinguishable from here: the request never arrived, it was processed and the reply was lost, or invoicing is merely slow. You cannot tell which, so the honest response is to schedule a retry and accept possible duplicate work.
• Type safety across the boundary is gone. The contract is a JSON shape described in a document, so a field rename on their side becomes a run-time failure on yours, at the worst moment.
• This is one call. A flow crossing four services carries this weight four times, and the combinations of partial failure multiply rather than add.

Scale is the reason given most often and it is the weakest one. A single application can run as twenty identical copies behind a load balancer, sharing one database, and handle very large volumes. You get horizontal scale without splitting anything. What you cannot do that way is size parts differently: if the PDF renderer needs eight gigabytes of memory and the API needs half of one, you pay for the larger figure everywhere. That is a genuine argument, and it is much narrower than "we need to scale".

Two arguments do hold. The first is independent deployment: separate teams with different release rhythms, where one team's half-finished work must not delay another team's release, and where a risky change should be able to go out without re-testing everything else. The second is team autonomy at a size where a single codebase creates real coordination cost — many teams, one repository, one release train, and a queue to get anything out.

So team size and the need for independent deployment decide this, not throughput. Three teams that block each other every fortnight have the problem microservices solve. One team of six deploying twice a week does not, and splitting their application adds the coordination cost of many teams without giving them any of the independence, because every change still touches several services and they still all ship together.

For a small team the better answer is almost always a modular monolith: real module boundaries, dependency rules the build enforces, separate schemas per module if you like, and one deployable unit. You keep compile-time checking, one transaction, one stack trace and one pipeline. The boundaries you draw there are the boundaries you would need anyway, and drawing them is the work that makes a later split possible.