Serviços

A BoxOffice começou, como a maioria das empresas, como uma única aplicação Spring Boot: eventos, assentos, pedidos, pagamentos e e-mails em uma só base de código, um só banco PostgreSQL, um só .jar para fazer deploy. No primeiro ano isso era exatamente o certo. Então três coisas aconteceram ao mesmo tempo. Nos dias de abertura de vendas, só o mapa de assentos e o checkout ficavam sobrecarregados, mas a única forma de escalá-los era rodar mais cópias de tudo. Um bug no upload de imagens de locais derrubou o checkout junto. E quatro times passaram a dividir a mesma base de código: cada release exigia que todos concordassem com o mesmo dia.

Nada estava errado com o código. O formato do sistema já não combinava com a carga nem com a organização. Esta página trata de escolher esse formato: de que tamanho deve ser uma unidade de deploy, onde traçar as fronteiras entre serviços e como organizar o código dentro de um serviço para que ele sobreviva a anos de mudanças.

O espectro: do monolito aos microsserviços

"Monolito ou microsserviços" não é uma escolha binária; é um espectro de quantas unidades com deploy independente o sistema tem e de quão fortemente suas fronteiras são impostas.

flowchart LR
    subgraph mono ["Monolito"]
        direction TB
        m1["uma aplicação<br/>catalog · inventory · order · payment"] --> mdb[("um banco de dados")]
    end
    subgraph modular ["Monolito modular"]
        direction TB
        mm["uma aplicação"] --- c1["módulo catalog"]
        mm --- c2["módulo inventory"]
        mm --- c3["módulo order"]
        c1 --> s1[("schema catalog")]
        c2 --> s2[("schema inventory")]
        c3 --> s3[("schema order")]
    end
    subgraph micro ["Microsserviços"]
        direction TB
        gw["gateway"] --> x1["catalog"]
        gw --> x2["inventory"]
        gw --> x3["order"]
        x1 --> d1[("banco catalog")]
        x2 --> d2[("banco inventory")]
        x3 --> d3[("banco order")]
    end
    mono --> modular --> micro

O monolito modular merece mais atenção do que costuma receber. Ele entrega o principal benefício dos microsserviços — fronteiras claras, cada módulo dono dos seus dados — sem pagar pela rede. Se um módulo depois precisar de escala independente ou de outro time, ele pode ser extraído ao longo de uma fronteira que já existe. A Shopify, por exemplo, descreveu publicamente sua escolha de modularizar um grande monolito Rails em vez de quebrá-lo em serviços⁷.

Quando dividir compensa

Separe uma parte do sistema em um serviço próprio quando pelo menos uma destas forças for forte — e anote qual, porque ela diz onde cortar:

E os custos que você aceita ao dividir:

• Toda chamada pode falhar ou ser lenta (sistemas distribuídos): timeouts, retries e circuit breakers passam a ser obrigatórios.
• Não há transações entre serviços: "reservar o assento, criar o pedido, cobrar o cartão" vira uma saga com compensações (mensageria).
• A disponibilidade se multiplica para baixo em cadeias síncronas: três serviços a 99,9% em série dão ≈ 99,7%.
• A operação se multiplica: N pipelines, N dashboards, tracing distribuído para depurar uma única requisição (observabilidade).

Quão pequeno é "micro"? Não é um número de linhas. Um serviço tem o tamanho certo quando um time consegue ser dono dele de ponta a ponta, ele pode ir para produção sem coordenação com outros e corresponde a uma capacidade de negócio. Serviços pequenos demais ("nanosserviços", por exemplo, um por tabela) gastam mais tempo conversando entre si do que trabalhando.

Encontrando fronteiras com Domain-Driven Design

Você decidiu dividir. Onde cortar? Por tabela do banco (events, seats, orders)? Por camada (um "serviço de UI", um "serviço de lógica")? Cada uma dessas opções produz serviços que precisam mudar juntos. O Domain-Driven Design (DDD)¹ dá uma resposta melhor: corte onde o próprio negócio tem uma emenda.

O DDD atua em dois níveis:

O design estratégico decide os serviços; o design tático molda o código dentro de cada um.

Subdomínios: onde investir

Nem toda parte do negócio merece o mesmo esforço:

Essa última linha é a razão de a BoxOffice ter um problema de integrações externas: ela deliberadamente não constrói seu próprio processamento de cartões nem seus servidores de e-mail.

Linguagem ubíqua e bounded contexts

A linguagem ubíqua é o vocabulário compartilhado por desenvolvedores e especialistas do domínio e usado literalmente no código: se a equipe da bilheteria fala hold, on-sale, mapa de assentos e alocação, o código diz Hold, OnSale, SeatMap e Allocation — não TempReservation nem Lock.

