Filas e Pub/Sub

Todo ingresso vendido no BoxOffice precisa de um PDF com QR code. Gerá-lo leva cerca de 400 ms de CPU — lento demais para fazer dentro da requisição de compra durante uma flash sale. A solução óbvia é colocar o trabalho em algum lugar e deixar um pool de workers pegá-lo. Esse "algum lugar" é o componente de mensageria mais antigo e mais simples: a fila. Pouco depois, o time de produto pede um e-mail, uma notificação push, uma atualização da busca e um registro de analytics para cada compra — quatro serviços diferentes, cada um precisando da própria cópia. Essa é a segunda forma: publish/subscribe.

Esta página cobre as duas formas, como elas se comportam sob carga, e a fila mais famosa do BoxOffice: a sala de espera que impede dois milhões de fãs de esmagarem o inventário de lugares às 10:00.

Filas ponto a ponto

Uma fila de mensagens guarda mensagens até que um consumidor as pegue. Cada mensagem é entregue a um consumidor; muitos consumidores podem ler a mesma fila, e eles competem pelas mensagens — o padrão competing consumers (consumidores concorrentes)¹. Adicionar consumidores aumenta o throughput sem nenhuma mudança no produtor.

flowchart LR
    order["order"] -->|"GenerateTicketPdf"| q[["fila: ticket-pdf"]]
    q -->|"msg 1"| w1["worker 1"]
    q -->|"msg 2"| w2["worker 2"]
    q -->|"msg 3"| w3["worker 3"]
    w1 --> os[("object store<br/>tickets/*.pdf")]
    w2 --> os
    w3 --> os

A vida de uma mensagem

Uma fila não pode simplesmente apagar uma mensagem quando um consumidor a recebe: o consumidor pode cair no meio do processamento. Por isso a entrega é um protocolo em dois passos — receber e depois confirmar:

1. O consumidor recebe uma mensagem. O broker não a apaga; ele a esconde dos outros consumidores (o SQS chama isso de visibility timeout; o RabbitMQ a mantém como não confirmada no canal daquele consumidor).
2. O consumidor a processa e envia uma confirmação (ack). Só então a mensagem é apagada.
3. Se o consumidor cai, ou se o visibility timeout expira antes do ack, a mensagem volta a ficar visível e outro consumidor a recebe.

sequenceDiagram
    participant Q as fila ticket-pdf
    participant W1 as worker 1
    participant W2 as worker 2
    Q->>W1: GenerateTicketPdf (pedido o-7731)
    Note over Q: mensagem escondida por 30 s
    W1->>W1: gera o PDF...
    Note over W1: cai antes do ack
    Note over Q: 30 s sem ack: visível de novo
    Q->>W2: GenerateTicketPdf (pedido o-7731), entrega nº 2
    W2->>W2: gera o PDF, faz upload
    W2->>Q: ack
    Note over Q: mensagem apagada

Esse protocolo dá entrega at-least-once: nenhuma mensagem se perde quando um worker morre, mas uma mensagem pode ser processada duas vezes (o worker 1 pode ter feito upload do PDF logo antes de cair). Todo consumidor de fila precisa, portanto, ser idempotente — veja Semântica de entrega. Aqui é fácil: o PDF é salvo com um nome determinístico (tickets/o-7731.pdf), então gravá-lo duas vezes dá o mesmo resultado.

Ordenação

Com consumidores concorrentes, a ordem não é preservada: a mensagem 2 pode terminar antes da mensagem 1 porque elas rodam em workers diferentes. Para a maioria dos jobs (PDFs, e-mails) isso não é problema. Quando é, você precisa de um jeito de serializar mensagens relacionadas:

• Filas FIFO com id de grupo (MessageGroupId no SQS FIFO, sessions no Azure Service Bus): mensagens do mesmo grupo são entregues em ordem, uma de cada vez; grupos diferentes rodam em paralelo.
• Um log particionado com chave pela entidade — Kafka, na próxima página — dá o mesmo comportamento "ordenado por chave, paralelo entre chaves" com alto throughput.

Dimensionando o pool de workers

A Lei de Little (veja Filas) diz quantos workers acompanham uma taxa de chegada estável: o número de jobs em andamento é a taxa de chegada vezes o tempo que cada um leva.

Backpressure

Backpressure é qualquer mecanismo pelo qual um consumidor lento faz um produtor rápido desacelerar — ou pelo menos faz o sistema perceber que não está dando conta. Sem isso, uma fila entre um produtor rápido e um consumidor lento é só um lugar onde o problema cresce em silêncio.

