Trabalho Assíncrono

Quando o pagamento de um pedido é aprovado, a BoxOffice tem muito a fazer: marcar o pedido como confirmado, transformar o hold em assentos vendidos, gerar o PDF do ingresso com um QR code (cerca de 800 ms de CPU), enviá-lo por e-mail pelo provedor (300 ms, às vezes 5 s), mandar uma notificação push, atualizar o painel de vendas e reindexar a disponibilidade para a busca. Se a requisição de checkout fizer tudo isso antes de responder, o fã espera segundos, cada provedor lento deixa o checkout lento, e uma queda do e-mail derruba a venda de ingressos.

Nada desse trabalho muda a resposta que o fã está esperando — "seu pedido está confirmado". Ele pode acontecer um instante depois, em outro lugar. Esta página trata desse "outro lugar": workers que processam jobs de uma fila e schedulers que iniciam trabalho num horário definido — e de como deixar ambos corretos quando jobs são reexecutados e réplicas rodam em paralelo.

O que pertence ao caminho da requisição?

Faça uma pergunta sobre cada etapa: a resposta ao usuário depende dela?

Tudo abaixo da primeira linha vira um job (uma unidade de trabalho descrita por uma mensagem pequena) colocado numa fila e executado por workers (processos que puxam jobs e os executam).

sequenceDiagram
    participant F as Fã
    participant O as order
    participant Q as Fila / Kafka
    participant W as worker de ingressos
    participant N as worker de notificação
    participant E as Provedor de e-mail
    F->>O: POST /orders/ord_9/confirm
    O->>O: pedido CONFIRMED (uma transação no BD)
    O->>Q: OrderConfirmed {orderId: ord_9}
    O-->>F: 200 Seu pedido está confirmado
    Q->>W: gerar ingressos de ord_9
    W->>W: PDF + QR → object store
    W->>Q: TicketsIssued {orderId: ord_9}
    Q->>N: TicketsIssued
    N->>E: enviar e-mail com o link
    E-->>N: 202 na fila

O que você ganha:

• Latência: o checkout responde em dezenas de milissegundos em vez de segundos.
• Disponibilidade: o provedor de e-mail pode ficar fora do ar por 20 minutos; os jobs esperam na fila e o checkout continua vendendo.
• Nivelamento de carga: a fila absorve o pico da abertura de vendas; os workers a esvaziam no próprio ritmo, constante.
• Escala independente: gerar ingressos consome CPU, enviar e-mail é limitado por I/O — cada pool de workers escala por conta própria.

O que você paga: o resultado chega eventualmente, não imediatamente; é preciso mostrar o status ("seus ingressos estão sendo emitidos"), tratar falhas sem um usuário a quem mostrar um erro e tornar cada job seguro para rodar mais de uma vez.

@Transactional
public PlaceResult place(OrderRequest req) {
    int inserted = jdbc.sql("""
            INSERT INTO orders (id, show_id, hold_id, customer_email, amount, status)
            VALUES (?, ?, ?, ?, ?, 'PENDING_PAYMENT')
            ON CONFLICT (hold_id) DO NOTHING
            """)
            .params(UUID.randomUUID(), req.showId(), req.holdId(), req.customerEmail(), req.amount())
            .update();

    OrderView order = jdbc.sql(SELECT + " WHERE hold_id = ?")
            .param(req.holdId())
            .query(OrderView.class)
            .single();

    if (inserted == 0) {
        // same hold already ordered: idempotent replay, no second event
        return new PlaceResult(order, false);
    }

    OrderEvent event = OrderEvent.placed(order);
    if (props.notifyMode() == NotifyMode.SYNC) {
        notifications.send(event); // BEFORE: the fan waits for the e-mail
    } else {
        outbox.append(event.eventId(), "order", order.id(), event.eventType(), event);
    }
    return new PlaceResult(order, true);
}

Quantos workers?

Workers são dimensionados como qualquer servidor, com a Lei de Little: o número de jobs em andamento é igual à taxa de chegada vezes o tempo que cada job leva.

Quando as chegadas superam a capacidade, o excesso se acumula como backlog, e o backlog só é drenado à diferença entre capacidade e chegadas:

O gráfico traz duas lições. Primeiro, uma fila converte um problema de capacidade em atraso: nada falhou com 40 workers, os fãs só esperaram. Segundo, quem está a jusante define o limite real: se o provedor de e-mail aceita no máximo, digamos, 100 mensagens por segundo no seu plano, 500 workers de notificação não enviam mais rápido — só colecionam 429 Too Many Requests. Dimensione o pool de workers pela dependência mais lenta e deixe a fila guardar o resto.

Escale workers pela profundidade da fila ou pelo consumer lag, não pela CPU: um worker esperando um provedor lento não usa CPU, mas também não está livre. Serverless e autoscaling mostra como (KEDA).

Experimente no playground

Abra o cenário async-queue: produtores escrevem numa fila esvaziada por um pool de workers.

