O que é o padrão Pub/Sub (publicação-assinatura)?

Pub/sub é um padrão de mensageria em que publicadores enviam mensagens a tópicos em um broker, e cada assinante do tópico recebe uma cópia. Todo o seu valor está no que as partes não sabem: publicadores nunca descobrem quem está ouvindo, assinantes nunca descobrem quem enviou — a indireção do broker os desacopla no espaço (sistemas diferentes), no tempo (assinantes podem estar offline) e na sincronização (o publish retorna imediatamente). Adicione assinantes sem tocar nos publicadores; esse é o superpoder discreto do padrão.

Principais pontos

O padrão em código

Toda API de pub/sub se reduz a dois verbos, seja qual for o broker:

// Assinantes — registram interesse em um tópico
broker.subscribe('orders.paid', (msg) => fulfill(msg));   // serviço A
broker.subscribe('orders.paid', (msg) => notifyUser(msg)); // serviço B — sua própria cópia

// Publicador — dispara e esquece
broker.publish('orders.paid', { orderId: 'o-1187' });
// O publicador nunca descobre quem recebeu — nem se alguém recebeu.

A mesma forma na borda do cliente, onde uma assinatura de live query é o tópico e uma escrita no banco de dados é o publish:

// JavaScript / Node.js — Back4app JS SDK
// Pub/sub at the edge: live queries subscribe, saves publish
// Subscriber — register interest in a topic
const topic = new Parse.Query('Event');
topic.equalTo('topic', 'orders');
const sub = await topic.subscribe();
sub.on('create', (event) => handle(event.get('payload')));

// Publisher — fire and forget; no knowledge of subscribers
const event = new Parse.Object('Event');
event.set('topic', 'orders');
event.set('payload', { orderId: 'o-1187', status: 'paid' });
await event.save();

// Flutter / Dart — Back4app Flutter SDK
// Pub/sub at the edge: live queries subscribe, saves publish
// Subscriber — register interest in a topic
final liveQuery = LiveQuery();
final topic = QueryBuilder<ParseObject>(ParseObject('Event'))
  ..whereEqualTo('topic', 'orders');
final sub = await liveQuery.client.subscribe(topic);
sub.on(LiveQueryEvent.create, (event) => handle(event.get('payload')));

// Publisher — fire and forget; no knowledge of subscribers
final event = ParseObject('Event')
  ..set('topic', 'orders')
  ..set('payload', {'orderId': 'o-1187', 'status': 'paid'});
await event.save();

// iOS / Swift — Back4app Swift SDK
// Pub/sub at the edge: live queries subscribe, saves publish
// Subscriber — register interest in a topic
let topic = Event.query("topic" == "orders")
let sub = try await topic.subscribe()
sub.handleEvent { _, e in
    if case .created(let event) = e { handle(event.payload) }
}

// Publisher — fire and forget; no knowledge of subscribers
var event = Event()
event.topic = "orders"
event.payload = ["orderId": "o-1187", "status": "paid"]
try await event.save()

// Android / Kotlin — Back4app Android SDK
// Pub/sub at the edge: live queries subscribe, saves publish
// Subscriber — register interest in a topic
val client = ParseLiveQueryClient.Factory.getClient()
val topic = ParseQuery.getQuery<ParseObject>("Event")
topic.whereEqualTo("topic", "orders")
val sub = client.subscribe(topic)
sub.handleEvent(SubscriptionHandling.Event.CREATE) { _, event ->
    handle(event.getJSONObject("payload"))
}

// Publisher — fire and forget; no knowledge of subscribers
val event = ParseObject("Event")
event.put("topic", "orders")
event.put("payload", JSONObject(mapOf("orderId" to "o-1187", "status" to "paid")))
event.save()

Como o pub/sub funciona

O broker faz quatro trabalhos: aceitar publishes e retornar imediatamente; casar cada mensagem com as assinaturas (por nome de tópico, hierarquicamente — orders.* — ou por atributos de conteúdo); entregar uma cópia independente por assinante, com retry conforme o nível de garantia; e reter mensagens para assinantes offline onde a durabilidade estiver configurada — o desacoplamento no tempo que deixa um serviço fazer deploy ao meio-dia e recuperar o que perdeu. Uma nota de vocabulário que vale a frase: uma mensagem é o envelope; um evento — “isto aconteceu, no passado” — é o que o pub/sub normalmente carrega, e se ele carrega só o fato ou o estado completo é a distinção de Fowler entre event notification e event-carried state transfer.

Pub/sub vs. filas de mensagens vs. padrão observer

As duas confusões, resolvidas em uma tabela:

A frase que sobrevive à reunião: uma fila distribui o trabalho; pub/sub o duplica. E observer não é um “pub/sub pequeno” — a indireção do broker é exatamente o que falta ao observer, e por isso refatorar um observer para pub/sub é uma mudança arquitetural, não uma renomeação. Na prática os brokers oferecem as duas formas: consumer groups transformam um tópico em fila por grupo (a jogada de assinatura do Kafka), exchanges de fanout transformam um sistema de filas em pub/sub.

Garantias de entrega: at-most-once vs. at-least-once vs. exactly-once

Os níveis de QoS 0/1/2 do MQTT mapeiam exatamente para esses três — uma confirmação elegante de que a tricotomia é fundamental, não marketing de fornecedor. A verdade de engenharia: exactly-once de ponta a ponta é inatingível no caso geral (o problema dos Dois Generais usando crachá de broker); sistemas que o anunciam combinam entrega at-least-once com deduplicação. Por isso o contrato real do padrão está escrito no seu handler: at-least-once + idempotência — deduplique por ID de mensagem, use upserts com chave na entidade ou cheque a versão antes de aplicar — transforma duplicatas de bugs em no-ops.

Ordenação, dead letters e design de tópicos

Três realidades operacionais que os diagramas introdutórios pulam. Ordenação: fan-out para consumidores paralelos não tem ordem global; brokers a restauram por partição ou chave de ordenação ao preço do paralelismo — desenhe handlers que apliquem eventos por ID e versão da entidade, não pela sequência de chegada, e o problema quase se dissolve. Mensagens venenosas: uma mensagem cujo processamento sempre lança erro vai tentar de novo para sempre sob at-least-once; limite as tentativas de entrega e roteie as falhas para uma fila de dead-letter para triagem, ou um evento ruim trava o tópico. Design de tópicos: nomeie hierarquicamente (orders.paid, orders.refunded, curinga orders.*), mantenha a granularidade no nível em que os assinantes de fato diferem e evolua os schemas de mensagem aditivamente — assinantes ignoram campos desconhecidos; quebras ganham um novo tópico versionado (orders.v2) com janela de migração, exatamente como uma versão de API.

Casos de uso comuns

• Integração de microsserviços — serviços de times diferentes reagindo aos eventos uns dos outros sem chamadas diretas nem agendas de deploy compartilhadas.
• Recursos de tempo real no cliente — fan-out de chat, dashboards ao vivo, presença: pub/sub sobre WebSockets na borda.
• Telemetria de IoT — milhares de dispositivos publicando via MQTT; consumidores de alertas a analytics assinando de forma independente.
• Invalidação de cache e replicação — uma escrita publicada, cada cache e réplica notificados.
• Pipelines de processamento paralelo — um evento disparando fulfillment, notificação e analytics ao mesmo tempo, cada um no próprio ritmo.

Você deveria usar pub/sub? Matriz de decisão

Limitações e trade-offs

• O debug atravessa um broker. “Quem consumiu isto e por que falhou?” exige IDs de correlação e tracing; o desacoplamento que liberta os times também esconde a causalidade.
• Sem respostas, por design. Fluxos que precisam de resposta têm de modelá-la como novas mensagens — latência extra e máquinas de estado onde antes bastava uma chamada de função.
• O broker é infraestrutura. Disponibilidade, capacidade, segurança e políticas de retenção da camada de mensageria viram trabalho de plataforma; um broker fora do ar é um multiplicador de outages.
• A cegueira do publicador corta dos dois lados. Publicadores não observam a saúde dos assinantes; um consumidor falhando em silêncio perde dados, a menos que exista monitoramento de dead-letter.
• Garantias custam throughput. Chaves de ordenação serializam, exactly-once coordena, durabilidade persiste — cada reforço de semântica gasta performance; compre só o que os dados precisam.

Pub/Sub no Back4app

O Back4app é uma plataforma open-source de Backend as a Service (BaaS) que combina banco de dados gerenciado, APIs REST e GraphQL geradas automaticamente, autenticação, armazenamento de arquivos e funções serverless com Cloud Code. O padrão aparece aqui na borda do cliente: as Live Queries são pub/sub em que a query é o tópico — assinantes registram um predicado, qualquer escrita que casar é publicada para cada assinante por uma frota gerenciada de WebSockets, com permissões checadas por assinante e fan-out por conta da plataforma, como nas abas de código acima. Reações server-side se compõem do mesmo jeito: triggers de Cloud Code assinam mudanças de dados (afterSave como assinatura de tópico em espírito), e funções agendadas drenam trabalho publicado como linhas. Para streaming pesado entre serviços você ainda buscaria um broker dedicado como Kafka ou RabbitMQ — mas, para os casos comuns de produto, o transmitir-ao-mudar já vem com o backend.