Uma fila que pode crescer sem limite é uma ilusão: a memória ou o disco acabam em algum momento, e muito antes disso as mensagens do fim da fila ficam velhas (um push "seus lugares estão reservados" que chega duas horas depois é pior que nenhum). Toda fila precisa de uma resposta para "o que acontece quando ela enche?"²:

A sala de espera da flash sale

Às 10:00, dois milhões de fãs chegam para 60.000 lugares. O inventory consegue reservar lugares com segurança (com locks de linha, veja Transações) a cerca de 1.100 reservas por segundo — a ordem de grandeza da estimativa da aula 2, contra 33.000 que chegam; você o mediria com um teste de carga. Deixar todo mundo bater no caminho de compra ao mesmo tempo não vende ingressos mais rápido; faz o banco de dados entrar em colapso e o site inteiro falhar.

A sala de espera virtual é uma fila colocada na frente do fluxo de compra, na borda:

1. Os fãs que chegam recebem uma posição na sala de espera em vez da página de compra.
2. Um job de admissão libera os fãs a uma taxa controlada, ajustada ao que o inventory aguenta com margem.
3. Um fã admitido recebe um token de admissão assinado e de vida curta; o gateway rejeita chamadas de compra sem ele.
4. Quando o inventário chega a zero, a sala de espera avisa todos que ainda esperam que "esgotou" — de forma barata, pela borda, sem tocar no banco de dados.

sequenceDiagram
    participant F as Fã
    participant W as sala de espera (borda)
    participant R as Redis (fila)
    participant G as gateway
    participant I as inventory
    F->>W: GET /events/ev-88/buy (10:00:01)
    W->>R: ZADD room:ev-88 score=chegada fan-123
    W-->>F: posição 512.384 (cerca de 17 min)
    loop a cada 15 s
        F->>W: GET /room/status
        W->>R: ZRANK room:ev-88 fan-123
        W-->>F: posição 30.112
    end
    Note over R: job de admissão: 500 fãs/s
    W-->>F: admitido + token (válido por 10 min)
    F->>G: POST /holds (Authorization: token de admissão)
    G->>I: reserva lugares B-12, B-13
    I-->>F: reservados até 10:21

A fila em si pode ser bem simples. Um sorted set do Redis ordenado por horário de chegada dá posições em \(O(\log n)\):

# a fan joins (score = arrival time in ms; NX: joining twice keeps the first position)
ZADD room:ev-88 NX 1804406400123 fan-123

# where am I? (0-based rank)
ZRANK room:ev-88 fan-123

# admission job, once per second: let the next 500 fans in
ZPOPMIN room:ev-88 500

# how many are still waiting?
ZCARD room:ev-88

Decisões de projeto que vale discutir:

• Taxa de admissão. É um número de capacidade, não um chute: o throughput medido do inventory × um fator de segurança (digamos 50%): cerca de 1.100 × 0,5 ≈ 500 fãs/s, a taxa usada acima. Ela pode se adaptar: reduzir as admissões quando o p99 ou a taxa de erros do inventory sobem — um laço de realimentação.
• Justiça. FIFO estrito premia quem tem a menor latência até o data center (e os bots). Muitos sites de ingressos dão aos fãs que chegaram antes do horário de abertura uma posição aleatória às 10:00, e só usam FIFO depois disso.
• Bots. A sala de espera é o lugar de exigir um desafio e aplicar detecção de bots e limites por conta (veja Tráfego e borda).
• Expiração da reserva. A admissão dá ao fã um direito de compra com prazo; a reserva dos lugares expira (aqui, depois de 10 minutos) e os lugares voltam para o estoque. Isso é um timer — outro job assíncrono.
• Onde roda. As posições são servidas pela borda (funções de CDN ou um serviço pequeno, escalado horizontalmente, com Redis), então o polling de dois milhões de navegadores nunca chega aos serviços centrais.

public Ticket join(String showId) {
    String ticket = UUID.randomUUID().toString();
    Long arrival = redis.opsForValue().increment(seq(showId)); // the server decides the order
    redis.opsForZSet().add(queue(showId), ticket, arrival);
    return status(showId, ticket);
}
/** ZPOPMIN + SET in one Lua script: a polling fan never sees a ticket that is neither queued nor admitted. */
private static final RedisScript<Long> POP_AND_ADMIT = RedisScript.of("""
        local popped = redis.call('ZPOPMIN', KEYS[1], ARGV[1])
        for i = 1, #popped, 2 do
            redis.call('SET', ARGV[2] .. popped[i], '1', 'EX', ARGV[3])
        end
        return #popped / 2
        """, Long.class);