Mas a mesma palavra muitas vezes significa coisas diferentes em partes diferentes do negócio. Um bounded context (contexto delimitado) é a fronteira dentro da qual vale um modelo, e um significado para cada palavra:

flowchart LR
    subgraph cat ["Contexto Catalog"]
        e1["Event<br/>artista · data · local · descrição · imagens"]
    end
    subgraph inv ["Contexto Inventory"]
        e2["Event<br/>mapa de assentos · setores · holds · capacidade"]
    end
    subgraph ord ["Contexto Order"]
        e3["Event (como vendido)<br/>id do evento · assento · preço pago · taxas"]
    end
    cat -. "mesma palavra,<br/>modelo diferente" .- inv
    inv -. "mesma palavra,<br/>modelo diferente" .- ord

Tentar construir uma única classe Event que sirva aos três — com imagens, mapa de assentos e preços históricos — produz um objeto inchado que não serve bem a nenhum e acopla três times. Em vez disso, cada contexto é dono do seu próprio modelo, e eles trocam ids e eventos. Note em especial o contexto Order: um pedido guarda o preço pago, não uma referência ao preço atual, porque se o catálogo mudar um preço amanhã, o pedido de ontem não pode mudar.

Um bounded context normalmente corresponde a um serviço (ou a um pequeno grupo de serviços muito relacionados). Essa é a principal heurística para fronteiras de serviços.

Context maps: como os contextos se relacionam

Os contextos trocam dados, e a relação entre cada par é uma decisão de design. Um context map (mapa de contextos) desenha essas relações³:

flowchart LR
    catalog["Catalog"] -->|"Open Host: REST + OpenAPI"| order["Order"]
    catalog -->|"Published Language:<br/>eventos EventPublished"| search["Search"]
    inventory["Inventory"] -->|"Customer / Supplier:<br/>API de hold e confirmação"| order
    order -->|"evento OrderConfirmed"| notification["Notification"]
    psp["Provedor de pagamentos"] -->|"Anti-Corruption Layer"| payment["Payment"]
    payment -->|"evento PaymentSucceeded"| order
    mail["Provedor de e-mail"] -->|"Anti-Corruption Layer"| notification

As duas anti-corruption layers são as que mais importam na prática: o modelo do provedor de pagamentos (seus "payment intents", seus nomes de status, seus códigos de erro) não pode se espalhar pela BoxOffice. O serviço payment o traduz para o modelo Payment da própria BoxOffice na fronteira — a página de integrações mostra esse adaptador.

Agregados: a unidade de consistência

Dentro de um contexto, um agregado é um conjunto de objetos alterados juntos como uma unidade, com uma raiz como único ponto de entrada. A raiz garante os invariantes — regras que precisam valer sempre. Duas regras fazem os agregados se encaixarem em microsserviços:

• Referencie outros agregados apenas pelo id. Um Hold guarda o seatId e o fanId, nunca um objeto Fan. É isso que permite que os dois vivam em serviços diferentes.
• Uma transação altera um agregado. Se um caso de uso precisa alterar dois agregados, a segunda alteração acontece depois, disparada por um evento de domínio (consistência eventual).

public class Hold {                                   // aggregate root
    private static final Duration TTL = Duration.ofMinutes(10);
    private static final int MAX_SEATS = 6;           // per fan, per event

    private final HoldId id;
    private final EventId eventId;                    // other aggregates: by id only
    private final FanId fanId;
    private final Set<SeatId> seats;
    private final Instant expiresAt;
    private HoldStatus status = HoldStatus.ACTIVE;

    public static Hold place(EventId event, FanId fan, Set<SeatId> seats, Clock clock) {
        if (seats.isEmpty() || seats.size() > MAX_SEATS)
            throw new HoldRejected("between 1 and " + MAX_SEATS + " seats");
        return new Hold(HoldId.random(), event, fan, Set.copyOf(seats),
                        clock.instant().plus(TTL));
    }

    public void confirm(Clock clock) {                // called when the payment succeeds
        if (status != HoldStatus.ACTIVE || clock.instant().isAfter(expiresAt))
            throw new HoldExpired(id);
        status = HoldStatus.CONFIRMED;
    }
}

O invariante "um assento pertence a no máximo um hold ativo" abrange todos os holds de um evento, então não pode ser verificado dentro de um único objeto Hold; quem o garante é o banco de dados (uma restrição de unicidade em (event_id, seat_id) para holds ativos) — exatamente o tipo de decisão de que trata a aula 6.

