---
term: 'Orchestrazione di API'
seoTitle: 'Orchestrazione di API: saga, latenza, gateway vs. BFF'
headline: 'Che cos''è l''orchestrazione di API?'
slug: orchestrazione-di-api
category: backend-compute
shortDefinition: 'L''orchestrazione di API è un pattern in cui un livello di coordinamento chiama più API in sequenza e restituisce un unico risultato combinato.'
relatedTerms:
  - api-gateway-architecture
  - event-driven-architecture
  - webhooks
  - microservices-vs-monolith
contrastsWith:
  - api-gateway-architecture
aboutTerms:
  - 'Orchestrator'
  - 'Saga / Compensation'
  - 'API Composition'
faq:
  - question: 'Che cos''è l''orchestrazione di API?'
    answer: 'Coordinare più chiamate API dentro un unico workflow governato: arriva una sola richiesta, l''orchestratore chiama ogni servizio di backend nell''ordine giusto con i dati giusti – gestendo dipendenze, trasformazioni, retry ed errori – e ne esce una sola risposta combinata. Il direttore d''orchestra, con le API come sezioni.'
  - question: 'Qual è la differenza tra orchestrazione e coreografia?'
    answer: 'L''orchestrazione poggia su un coordinatore centrale che comanda i servizi e tiene traccia dello stato – visibile, debuggabile e punto di accoppiamento. La coreografia non ha coordinatore: i servizi reagiscono agli eventi degli altri – disaccoppiamento massimo, ma il workflow non esiste esplicitamente in nessun punto. La regola: orchestrare quando qualcuno deve rispondere del risultato; coreografare quando ai produttori davvero non importa cosa accade dopo.'
  - question: 'Un API gateway è un orchestratore?'
    answer: 'No – un gateway è un reverse proxy che gestisce gli aspetti trasversali di ogni richiesta: autenticazione, rate limiting, routing. L''orchestrazione governa una logica di workflow a più passi, con stato fra un passo e l''altro. Un gateway può fare un''aggregazione leggera delle risposte; nell''istante in cui il passo due dipende dall''output del passo uno, si è usciti dal territorio del gateway.'
  - question: 'Qual è la differenza tra orchestrazione e aggregazione?'
    answer: 'Lo stato. L''aggregazione (composizione di API) lancia chiamate indipendenti in fan-out – di solito in parallelo – e fonde le risposte; nessuna chiamata dipende da un''altra. L''orchestrazione è sequenziale e condizionale: l''input del passo N viene dall''output del passo N−1, i fallimenti esigono una compensazione, e il flusso stesso è logica.'
  - question: 'Qual è un esempio di orchestrazione di API?'
    answer: 'Il checkout, per antonomasia: validare il carrello, riservare la merce, addebitare la carta, creare la spedizione, inviare la conferma – cinque API, ordine stretto, e un fallimento in qualsiasi passo deve disfare ciò che è venuto prima. La prenotazione di viaggi e l''onboarding degli utenti seguono lo stesso schema.'
  - question: 'Come si gestisce un fallimento in mezzo a un flusso orchestrato?'
    answer: 'Fra servizi non esiste alcun rollback – una carta addebitata non si ri-accredita perché la spedizione è andata in errore. Il pattern saga risponde con azioni compensative: disfare in modo esplicito i passi già completati (rimborsare l''addebito, liberare la prenotazione), ritentare i fallimenti transitori con chiavi di idempotenza perché un addebito ripetuto non fatturi due volte, e delimitare ogni passo con un timeout.'
  - question: 'Quando conviene usare l''orchestrazione di API?'
    answer: 'Quando un client dovrebbe altrimenti concatenare tre o più chiamate dipendenti, quando i passi esigono un ordine e una gestione degli errori comune, oppure quando le reti mobili rendono costosi i round trip più chiacchieroni. Da evitare per le chiamate a un solo servizio e per le letture puramente parallele – quella è aggregazione, ed è più semplice.'
  - question: 'Serve un motore di workflow, o basta una funzione?'
    answer: 'Una semplice funzione lato server basta per i flussi brevi e sincroni – pochi passi, pochi secondi, e un fallimento restituisce un errore al client. I motori di workflow durevoli giustificano il proprio peso quando i flussi sono di lunga durata, devono sopravvivere ai riavvii oppure richiedono retry pianificati e passi di approvazione umana.'
codeLanguages: [javascript, dart, swift, kotlin]
externalAuthorities:
  - name: 'API Composition pattern — microservices.io'
    url: 'https://microservices.io/patterns/data/api-composition.html'
  - name: 'Saga pattern — microservices.io'
    url: 'https://microservices.io/patterns/data/saga.html'
  - name: 'Process Manager — Enterprise Integration Patterns'
    url: 'https://www.enterpriseintegrationpatterns.com/patterns/messaging/ProcessManager.html'
  - name: 'Backends For Frontends — Sam Newman'
    url: 'https://samnewman.io/patterns/architectural/bff/'
