Worker asincroni per aggiornamenti di catalogo ad alto volume

Aggiornare poche decine di prodotti è banale. Aggiornarne decine o centinaia di migliaia — con cambi di prezzo, stock e attributi che arrivano a ondate — richiede un'architettura pensata per il volume. I worker asincroni sono il modo standard per farlo in modo controllato.

Perché non farlo in linea

Elaborare un grande catalogo dentro una singola richiesta o un singolo job monolitico porta a timeout, picchi e fallimenti totali al primo errore. Spezzare il lavoro in unità piccole e indipendenti, messe in coda e processate da worker, rende il sistema resiliente e scalabile.

Code e unità di lavoro

Ogni cambiamento (un prodotto, un gruppo di varianti, un batch) diventa un messaggio in coda. I worker consumano i messaggi in parallelo. Vantaggi: i fallimenti isolano la singola unità (e finiscono in dead-letter), il carico si distribuisce, e si può riprendere da dove ci si era fermati.

Batching: il giusto compromesso

Chiamare l'API una volta per prodotto è inefficiente; mandare tutto in un colpo è rischioso. Il batching raggruppa N elementi per chiamata, sfruttando le operazioni bulk dei marketplace (es. operazioni Feed/bulk di eBay). La dimensione del batch va calibrata su limiti API e dimensione dei payload.

Concorrenza controllata

Leva	Effetto
Numero di worker	Quanti messaggi in parallelo
Max parallelismo per host	Evita di saturare CPU/connessioni
Rate limiter condiviso	Rispetta il budget API globale
Dimensione batch	Bilancia throughput e rischio

L'obiettivo è massimizzare il throughput senza superare i limiti dei sistemi a valle.

Operazioni bulk e asincrone

Molti marketplace offrono operazioni massive asincrone: si carica un set di modifiche e si riceve un job da monitorare. I worker devono saper inviare il batch, tracciare il job e leggere l'esito per ogni elemento, riportando i fallimenti per la rilavorazione.

Ripresa dai fallimenti

In un aggiornamento di massa qualcosa fallirà sempre. La chiave è la granularità: un errore su un prodotto non deve invalidare l'intero lotto. Con messaggi indipendenti, idempotenza e dead-letter, gli elementi falliti si rielaborano senza ripartire da zero.

Architettura su Azure

Su Microsoft Azure: una coda Service Bus per le unità di lavoro, Azure Functions o container come worker con parallelismo configurato, un rate limiter condiviso, e storage per stato e log. Una Function di orchestrazione può suddividere un grande aggiornamento in batch e seguirne l'avanzamento.

Errori comuni

• job monolitici che falliscono interi al primo errore;
• una chiamata per prodotto, inefficiente e lenta;
• concorrenza illimitata che satura API e infrastruttura;
• nessuna ripresa granulare dai fallimenti.

Conclusione

I worker asincroni con code, batching, concorrenza controllata e ripresa granulare sono il modo affidabile per aggiornare cataloghi ad alto volume. Trasformano un'operazione rischiosa in un processo prevedibile e monitorabile, anche con centinaia di migliaia di prodotti.