[{"data":1,"prerenderedAt":-1},["ShallowReactive",2],{"$f21wmlpq5z5p6q":3,"$f1k8oxvl7s0h1":161},{"data":4},[5],{"id":6,"slug":7,"locale":8,"type":9,"title":10,"subtitle":11,"summary":12,"body":13,"primary_topic":14,"knowledge_status":15,"practical_validation":16,"workflow_status":17,"author_id":18,"published_at":19,"updated_at":19,"review_due_at":20,"canonical_url":21,"seo_title":10,"seo_description":12,"hero_asset_id":20,"reading_time":22,"version":23,"technology_versions":24,"review_frequency_days":25,"parent_content_id":26,"sort_in_parent":27,"hub_entry_status":28,"content_blocks":29,"hero_alt_text":21,"hero_caption":21,"hero_credit":21,"publication_scope":151,"access_level":152,"approved_at":153,"approved_by":154,"review_note":21,"home_enabled":155,"home_slot":156,"home_variant":157,"home_priority":158,"home_eyebrow":20,"home_valid_from":20,"home_valid_to":20,"home_image_asset_id":20,"promotion_kind":159,"sponsor_name":20,"sponsor_url":20,"sponsor_disclosure":160},"2ff4758d-b587-481f-9dd7-84dd9e7ed081","modernizzazione-legacy-sanitario-resilience-patterns","it","CAPSULE","Resilience Patterns: timeout, retry, circuit breaker e bulkhead","Un sistema distribuito deve assumere che rete, legacy e dipendenze esterne possano rallentare o fallire.","Timeout, Retry, Circuit Breaker e Bulkhead limitano gli effetti a cascata delle dipendenze lente o indisponibili nelle piattaforme distribuite.","Perché la resilienza è parte dell'architettura\nQuando un monolite diventa distribuito, ogni chiamata di rete introduce fallimenti parziali. Un sistema esterno può essere lento senza essere completamente down; un integration engine può saturarsi; un viewer può non rispondere. Senza limiti, una dipendenza lenta consuma thread e connessioni fino a rendere indisponibili servizi altrimenti sani.\nTimeout\nOgni chiamata remota deve avere un timeout coerente con il caso d'uso. Timeout enormi non aumentano affidabilità: trattengono risorse e peggiorano il collasso a cascata. Connect timeout e read\u002Fresponse timeout vanno distinti e osservati.\nRetry\nIl retry è utile per errori transitori, ma deve avere limite, backoff e jitter. Non si ritenta automaticamente un errore funzionale 4xx o un comando non idempotente. Il retry indiscriminato durante un outage può moltiplicare il carico sulla dipendenza già in crisi.\nCircuit Breaker\nIl Circuit Breaker osserva i fallimenti e apre il circuito quando la dipendenza supera una soglia, facendo fail-fast. Dopo un intervallo passa in half-open e prova un numero limitato di richieste. Protegge risorse e riduce latenza durante indisponibilità persistenti.\nBulkhead\nIl Bulkhead isola pool di thread, connessioni o code per impedire che il problema di una dipendenza esaurisca tutte le risorse del servizio. Le integrazioni lente verso un sistema esterno non dovrebbero bloccare anche le API interne sane.\nComposizione corretta\nDefinire timeout realistico.\n\nApplicare retry solo a errori transient e operazioni idempotenti.\n\nProteggere la dipendenza con Circuit Breaker.\n\nIsolare le risorse con Bulkhead.\n\nEsportare metriche: latency, timeout, retry, circuit state e queue saturation.\n\nFallback\nUn fallback non deve inventare dati clinici o restituire silenziosamente informazioni obsolete come se fossero correnti. Può mostrare uno stato degradato, usare una cache esplicitamente marcata o disabilitare una funzione non critica. La degradazione deve essere visibile all'utente e all'osservabilità.\nRegola finale\nRetry senza timeout e idempotenza è spesso un amplificatore di guasti; timeout senza osservabilità è solo un errore più veloce.\n\nResilienza significa fallire in modo controllato e contenuto, non nascondere l'errore. Nei domini sanitari i fallback silenziosi sono particolarmente pericolosi.","58ba728e-da9d-409d-a6c7-31325e3773a8","REVIEWED","NOT_PERFORMED","PUBLISHED","fbbfd4b6-f4c7-4740-94a6-f81eb8fbb1b2","2026-08-25T18:17:32.377Z",null,"",8,4,{},365,"776fc737-dda9-4c82-bd56-b6ba0b7148d6",15,"AVAILABLE",[30,147],{"id":31,"type":32,"version":33,"doc":34},"81f5174e-d9d0-5248-b3ca-bad1607654cc","rich_text",1,{"type":35,"content":36},"doc",[37,45,50,55,59,64,68,73,77,82,86,91,126,131,135,140],{"type":38,"attrs":39,"content":41},"heading",{"level":40},2,[42],{"type":43,"text":44},"text","Perché la resilienza è parte dell'architettura",{"type":46,"content":47},"paragraph",[48],{"type":43,"text":49},"Quando un monolite diventa distribuito, ogni chiamata di rete introduce fallimenti parziali. Un sistema esterno può essere lento senza essere completamente down; un integration engine può saturarsi; un viewer può non rispondere. Senza limiti, una dipendenza lenta consuma thread e connessioni fino a rendere indisponibili servizi altrimenti sani.",{"type":38,"attrs":51,"content":52},{"level":40},[53],{"type":43,"text":54},"Timeout",{"type":46,"content":56},[57],{"type":43,"text":58},"Ogni chiamata remota deve avere un timeout coerente con il caso d'uso. Timeout enormi non aumentano affidabilità: trattengono risorse e peggiorano il collasso a cascata. Connect timeout e read\u002Fresponse timeout vanno distinti e osservati.",{"type":38,"attrs":60,"content":61},{"level":40},[62],{"type":43,"text":63},"Retry",{"type":46,"content":65},[66],{"type":43,"text":67},"Il retry è utile per errori transitori, ma deve avere limite, backoff e jitter. Non si ritenta automaticamente un errore funzionale 4xx o un comando non idempotente. Il retry indiscriminato durante un outage può moltiplicare il carico sulla dipendenza già in crisi.",{"type":38,"attrs":69,"content":70},{"level":40},[71],{"type":43,"text":72},"Circuit Breaker",{"type":46,"content":74},[75],{"type":43,"text":76},"Il Circuit Breaker osserva i fallimenti e apre il circuito quando la dipendenza supera una soglia, facendo fail-fast. Dopo un intervallo passa in half-open e prova un numero limitato di richieste. Protegge risorse e riduce latenza durante indisponibilità persistenti.",{"type":38,"attrs":78,"content":79},{"level":40},[80],{"type":43,"text":81},"Bulkhead",{"type":46,"content":83},[84],{"type":43,"text":85},"Il Bulkhead isola pool di thread, connessioni o code per impedire che il problema di una dipendenza esaurisca tutte le risorse del servizio. Le integrazioni lente verso un sistema esterno non dovrebbero bloccare anche le API interne sane.",{"type":38,"attrs":87,"content":88},{"level":40},[89],{"type":43,"text":90},"Composizione corretta",{"type":92,"attrs":93,"content":94},"orderedList",{"start":33,"type":20},[95,102,108,114,120],{"type":96,"content":97},"listItem",[98],{"type":46,"content":99},[100],{"type":43,"text":101},"Definire timeout realistico.",{"type":96,"content":103},[104],{"type":46,"content":105},[106],{"type":43,"text":107},"Applicare retry solo a errori transient e operazioni idempotenti.",{"type":96,"content":109},[110],{"type":46,"content":111},[112],{"type":43,"text":113},"Proteggere la dipendenza con Circuit Breaker.",{"type":96,"content":115},[116],{"type":46,"content":117},[118],{"type":43,"text":119},"Isolare le risorse con Bulkhead.",{"type":96,"content":121},[122],{"type":46,"content":123},[124],{"type":43,"text":125},"Esportare metriche: latency, timeout, retry, circuit state e queue saturation.",{"type":38,"attrs":127,"content":128},{"level":40},[129],{"type":43,"text":130},"Fallback",{"type":46,"content":132},[133],{"type":43,"text":134},"Un fallback non deve inventare dati clinici o restituire silenziosamente informazioni obsolete come se fossero correnti. Può mostrare uno stato degradato, usare una cache esplicitamente marcata o disabilitare una funzione non critica. La degradazione deve essere visibile all'utente e all'osservabilità.",{"type":38,"attrs":136,"content":137},{"level":40},[138],{"type":43,"text":139},"Regola finale",{"type":141,"content":142},"blockquote",[143],{"type":46,"content":144},[145],{"type":43,"text":146},"Retry senza timeout e idempotenza è spesso un amplificatore di guasti; timeout senza osservabilità è solo un errore più veloce.",{"id":148,"type":149,"version":33,"text":150},"859889c3-5794-574c-ae34-18574e17ca61","callout","Resilienza significa fallire in modo controllato e contenuto, non nascondere l'errore. Nei domini sanitari i fallback silenziosi sono particolarmente pericolosi.","PORTAL","ANONYMOUS","2026-08-25T18:17:31.097Z","794a9185-136c-4415-ab23-cd144eb5870e",false,"LATEST","AUTO",0,"EDITORIAL","Sponsorizzato",{"sources":162,"secondaryTopics":163,"tags":164,"primaryTopic":165,"technologies":169},[],[],[],[166],{"id":14,"name":167,"slug":168},"Software Architecture","software-architecture",[]]