cta:
  title: 'L''orchestratore che hai già'
  text: 'Una funzione Cloud Code di Back4app è orchestrazione leggera in un solo file: chiama pagamento, magazzino e spedizione con chiavi conservate lato server, compensa in caso di errore e restituisci al client una sola risposta pulita.'
  linkText: 'Inizia gratis'
  linkUrl: 'https://www.back4app.com/signup'
author: 'Back4app Engineering'
publishedDate: '2026-10-19'
translationKey: api-orchestration
---

**L'orchestrazione di API è un pattern in cui un livello di coordinamento chiama più API in sequenza e restituisce un unico risultato combinato.** La metafora del direttore d'orchestra è universale perché è esatta: ogni API suona la propria parte, ma la *partitura* – l'ordine, le dipendenze, cosa accade quando gli ottoni cedono – appartiene all'orchestratore. Una confusione da dissipare subito: metà del settore usa "orchestrazione" per indicare ciò che fa la propria categoria di prodotto (gateway, piattaforme di automazione, motori di workflow e router GraphQL rivendicano tutti la parola). Questa voce indica il pattern in sé – e districa i prodotti più sotto.

## Punti chiave

| Domanda | Risposta |
| --- | --- |
| La forma | Una richiesta in entrata → chiamate ordinate e condizionali → una sola risposta |
| vs. aggregazione | L'aggregazione lancia letture parallele stateless; l'orchestrazione è una sequenza con stato |
| vs. coreografia | Comando centrale vs. [reazione distribuita agli eventi](/glossary/it/architettura-orientata-agli-eventi/) |
| La verità sui fallimenti | Fra servizi non esiste alcun rollback – la compensazione (le saga) è la risposta |
| La leva sulla latenza | Parallelizzare tutto ciò che il grafo delle dipendenze non vieta |

## Il checkout, orchestrato

**JavaScript:**

```javascript
// JavaScript — Cloud Code (cloud/main.js)
// Lightweight orchestration: one function owns the checkout flow
Parse.Cloud.define('checkout', async (req) => {
  const { cartId } = req.params;

  // Independent lookups run in PARALLEL (~200 ms, not 400)
  const [cart, address] = await Promise.all([
    loadCart(cartId),
    loadAddress(req.user),
  ]);

  const reservation = await reserveInventory(cart);        // step 1
  try {
    const charge = await chargeCard(req.user, cart, {
      idempotencyKey: cartId,                              // safe to retry
    });
    const shipment = await createShipment(charge, address); // step 3
    return { orderId: shipment.orderId };                  // one response out
  } catch (e) {
    await releaseInventory(reservation); // compensate — no rollback exists
    throw e;
  }
});
```

**Flutter:**

```dart
// Flutter / Dart — Back4app Flutter SDK
// The client sees ONE call — the orchestrator owns the sequence
final result = await ParseCloudFunction('checkout')
    .execute(parameters: {'cartId': cartId});
showConfirmation(result.result['orderId']);
// Without orchestration this screen would call payment, inventory,
// and shipping itself — three round trips, and the error handling too.
```

**Swift:**

```swift
// iOS / Swift — Back4app Swift SDK
// The client sees ONE call — the orchestrator owns the sequence
let result: [String: String] = try await Cloud.run(
    name: "checkout", parameters: ["cartId": cartId])
showConfirmation(result["orderId"] ?? "")
// Without orchestration this screen would call payment, inventory,
// and shipping itself — three round trips, and the error handling too.
```

**Kotlin:**

```kotlin
// Android / Kotlin — Back4app Android SDK
// The client sees ONE call — the orchestrator owns the sequence
val params = mapOf("cartId" to cartId)
val result = ParseCloud.callFunction<Map<String, Any>>("checkout", params)
showConfirmation(result["orderId"] as String)
// Without orchestration this screen would call payment, inventory,
// and shipping itself — three round trips, and the error handling too.
```

Tutto il pattern sta in una funzione: le letture indipendenti parallelizzate, i passi dipendenti messi in sequenza, una chiave di idempotenza che rende ripetibile senza rischio il passo pericoloso, e una compensazione nel blocco catch – perché la prenotazione della merce non si annulla da sola quando la carta viene rifiutata.

