Core Concepts

Publish-Subscribe, comunicazione asincrona, broker e disaccoppiamento publisher/consumer: le fondamenta prima dei pattern avanzati.

Approfondimento

Definizioni, contesto e collegamenti tra concetti — leggi prima del palcoscenico interattivo se parti da zero.

Publish–Subscribe e fan-out

Nel modello pub/sub il publisher non indirizza i destinatari per nome: pubblica su un canale (topic, routing key, exchange) e il broker consegna a tutti gli subscriber interessati. È fan-out naturale: un solo evento può alimentare fatturazione, analytics, notifiche e cache invalidation.

Nel browser, l’analogo più vicino è spesso SSE o WebSocket verso un gateway che fa da subscriber verso il mondo backend. L’Observer pattern in memoria è pub/sub intra-processo; l’EDA estende lo stesso principio oltre il confine del singolo deploy.

Broker, code e disaccoppiamento temporale

Il broker è un componente infrastrutturale che riceve, persiste (a seconda del prodotto) e riconsegna messaggi. Introduce latenza e un nuovo punto di osservabilità, ma rimuove l’accoppiamento temporale: il consumer può essere momentaneamente offline e recuperare messaggi, se il modello di consegna lo consente.

Accoppiamento spaziale: il publisher non conosce l’URL del consumer. Accoppiamento temporale: il publisher non deve attendere che il consumer finisca. Queste libertà si pagano con complessità operativa e con la necessità di contratti chiari sugli eventi.

Semantiche di consegna (lettura obbligatoria)

At-most-once: un messaggio può perdersi, non ci sono duplicati. At-least-once: può arrivare più volte; il consumer deve essere idempotente o deduplicare con un ID stabile. Exactly-once end-to-end tra più sistemi è spesso un obiettivo marketing: in pratica si compone exactly-once “per effetto” con transazioni locali, idempotenza e offset commit cauti.

Le garanzie dipendono dal broker, dal protocollo e dal modo in cui fai ack: in RabbitMQ nack/requeue e DLX cambiano il comportamento; in Kafka commit offset e rielaborazione cambiano cosa significa “processato”.

Palcoscenico

Order API

Pubblica `order.placed`

Event Bus

Notifiche

Fatturazione

Magazzino

Messaggio replicato in parallelo verso consumer indipendenti

Diagramma

Contratto e codice

Schema JSON basato su CloudEvents 1.0, poi snippet server e client.

{
  "specversion": "1.0",
  "source": "/orders-service",
  "id": "550e8400-e29b-41d4-a716-446655440000",
  "time": "2026-05-13T12:00:00.000Z",
  "datacontenttype": "application/json",
  "type": "com.example.messaging.topic.subscribed",
  "data": {
    "topic": "orders.placed",
    "subscriberId": "billing-svc",
    "qos": "at-least-once"
  }
}