Tassonomia · Tag
Messaggistica
20 risorse pubbliche collegate a “Messaggistica”.
Issue
Inbox Pattern e consumer idempotenti
Come evitare effetti di business duplicati quando retry e redelivery sono normali, non eccezioni
· 5 min
Issue
Claim Check Pattern: tenere piccoli i messaggi, senza perdere governance
Quando il payload non deve viaggiare nel broker: reference, ownership e controlli da chiarire prima di andare in produzione
· 5 min
Issue
Transactional Outbox: pubblicare eventi senza perdere coerenza
Quando un servizio deve aggiornare il proprio database e notificare altri sistemi, il punto non è solo “mandare il messaggio”: è farlo in modo affidabile e misurabile.
· 5 min
Issue
Event-driven: non è il broker a fare l’architettura
Capire quando stai davvero modellando eventi di business e quando stai solo spostando messaggi tecnici
· 5 min
Topic
Claim Check Pattern
Usare il Claim Check pattern per mantenere i messaggi piccoli e sicuri, archiviando payload grandi o sensibili all’esterno e passando riferimenti attraverso il flusso di messaggistica.
Architettura tecnica · Media
Topic
Consumer concorrenti
Scalare l’elaborazione dei messaggi con più consumer preservando esplicitamente le assunzioni su delivery, ordering, concorrenza e idempotenza.
Architettura tecnica · Medio-alta
Topic
Router basato sul contenuto
Progettare regole esplicite e osservabili per instradare messaggi verso canali o consumer differenti in base al loro contenuto.
Architettura tecnica · Media
Topic
Dead Letter Channel
Progettare un Dead Letter Channel che separi i messaggi non processabili dal traffico sano e renda espliciti diagnosi, correzione e replay.
Architettura tecnica · Media
Topic
Event-driven architecture non significa solo messaggistica
Distinguere un evento di dominio da una notifica tecnica e capire quando una soluzione è davvero event-driven.
Architettura tecnica · Media
Topic
Inbox Pattern e consumer idempotenti
Progettare consumer di messaggi in modo che retry, consegne duplicate e fallimenti parziali non producano effetti di business duplicati e indesiderati.
Architettura tecnica · Medio-alta
Topic
Transactional Outbox
Progettare un flusso affidabile di pubblicazione eventi quando un servizio deve aggiornare il proprio database e pubblicare un messaggio senza affidarsi a transazioni distribuite.
Architettura tecnica · Medio-alta
Asset
Claim Check Pattern
Il Claim Check Pattern evita di trasportare payload grandi o sensibili dentro i messaggi, sostituendoli con un riferimento a uno store autorevole.
Concetto
Asset
Competing Consumers: scalare il consumo senza perdere controllo
Competing Consumers distribuisce i messaggi tra più istanze consumer per aumentare throughput e resilienza, esplicitando gli effetti su concorrenza, ordering e idempotenza.
Pratica
Asset
Content-Based Router: instradare con regole esplicite
Il Content-Based Router sceglie il canale o consumer in base a proprietà esplicite del messaggio, rendendo centralizzate e osservabili le decisioni di routing.
Pratica
Asset
Dead Letter Channel: rendere espliciti diagnosi e replay
Il Dead Letter Channel separa i messaggi non processabili dal flusso sano e conserva le evidenze necessarie per diagnosi, correzione e replay controllato.
Pratica
Asset
Inbox Pattern e consumer idempotenti
L'Inbox Pattern aiuta un consumer a gestire messaggi duplicati, retry e fallimenti parziali senza produrre effetti di business doppi.
Pratica
Asset
Messaging non basta per essere event-driven
Usare un broker come canale tecnico non garantisce autonomia, disaccoppiamento o chiarezza semantica.
Anti-pattern
Asset
Transactional Outbox: rendere atomici stato ed evento
Il Transactional Outbox registra l’evento nella stessa transazione del cambiamento di business e ne demanda la pubblicazione affidabile a un processo separato.
Pratica
Integrazione