```mermaid
flowchart LR
  accTitle: Flusso di checkout orchestrato con compensazione in caso di fallimento
  accDescr: Una sola richiesta del client raggiunge l'orchestratore, che esegue in parallelo le letture indipendenti e poi mette in sequenza i passi dipendenti: riservare la merce, addebitare la carta, creare la spedizione. Un fallimento dopo la prenotazione fa scattare una liberazione compensativa della merce prima che l'errore torni al client, perché fra servizi non esiste alcun rollback automatico.
  C["Client<br/>una sola chiamata"] --> O["Orchestratore"]
  O -->|"in parallelo"| L1["Carica il carrello"]
  O -->|"in parallelo"| L2["Carica l'indirizzo"]
  L1 --> S1["1 · Riserva la merce"]
  L2 --> S1
  S1 --> S2["2 · Addebita la carta<br/>(chiave di idempotenza)"]
  S2 -->|"ok"| S3["3 · Crea la spedizione"] --> R["Una sola risposta"]
  S2 -.->|"fallisce"| X["Compensa:<br/>libera la prenotazione"] -.-> E["Errore al client"]
```

## Gateway vs. BFF vs. aggregazione vs. orchestrazione vs. coreografia

La tabella a cinque voci che nessun singolo concorrente offre:

| | Che cos'è | Stato fra i passi | Dove vive la logica | Esempio |
| --- | --- | --- | --- | --- |
| [API gateway](/glossary/it/api-gateway/) | Reverse proxy per gli aspetti trasversali | Nessuno | Configurazione: autenticazione, rate limiting, routing | Un unico punto d'ingresso per tutte le API |
| [BFF](/glossary/it/api-gateway/) | Backend dedicato a un client | Per richiesta | Rimodellare per un solo frontend | BFF mobile che alleggerisce i payload |
| Aggregazione / [composizione](https://microservices.io/patterns/data/api-composition.html) | Fan-out parallelo + fusione | **Nessuno – stateless** | Un join in memoria | Dashboard che legge 4 servizi |
| **Orchestrazione** | Workflow comandato a più passi | **Sì – il passo N alimenta il passo N+1** | La sequenza e la logica di errore dell'orchestratore | Checkout, onboarding |
| Coreografia | Servizi che reagiscono a eventi | Distribuito, implicito | Ogni consumatore, [senza cervello centrale](/glossary/it/architettura-orientata-agli-eventi/) | Eventi d'ordine diffusi in fan-out |

Le ultime due righe formano la coppia essenziale, rispecchiata nella [voce sull'EDA](/glossary/it/architettura-orientata-agli-eventi/) con la stessa regola: **orchestrare quando qualcuno deve rispondere del risultato di un workflow; coreografare quando ai produttori davvero non importa cosa accade dopo.** Gli orchestratori parlano per *comandi* (imperativi, rifiutabili); la coreografia parla per *eventi* (fatti al passato) – la stessa distinzione, alla scala dell'architettura.

## Quando fallisce il passo 3 su 5

La sezione che i risultati di ricerca saltano, e la ragione per cui l'orchestrazione è ingegneria anziché idraulica. I passi distribuiti non hanno **alcuna transazione condivisa**: un addebito già andato a buon fine non può essere annullato da un database che non ne ha mai saputo nulla. Il [pattern saga](https://microservices.io/patterns/data/saga.html) è la risposta onesta – ogni passo è un'azione locale abbinata a un'azione *compensativa* (addebito ↔ rimborso, prenotazione ↔ liberazione), e un fallimento esegue le compensazioni di tutto ciò che è già stato fatto. Tre discipline lo fanno funzionare: **chiavi di idempotenza** sui passi pericolosi, perché un timeout seguito da un retry non addebiti due volte (il pagamento ripetuto con la stessa chiave viene riconosciuto, non ripetuto); **timeout per singolo passo**, perché una dipendenza bloccata non blocchi l'intero flusso; e **stati terminali espliciti**, perché un flusso completato a metà e poi compensato è un *esito noto* da registrare, non un'eccezione da ingoiare. Il regalo dell'orchestrazione è che tutto questo vive in un unico posto visibile – ed è anche il suo costo: quel posto va scalato, monitorato e tenuto in ordine.

## Il calcolo della latenza

Tre chiamate da 200 ms ciascuna: in sequenza = **600 ms**; in parallelo = **~200 ms**. La prima ottimizzazione dell'orchestratore non è la cache né un trasporto astuto – è una lettura onesta del grafo delle dipendenze: i caricamenti del carrello e dell'indirizzo (indipendenti) partono insieme; l'addebito (che ha bisogno del carrello) attende; la spedizione (che ha bisogno dell'addebito) attende a sua volta. La maggior parte dei flussi orchestrati è una breve spina dorsale sequenziale da cui pendono rami paralleli, e ogni passo collocato per errore sulla spina dorsale è latenza visibile all'utente, regalata per nulla.

## Codice o motore?

Una **semplice funzione basta** quando il flusso è breve e sincrono: una manciata di passi, qualche secondo di budget complessivo, e "è fallito" è una risposta accettabile da restituire a un client che attende – il che descrive le esigenze di orchestrazione della maggior parte dei backend applicativi, e corrisponde esattamente a ciò che offre una [funzione lato server](/glossary/it/cloud-code-funzioni-serverless/). Un **motore di workflow durevole** (esempi open source: Temporal, Camunda) giustifica il proprio peso operativo quando i flussi sono di lunga durata (da qualche minuto a giorni interi), devono sopravvivere al riavvio di un processo a metà percorso, oppure richiedono retry pianificati, passi di approvazione umana e uno storico riproducibile (replay). Il percorso di crescita è reale ma raramente urgente; l'anti-pattern è distribuire un motore per un checkout da tre chiamate – oppure costruire a mano uno stato durevole dentro una funzione che è diventata un motore senza che nessuno se ne accorgesse.

## Casi d'uso tipici

- **Flussi di checkout e pagamento** – la sequenza dipendente tipica, con dei soldi in gioco.
- **Onboarding degli utenti** – creare l'account, verificare l'identità, fare il provisioning delle risorse, mandare il benvenuto: ordinato e compensabile.
- **Assemblaggio di schermate mobili** – una chiamata orchestrata che sostituisce tre round trip chiacchieroni su una [rete a latenza alta](/glossary/it/ottimizzazione-del-payload/).
- **Pacchetti di servizi terzi** – verifiche KYC, preventivi di spedizione, arricchimento dei dati: più fornitori, una sola risposta, chiavi conservate [lato server](/glossary/it/sicurezza-delle-chiavi-api/).
- **Cuciture di migrazione** – un orchestratore che nasconde dietro un'unica API stabile la divisione fra sistema vecchio e sistema nuovo durante lo [smontaggio di un monolite](/glossary/it/microservizi-vs-monolite/).

## Conviene orchestrare? Matrice decisionale

| Situazione | Scelta consigliata |
| --- | --- |
| 3+ chiamate dipendenti dietro una sola azione dell'utente | Orchestrazione – prima una funzione |
| Letture parallele indipendenti per una sola schermata | Aggregazione – più semplice, stateless |
| Aspetti trasversali (autenticazione, limiti) | Il [gateway](/glossary/it/api-gateway/) – non la logica di workflow |
| Reazioni di cui ai produttori non importa | [Eventi e coreografia](/glossary/it/architettura-orientata-agli-eventi/) |
| Flussi lunghi giorni con passi umani | Un motore di workflow durevole |
| Una sola chiamata al backend | Niente – la si chiama e basta |

## Limiti e trade-off

- **L'orchestratore attira dipendenze.** Conosce ogni servizio del flusso; i cambiamenti a valle si ripercuotono su di esso – la visibilità e l'accoppiamento sono la stessa proprietà.
- **Sta sull'hot path.** Ogni flusso lo attraversa, quindi la sua latenza, la sua scalabilità e il suo budget di disponibilità appartengono al prodotto, non a una nota a piè di pagina sull'infrastruttura.
- **La compensazione non è un annullamento.** Un rimborso è un nuovo evento con le proprie modalità di guasto, non una macchina del tempo; le saga scambiano l'atomicità con l'esplicitezza, e quell'esplicitezza va gestita.
- **La logica di business migra verso l'orchestratore.** Senza governo, assorbe decisioni che spettano ai servizi proprietari dei dati – la sequenza qui, la semantica là.
- **L'orchestrazione sincrona eredita i limiti del sincrono.** Un client che aspetta cinque passi resta bloccato ad aspettare; i flussi che escono dalla finestra della richiesta spettano ai [job](/glossary/it/job-in-background/) con uno stato, non a timeout più lunghi.

## L'orchestrazione su Back4app

Back4app è una piattaforma open-source di Backend as a Service (BaaS) che combina database gestito, API REST e GraphQL generate automaticamente, autenticazione, archiviazione di file e funzioni serverless con Cloud Code. L'orchestrazione leggera è ciò che una [funzione Cloud Code](/glossary/it/cloud-code-funzioni-serverless/) fa per natura, e le schede di codice mostrano il pattern completo: una funzione `checkout` che parallelizza le letture indipendenti, mette in sequenza i passi dipendenti, tiene le chiavi dei servizi terzi [lato server](/glossary/it/sicurezza-delle-chiavi-api/), compensa nel blocco catch e restituisce una sola risposta a un client mobile che ha fatto esattamente una chiamata. La funzione gira accanto al database (lo stato dell'ordine e gli esiti terminali distano una sola scrittura), il contesto di autenticazione arriva su `request.user`, e non c'è alcun livello di orchestrazione separato da distribuire o da scalare. Il giorno in cui un flusso uscirà dalla finestra della richiesta – approvazioni, attese di un giorno intero – sarà il momento di passare a un motore di workflow; fino a quel momento, l'orchestratore è un file nel repository.