A lei de Conway

"Qualquer organização que projeta um sistema produzirá um projeto cuja estrutura é uma cópia da estrutura de comunicação da organização." — Melvin Conway, 1968⁴

As fronteiras no código tendem a acompanhar as fronteiras entre os times, porque a comunicação dentro de um time é barata e a comunicação entre times é cara. O gráfico abaixo mostra a evolução da BoxOffice: à medida que os times se formam em torno de capacidades de negócio, a base de código se divide nas mesmas linhas.

Duas consequências práticas:

• Se fronteiras e times discordam, os times vencem. Um serviço com três times donos vira um gargalo de coordenação; três serviços de um único time tendem a se fundir de novo em um monolito distribuído.
• A manobra inversa de Conway (inverse Conway maneuver): desenhe os times primeiro — um time stream-aligned por capacidade de negócio, mais um time de plataforma que oferece deploy, observabilidade e bancos de dados como autosserviço — para que a arquitetura venha atrás⁵.

Sendo dono dos dados

Banco de dados por serviço (database per service) significa que nenhum serviço lê ou escreve as tabelas de outro. Isso não exige um servidor de banco por serviço: um cluster PostgreSQL pode hospedar vários schemas, desde que cada schema tenha exatamente um dono.

flowchart LR
    order["order"] -->|"POST /holds/{id}/confirm"| inventory["inventory"]
    inventory --> inv[("schema inventory")]
    order --> ord[("schema order")]
    order -.-x|"sem SQL direto"| inv

Quando order precisa confirmar um hold, ele chama a API de inventory, nunca a tabela holds. Isso deixa o time de inventário livre para mudar seu schema, acrescentar um cache ou migrar para outro banco. Duas consequências decorrem disso:

• Consultas entre serviços viram chamadas de API — ou uma cópia local, somente leitura, dos dados do outro serviço, mantida atualizada por eventos (CQRS, mensageria). O search mantém seu próprio índice de eventos dessa forma.
• Transações de negócio entre serviços viram uma sequência de transações locais coordenadas por eventos ou por um orquestrador, com compensações quando um passo falha: o padrão saga. "Pagamento falhou → liberar o hold" é uma compensação.

datasource:
  url: jdbc:postgresql://${DB_HOST:db}:${DB_PORT:5432}/${DB_NAME:boxoffice}?currentSchema=orders
  username: ${DB_USER:boxoffice}
  password: ${DB_PASSWORD:boxoffice}
flyway:
  schemas: orders

Conversando entre si

sequenceDiagram
    participant F as Fã
    participant O as order
    participant I as inventory
    F->>O: POST /orders
    O->>I: confirmar hold H-7
    I-->>O: confirmado
    O-->>F: 201 Created

sequenceDiagram
    participant O as order
    participant K as Kafka
    participant N as notification
    participant A as analytics
    O->>K: OrderConfirmed
    Note over O: responde ao fã imediatamente
    K->>N: OrderConfirmed → enviar ingressos por e-mail
    K->>A: OrderConfirmed → dashboard de vendas

A aula 8 (mensageria) aprofunda os eventos; a página de estilos de API cobre as opções de requisição/resposta.

Experimente. O cenário microservices divide a aplicação em catalog, inventory, order e notify, cada um com seu banco, atrás de um gateway, e comprar é uma cadeia síncrona: order chama inventory, catalog e notify antes de responder. Execute-o: com 2.000 req/s o catálogo não consegue os pods de que precisa e cerca de 25% das requisições falham (pods e nós são a história da aula 11). Abra-o no playground completo (↗) e aperte Mostrar uma solução possível: mais espaço no cluster e uma fila entre order e notify; o p99 cai para cerca de 60 ms. Agora apague a fila e ligue order direto em notify de novo: com a mesma capacidade, o p99 volta a cerca de 360 ms, porque cada comprador agora espera a confirmação (120 ms em média, com uma cauda longa) antes de receber a resposta.

Dentro de um serviço: arquitetura interna

Dividir o sistema decide as fronteiras entre serviços. Cada serviço ainda precisa de uma estrutura interna, e o mesmo princípio vale em escala menor: proteja as regras de negócio daquilo que muda com mais frequência — frameworks, bancos de dados, protocolos, provedores.

SOLID em uma tabela

Os cinco princípios SOLID⁸ são regras no nível de classe que tornam essa proteção possível:

Em camadas, clean e hexagonal