/** Runs on ONE instance only (see pitfalls): N replicas would admit N times the rate. */
@Scheduled(fixedRate = 1000)
public void admit() {
    Set<String> shows = redis.opsForSet().members(OPEN_SHOWS);
    if (shows == null) {
        return;
    }
    for (String showId : shows) {
        redis.execute(POP_AND_ADMIT, List.of(queue(showId)), String.valueOf(props.admitPerSecond()),
                admitted(showId, ""), String.valueOf(props.admissionTtl().toSeconds()));
    }
}

public boolean mayEnter(String showId, String ticket) {
    if (!isOpen(showId)) {
        return true; // no on-sale running for this show: no gate
    }
    return ticket != null && Boolean.TRUE.equals(redis.hasKey(admitted(showId, ticket)));
}

Publish/subscribe

No publish/subscribe (pub/sub) o produtor publica em um tópico, e cada assinatura desse tópico recebe a própria cópia de toda mensagem³. Dentro de uma assinatura, os consumidores competem como em uma fila; entre assinaturas, cada assinatura vê tudo. Na prática, cada assinatura é uma fila que o broker preenche automaticamente.

flowchart LR
    order["order"] -->|"OrderConfirmed"| t{{"tópico: order-events"}}
    t --> s1[["assinatura: notification"]]
    t --> s2[["assinatura: search"]]
    t --> s3[["assinatura: analytics"]]
    s1 --> n1["notification #1"]
    s1 --> n2["notification #2"]
    s2 --> se["indexador da busca"]
    s3 --> an["carregador do analytics"]

Adicionar um quarto consumidor — digamos, um programa de fidelidade que dá pontos — é uma nova assinatura. O serviço order não muda, não é reimplantado e nem fica sabendo. Esse é o principal motivo para usar pub/sub: o produtor fica desacoplado do conjunto de consumidores.

Push ou pull

Filtragem e roteamento

Nem todo assinante quer toda mensagem. Os brokers deixam uma assinatura declarar um filtro sobre atributos da mensagem, de modo que só as mensagens que casam são copiadas para ela — por exemplo, o serviço de SMS assina apenas eventos OrderConfirmed cujo atributo channel é sms. O RabbitMQ generaliza isso com exchanges: uma exchange fanout copia para toda fila ligada a ela, uma direct roteia por uma routing key exata, e uma topic roteia por padrões como order.*.br.

Pub/sub durável e efêmero

Alguns sistemas pub/sub não armazenam mensagens: o Redis Pub/Sub e o NATS core entregam uma mensagem apenas aos assinantes conectados naquele momento. Se um assinante está fora do ar, ele simplesmente perde a mensagem. Isso é perfeito para indicadores de "usuário está digitando…" em um chat e inaceitável para confirmações de pedido. O pub/sub durável (Google Cloud Pub/Sub, SNS → SQS, NATS JetStream, Kafka) guarda as mensagens de cada assinatura até serem confirmadas.

Fila, pub/sub ou log?

A próxima página apresenta a terceira forma, o log (Kafka, Kinesis). A tabela resume as três; a pergunta principal é o que acontece com uma mensagem depois que ela é lida.

Produtos

Como se conecta

flowchart LR
    P["produtor: order"] --> Q["fila<br/>consumidores concorrentes"]
    Q --> ACK["receber, depois ack<br/>visibility timeout"]
    ACK --> ALO["pelo menos uma vez<br/>→ Semântica de entrega"]
    Q --> LL["pool de workers pela<br/>Lei de Little → Estimativas"]
    Q --> BP["backpressure: limitar,<br/>escalar, rejeitar, descartar"]
    BP --> AGE["idade da mensagem mais antiga<br/>→ SLO de atualidade"]
    WR["sala de espera<br/>sorted set no Redis"] --> TOK["token de admissão<br/>validado no gateway"]
    TOK --> INV["reservas do inventory no SQL<br/>→ Bancos de dados"]
    P --> T["tópico pubsub"]
    T --> SUBS["uma assinatura<br/>por serviço consumidor"]
    T --> LOG["precisa de replay ou ordem por chave?<br/>→ Kafka"]

Componentes da paleta: queue · pubsub · worker · objstore (os PDFs) · cache (sala de espera no Redis) · apigw (rejeita chamadas sem token de admissão) · waf (bots na sala de espera) · sql (inventory) · notifications (uma assinatura). Cenários: async-queue, flash-sale, notification-system, chat (pub/sub efêmero). Continua em: Kafka e logs de eventos, Semântica de entrega, Compute — trabalho assíncrono, Estimativas — filas, Observabilidade — SLOs, Tráfego e borda — WAF e bots, Hands-on 7 — sala de espera.