1. Rode o perfil spike e observe o backlog e o consumer lag subirem durante a rajada e depois caírem.
2. Dobre as réplicas de workers: o pico do backlog cai e é drenado mais cedo — confira com a fórmula acima.
3. Reduza o rate limit do serviço a jusante: mais workers deixam de ajudar, e aparecem erros no lugar.

Projetando jobs que sobrevivem ao mundo real

Uma fila não é mágica: workers caem no meio de jobs, brokers reentregam, provedores estouram o timeout. A maioria dos brokers oferece entrega at-least-once (pelo menos uma vez): um job só é removido (confirmado, ack) depois que o worker avisa que terminou, então uma queda antes do ack significa que o job será entregue de novo. Todas as regras abaixo decorrem disso.

Uma mensagem envenenada (poison message) é aquela que falha sempre (um payload malformado, um bug). Sem limite de retries, ela é reprocessada para sempre e, em partições ordenadas, bloqueia todas as mensagens atrás dela. A DLQ a estaciona para um humano (ou para uma versão corrigida do código) e deixa a fila seguir. Monitore o tamanho da DLQ: uma DLQ crescendo é um incidente.

Com o Spring for Apache Kafka, retries com backoff e um tópico de dead letter são poucas anotações³:

@Component
class TicketJobListener {

    private final TicketService tickets;

    TicketJobListener(TicketService tickets) { this.tickets = tickets; }

    @RetryableTopic(
        attempts = "4",                                    // 1 try + 3 retries
        backOff = @BackOff(delay = 1000, multiplier = 2.0), // 1 s, 2 s, 4 s (Spring Kafka 4)
        dltTopicSuffix = ".dlt")
    @KafkaListener(topics = "order.confirmed.v1", groupId = "ticket-worker")
    void onOrderConfirmed(OrderConfirmed event) {
        if (tickets.alreadyIssued(event.orderId())) {
            return;                                        // idempotent: duplicate delivery
        }
        tickets.renderAndStore(event.orderId());           // PDF + QR → object store
    }

    @DltHandler
    void onDeadLetter(OrderConfirmed event) {
        tickets.markFailed(event.orderId());               // visible to support; alert on rate
    }
}

Onde os jobs vivem

Os motores de execução durável (durable execution) merecem menção: quando um processo tem muitas etapas e esperas — "evento cancelado → reembolsar 60.000 pedidos → enviar e-mail a cada fã → esperar 7 dias → fechar a contabilidade" — escrevê-lo como um workflow, cujo progresso o motor persiste após cada etapa, é mais simples e mais seguro do que encadear filas à mão⁴.

Schedulers

Parte do trabalho é disparada pelo tempo, não por uma requisição ou um evento:

• a cada 30 s, liberar os holds expirados para que seus assentos possam ser vendidos de novo;
• às 10:00:00, abrir as vendas de um evento;
• 24 h antes de cada show, enviar um lembrete a cada portador de ingresso;
• toda noite, conciliar os pagamentos com o relatório do provedor (integrações).

O problema do cron duplicado

A implementação óbvia é um método @Scheduled no serviço. Funciona com uma réplica. Com 10 réplicas, o job roda 10 vezes: 10 e-mails de lembrete por fã, 10 varreduras concorrentes brigando pelas mesmas linhas. O mesmo acontece com uma entrada de cron copiada em cada VM. Há quatro soluções padrão:

apiVersion: batch/v1
kind: CronJob
metadata:
  name: release-expired-holds
spec:
  schedule: "* * * * *"              # every minute (cron's finest granularity)
  concurrencyPolicy: Forbid          # never two runs at the same time
  startingDeadlineSeconds: 30        # skip a run that could not start in time
  successfulJobsHistoryLimit: 3
  jobTemplate:
    spec:
      backoffLimit: 2
      activeDeadlineSeconds: 50      # kill a run that hangs
      template:
        spec:
          restartPolicy: Never
          containers:
            - name: sweeper
              image: ghcr.io/boxoffice/inventory:1.8.2
              args: ["--job=release-expired-holds"]

@Component
class HoldSweeper {

    private static final Logger log = LoggerFactory.getLogger(HoldSweeper.class);
    private final HoldRepository holds;

    HoldSweeper(HoldRepository holds) { this.holds = holds; }

    @Scheduled(fixedRate = 30_000)
    @SchedulerLock(name = "releaseExpiredHolds",
                   lockAtMostFor = "PT25S",   // lock expires even if this replica dies
                   lockAtLeastFor = "PT5S")   // absorb small clock differences
    void releaseExpiredHolds() {
        int released = holds.releaseExpired(Instant.now(), 5_000);   // batch of 5,000
        log.info("released {} expired holds", released);
    }
}

Locks expiram: fencing tokens

Um lock distribuído com expiração tem uma brecha sutil, descrita por Martin Kleppmann¹: uma réplica obtém o lock e então pausa (uma coleta de lixo longa, uma migração de VM) além da expiração do lock. Outra réplica obtém o lock e inicia o job. A primeira acorda, ainda acreditando que detém o lock, e as duas escrevem.

