Queue ou topic?

Use uma queue quando uma mensagem representa trabalho que deve ser processado por um consumidor concorrente do grupo. Use topic com uma ou mais subscriptions quando diferentes consumidores precisam receber sua própria cópia lógica, possivelmente filtrada. Uma assinatura possui seu próprio ciclo de entrega e dead-letter.

O broker desacopla produtor e consumidor no tempo; não decide sozinho o significado de eventos, a ordem de negócio ou como corrigir uma operação parcialmente concluída.

Peek-Lock e settlement da mensagem

No modo Peek-Lock, o consumidor recebe uma mensagem com lock temporário. Depois de processar com sucesso, completa a mensagem; se falhar, pode abandoná-la para nova entrega ou encaminhá-la à dead-letter. Se o lock expirar antes do settlement, a mensagem pode voltar a ser entregue. Isso é uma garantia de entrega com possibilidade de duplicidade, não execução única do efeito externo.

Handlers devem ser idempotentes, usar cancellation tokens e terminar dentro dos limites apropriados. Operações demoradas precisam considerar renovação de lock e desenho do processamento; limites e funcionalidades disponíveis variam conforme tier e configuração, então confirme os requisitos do ambiente antes de fixá-los no código.

Enviar uma mensagem em .NET

Com o pacote oficial Azure.Messaging.ServiceBus, o envio pode ser organizado assim:

await using var client = new ServiceBusClient(connectionString);
ServiceBusSender sender = client.CreateSender("orders");

var message = new ServiceBusMessage(
    BinaryData.FromObjectAsJson(orderCreated))
{
    MessageId = orderCreated.EventId,
    Subject = "OrderCreated",
    CorrelationId = orderCreated.OrderId
};

await sender.SendMessageAsync(message, cancellationToken);

Em aplicações reais, armazene a configuração em mecanismo seguro, reutilize clientes/senders de acordo com o ciclo de vida recomendado pelo SDK e não grave connection strings em código. Defina versão e serialização do contrato, tamanho máximo e estratégia de tratamento de erros.

DLQ, retries e duplicidade

Mensagens rejeitadas repetidamente ou que não podem ser processadas podem acabar na dead-letter queue. Configure observação de contagem e idade, alarme, retenção e um procedimento de inspeção e replay. Corrigir a causa antes do reenvio evita repetir o mesmo erro.

Detecção de duplicidade configurada no broker pode filtrar mensagens repetidas com identificadores dentro de uma janela definida, mas não substitui idempotência no consumidor nem uma estratégia de consistência com o banco. Se a publicação depende de uma gravação local, veja Outbox e Inbox.

Sessões e ordem

Quando operações da mesma entidade precisam ser processadas em ordem, sessões podem agrupar mensagens por SessionId e oferecer exclusividade de processamento da sessão. Essa ordenação reduz paralelismo entre mensagens daquela sessão e exige que a aplicação escolha uma chave adequada. Não assuma uma ordem global entre todas as filas e consumidores.

Quando escolher Service Bus?

Faz sentido quando a organização já opera na Azure, quer reduzir a gestão de infraestrutura do broker e precisa de queues/topics, dead-letter, filtros ou integração com serviços da plataforma. Avalie custo, limites, disponibilidade regional, conectividade, identidade, rede e requisitos de portabilidade. Serviço gerenciado reduz algumas tarefas, não a responsabilidade de operar consumidores e contratos.

Para controle da topologia e roteamento com broker próprio, compare com RabbitMQ. Para retenção e replay de fluxos particionados, compare com Kafka.

Operação e links relacionados

Observe mensagens ativas, dead-letter, latência de entrega, erros de autorização e saúde dos consumidores. Configure retries limitados com backoff, timeouts e concorrência consciente, conforme resiliência. Correlacione mensagens e traces com observabilidade.