A maioria dos serviços Spring Boot começa em camadas: controller → service → repository → banco de dados. Isso separa o HTTP da lógica de negócio, mas a camada de negócio ainda depende da camada de persistência. A Clean Architecture (Robert C. Martin) e a Arquitetura Hexagonal, também chamada de ports and adapters (Alistair Cockburn), invertem essa única seta: o núcleo define interfaces (portas) em termos de negócio, e a infraestrutura (adaptadores) as implementa⁹¹⁰.

flowchart LR
    rest["Controller REST<br/>(adaptador de entrada)"] --> uc["PayForOrder<br/>caso de uso"]
    kafka["Listener Kafka<br/>(adaptador de entrada)"] --> uc
    uc --> port1["«porta»<br/>PaymentGateway"]
    uc --> port2["«porta»<br/>PaymentRepository"]
    stripe["ProviderAdapter<br/>(cliente HTTP)"] -.->|implementa| port1
    fake["FakeGateway<br/>(testes)"] -.->|implementa| port1
    jpa["JpaPaymentRepository"] -.->|implementa| port2

Para o serviço payment isso não é acadêmico. A porta é a anti-corruption layer do mapa de contextos:

// core — knows nothing about HTTP, JSON or any provider SDK
public interface PaymentGateway {
    ChargeResult charge(PaymentId id, Money amount, PaymentMethodToken method,
                        IdempotencyKey key);
}

// adapter — the only class that knows the provider's API and vocabulary
@Component
class ProviderPaymentGateway implements PaymentGateway {
    private final ProviderClient client;   // generated or hand-written HTTP client

    @Override
    public ChargeResult charge(PaymentId id, Money amount, PaymentMethodToken method,
                               IdempotencyKey key) {
        var response = client.createPayment(amount.cents(), amount.currency().code(),
                                            method.value(), key.value());
        return switch (response.status()) {            // translate THEIR states to OURS
            case "succeeded"       -> ChargeResult.succeeded(response.id());
            case "requires_action" -> ChargeResult.needsCustomerAction(response.nextActionUrl());
            case "processing"      -> ChargeResult.pending(response.id());
            default                -> ChargeResult.failed(response.failureCode());
        };
    }
}

O ganho: os testes dos casos de uso rodam em milissegundos com um FakeGateway; acrescentar um segundo provedor para failover é um novo adaptador, não uma reescrita; e os nomes de status do provedor param em uma única classe.

Capacidades compartilhadas como serviços

Algumas capacidades são necessárias para muitas partes do sistema e aparecem como componentes próprios na paleta. Costumam ser os primeiros serviços extraídos — e muitas vezes os primeiros comprados:

Dois padrões se repetem: esses serviços são em sua maioria alimentados por eventos em vez de chamados de forma síncrona, e seus dados muitas vezes são derivados — busca e analytics podem ser reconstruídos a partir da fonte da verdade, o que os torna mais baratos de operar.

Mapa de serviços da BoxOffice

routes:
  - id: auth
    uri: ${AUTH_URL:http://auth:8081}
    predicates:
      - Path=/auth/**
  - id: catalog
    uri: lb://catalog              # "lb": pick one instance of "catalog" per request
    predicates:
      - Path=/catalog/**
  - id: inventory
    uri: ${INVENTORY_URL:http://inventory:8083}
    predicates:
      - Path=/inventory/**

Como se conecta

flowchart LR
    MONO["monólito"] --> MOD["monólito modular"]
    MOD --> MS["microsserviços<br/>quando uma força é real"]
    DDD["DDD: subdomínios,<br/>bounded contexts"] --> MS
    CONWAY["lei de Conway<br/>times moldam serviços"] --> MS
    AGG["agregados<br/>referência por id"] --> OWN
    MS --> OWN["cada serviço é dono dos seus dados<br/>→ Bancos de dados"]
    MS --> TALK["APIs e eventos<br/>→ Estilos de API, Mensageria"]
    OWN --> SAGA["sem transações entre serviços<br/>→ sagas, outbox"]
    HEX["portas e adaptadores"] --> INT["adapters de provedores<br/>→ Integrações"]
    MS --> SHARED["capacidades compartilhadas:<br/>auth, busca, notificações"]

Componentes da paleta: app (cada serviço é a sua própria camada stateless) · apigw (gateway, o ponto único de entrada) · auth · search · notifications · analytics · scheduler (capacidades compartilhadas, muitas vezes compradas) · sql (um banco por serviço, nunca tabelas compartilhadas) · stream (eventos alimentam os serviços derivados). Cenários: monolith, event-fanout, microservices. Continua em: Estilos de API, Bancos de dados (um banco por serviço), Mensageria — padrões (outbox, saga), Distribuídos — transações, Hands-on 1.

Pontos-chave