sequenceDiagram
    participant A as Réplica A
    participant L as Armazenamento de locks
    participant B as Réplica B
    participant DB as Banco de dados
    A->>L: obtém (token 33), expira em 25 s
    Note over A: pausa de GC: 40 s
    B->>L: lock expirado → obtém (token 34)
    B->>DB: libera holds (token 34)
    A->>DB: libera holds (token 33) — ainda acha que tem o lock
    DB-->>A: rejeitado: token 33 < 34 já visto

A correção é um fencing token: o armazenamento de locks entrega um número crescente a cada aquisição, e o recurso protegido rejeita escritas com um token mais antigo. Quando o recurso não consegue verificar tokens, o próprio job precisa ser idempotente — o que você precisa de qualquer forma. Um lock é uma otimização que evita esforço duplicado; a correção tem de vir da idempotência ou do banco de dados (um UPDATE ... WHERE status = 'ACTIVE' AND expires_at < now() condicional libera cada hold no máximo uma vez, não importa quantas varreduras rodem).

Trabalho atrasado: três formas de expirar um hold

Liberar um hold 10 minutos depois de criado é um job atrasado (delayed job). Três designs, muitas vezes combinados:

A regra da BoxOffice: a correção nunca espera pelo scheduler. Um hold cujo expires_at já passou não pode ser confirmado, tenha a varredura rodado ou não (expiração preguiçosa), e uma varredura devolve seus assentos à venda. Se o scheduler ficar fora do ar por 5 minutos, nenhum assento é vendido duas vezes; os assentos dos holds expirados só voltam mais tarde. (Um desenho totalmente preguiçoso vai além: novos holds podem pegar os assentos de um hold expirado na hora, sem esperar a varredura.)

/** Payment succeeded (lab 7 calls this): seats become SOLD. */
@Transactional
public HoldOut confirm(String userId, UUID holdId) {
    int changed = jdbc.sql("""
            UPDATE inventory.holds SET status = 'CONFIRMED'
            WHERE id = :id AND user_id = :userId AND status = 'ACTIVE' AND expires_at > now()""")
            .param("id", holdId).param("userId", userId)
            .update();
    if (changed == 0) {
        throw new ResponseStatusException(HttpStatus.CONFLICT, "hold is not active (expired, released or unknown)");
    }
    jdbc.sql("UPDATE inventory.seats SET status = 'SOLD', version = version + 1 WHERE hold_id = :id")
            .param("id", holdId).update();
    return find(userId, holdId);
}
@Scheduled(fixedDelay = 5000)
@Transactional
public void expireHolds() {
    int freed = jdbc.sql("""
            WITH expired AS (
                UPDATE inventory.holds SET status = 'EXPIRED'
                WHERE id IN (SELECT id FROM inventory.holds
                             WHERE status = 'ACTIVE' AND expires_at < now()
                             ORDER BY expires_at
                             LIMIT 500
                             FOR UPDATE SKIP LOCKED)
                RETURNING id)
            UPDATE inventory.seats
            SET status = 'AVAILABLE', hold_id = NULL, version = version + 1
            WHERE status = 'HELD' AND hold_id IN (SELECT id FROM expired)""")
            .update();
    if (freed > 0) {
        log.info("expired holds freed {} seats", freed);
    }
}

O cenário notification-system combina um scheduler, uma fila e os provedores de e-mail/push. Experimente aumentar o número de jobs do scheduler para simular a rajada de lembretes de 24 horas e observe onde o backlog se acumula.

Abrir o simulador completo

Trade-offs em resumo

Como se conecta

flowchart LR
    RP["caminho da requisição: só o que<br/>a resposta precisa"] --> Q["jobs numa fila<br/>→ Mensageria"]
    Q --> W["workers<br/>taxa × tempo por job"]
    W --> JOB["jobs idempotentes, ack após o trabalho,<br/>retries com backoff"]
    JOB --> DLQ["DLQ para mensagens venenosas"]
    W --> SCALE["escalar pelo atraso da fila<br/>→ Autoscaling"]
    CRON["trabalho agendado<br/>em N réplicas"] --> LOCK["CronJob, lock distribuído,<br/>eleição de líder"]
    LOCK --> FENCE["locks expiram: fencing tokens<br/>→ Consenso distribuído"]
    CRON --> LAZY["expiração preguiçosa + varredor<br/>reservas → Bancos de dados"]

Componentes da paleta: queue (jobs e mensagens atrasadas) · worker (consumidores dimensionados pela lei de Little) · scheduler (cron e trabalho atrasado, uma vez por cluster) · kafka (commit do offset após o trabalho) · sql (a linha do ShedLock, reservas que expiram preguiçosamente) · objstore (PDFs dos ingressos) · notifications · email (o e-mail do ingresso, fora do caminho da requisição). Cenários: async-queue, notification-system. Continua em: Serverless e autoscaling — escalar pela profundidade da fila, Mensageria — filas e pub/sub, Mensageria — semântica de entrega, Distribuídos — consenso (fencing), Hands-on 7.

Pontos-chave