MCP Gateway: perché serve tra ChatGPT e i vostri servizi

1. Perché serve un altro livello?

Quasi tutti iniziano allo stesso modo: c’è un server MCP che descrive un paio di strumenti, ChatGPT lo chiama direttamente via HTTPS e tutto, a prima vista, sembra perfetto. L’architettura di massima è questa:

ChatGPT  →  il vostro server MCP  →  database / API esterne

Nella fase di «pet project» è davvero un’opzione valida. Ma non appena l’applicazione inizia ad arricchirsi di funzionalità e il team di sviluppo cresce, i problemi emergono molto rapidamente.

Per prima cosa, il server MCP si trasforma in un «God object». Al suo interno convivono strumenti per la scelta dei regali, checkout, analytics e magari anche «già che ci siamo mettiamoci anche la reportistica». Parti diverse del codice hanno SLA differenti e requisiti di sicurezza diversi, ma sono incollate in un unico processo.

In secondo luogo, ChatGPT e altri client sono costretti a conoscere la topologia dei vostri servizi. Se tra sei mesi comparirà un altro server MCP per il commerce, dovrete ricollegare i client, cambiare configurazioni e descrizioni. Invece di un «punto d’ingresso unico» vi ritroverete con uno zoo di URL.

In terzo luogo, diventa poco chiaro dove implementare ciò che è comune a tutti i servizi: autenticazione, logging, metriche, rate limiting, verifica dei token, localizzazione e instradamento per regioni. Se sparpagliate tutto questo su tutti i servizi MCP/Agent, otterrete molta duplicazione e comportamenti diversi tra i servizi.

Per spezzare questo accoppiamento e, allo stesso tempo, nascondere a ChatGPT la complessità interna, entra in gioco MCP Gateway — uno strato di gateway di rete e punto d’ingresso unico per tutto il traffico MCP.

2. Che cos’è MCP Gateway nel contesto di ChatGPT App

Formalmente MCP Gateway è un livello proxy e un punto d’ingresso unico tra i client MCP (ChatGPT, MCP Jam, i vostri strumenti interni) e l’insieme dei vostri servizi backend — di solito REST/HTTP‑API, microservizi, servizi Agents, commerce‑backend ecc.

Il gateway implementa verso l’esterno il protocollo MCP (per ChatGPT appare come un unico server MCP) e, all’interno, chiama i normali endpoint REST via HTTP/gRPC.

Alla richiesta tools/list il gateway non inoltra la chiamata oltre, ma restituisce un proprio elenco di strumenti: può essere definito rigidamente nel codice oppure composto dalla configurazione. Ogni tool è collegato a uno specifico endpoint REST e a uno schema dati. Alla richiesta tools/call il gateway prende il nome dello strumento, trova il percorso REST corrispondente e lo chiama tramite fetch/HTTP client.

In modo schematico si può rappresentare così:

flowchart LR
    ChatGPT["ChatGPT / modello"] --> |MCP JSON-RPC| Gateway["MCP Gateway<br/>(unico server MCP)"]
    Gateway --> GiftAPI["Gift REST API<br/>/ microservizio dei regali"]
    Gateway --> CommerceAPI["Commerce REST API<br/>/ ACP / pagamenti"]
    Gateway --> AnalyticsAPI["Analytics Service<br/>/ eventi e metriche"]

Per ChatGPT è un solo server: un URL, un set di strumenti, un unico flusso di eventi. Per voi — un punto flessibile per instradare il traffico verso diversi servizi più o meno critici.

3. MCP Gateway nell’architettura di GiftGenius

Per essere meno astratti e mostrare il gateway «in un sistema vivo», continuiamo con il nostro esempio GiftGenius — un’app che suggerisce regali e sa creare ordini tramite ACP/Instant Checkout.

Nella versione semplice avevamo un solo server MCP che sapeva fare sia suggest_gifts sia checkout_start. Ora che l’app è cresciuta, separiamo le responsabilità:

• Gift REST API — ricerca e raccomandazioni di regali, lavoro con catalogo e feed (un normale servizio HTTP/REST).
• Commerce REST API — ACP, sessioni di checkout, stati degli ordini, integrazione con il provider dei pagamenti.
• Analytics Service / REST API — raccolta di eventi e metriche (quali raccolte vengono aperte, cosa si acquista).
• Un servizio Agents separato (se necessario) — scenari complessi multi‑passo. Anch’esso è esposto via HTTP/REST, non via MCP.

MCP Gateway diventa il punto d’ingresso unico per tutti questi componenti. Esso:

• alla richiesta tools/list restituisce un elenco unico di tools che definisce da sé: ogni tool è collegato allo specifico endpoint REST di uno dei servizi;
• alla richiesta tools/call guarda il nome dello strumento (params.name), in base a una tabella di routing determina verso quale servizio REST andare e chiama il metodo HTTP corrispondente (tramite fetch, axios ecc.).

Se arriva un tools/call con nome suggest_gifts, il gateway chiama l’endpoint REST corrispondente nel Gift REST API. Se è checkout_start, la richiesta andrà al Commerce REST API.

Un piccolo pseudocodice in TypeScript in stile Express può essere così:

// Handler MCP molto semplificato
app.post("/mcp", async (req, res) => {
  const mcpReq = req.body as { method: string; params?: any };
  const ctx = buildContextFromHeaders(req); // auth, locale ecc.

  const toolName = mcpReq.params?.name;
  const backendRes = await callBackend(toolName, mcpReq, ctx);

  res.json(backendRes);
});

All’interno di pickBackend potete basarvi sul nome del metodo, sul nome dello strumento, sulla locale dell’utente e persino sulla versione del servizio (per i rilasci «canary» e blue/green, di cui parleremo più avanti nel modulo).

4. Responsabilità di MCP Gateway: cosa fa esattamente

Abbiamo visto come il gateway si inserisce nell’architettura di GiftGenius. Ora fissiamo esplicitamente quali responsabilità ha come livello separato, indipendentemente dall’applicazione concreta. È importante pensare al gateway come a un livello di rete e cross‑servizio. Il suo compito non è occuparsi della logica di business dei regali, ma risolvere i problemi infrastrutturali attorno ad essa.

Instradamento delle richieste

Il primo ruolo è quello di router. Il gateway riceve una richiesta MCP e, basandosi sul suo contenuto, sul contesto dell’utente e sulla propria configurazione, sceglie il servizio di destinazione.

Per esempio, in GiftGenius si può impostare una semplice tabella di routing:

const TOOL_ROUTES: Record<string, "gift" | "commerce" | "analytics"> = {
  suggest_gifts: "gift",
  get_similar_gifts: "gift",
  checkout_start: "commerce",
  get_order_status: "commerce",
  log_event: "analytics",
};

E poi usarla così:

function pickBackend(req: McpRequest, ctx: GatewayContext): Backend {
  if (req.method === "tools/list") return "aggregator";
  if (req.method === "tools/call") {
    const toolName = req.params?.name;
    const group = TOOL_ROUTES[toolName] ?? "gift";
    return group === "commerce" ? commerceBackend : giftBackend;
  }
  return giftBackend;
}

Nel nostro caso giftBackend, commerceBackend, analyticsBackend sono normali servizi REST: ciascuno ha un URL base ("https://gift-api.internal", "https://commerce-api.internal", …). Il gateway non inoltra MCP verso l’interno: decompone la chiamata MCP in una richiesta HTTP verso l’endpoint REST appropriato.

Autenticazione e autorizzazione al perimetro

La seconda funzione chiave è la protezione del perimetro. Il gateway è un luogo comodo per verificare il token, capire chi è l’utente, da quale organizzazione proviene e quali permissions possiede.

Può, ad esempio, accettare un token OAuth da ChatGPT o dal vostro server MCP Auth, convalidarlo (preferibilmente con una libreria collaudata, non con crittografia fatta in casa) e trasformarlo in un oggetto di contesto pulito:

type GatewayContext = {
  userId: string | null;
  tenantId: string | null;
  locale: string;
};

function buildContextFromHeaders(req: Request): GatewayContext {
  const token = req.headers["authorization"]; // "Bearer ..."
  const claims = token ? verifyJwt(token) : null;

  return {
    userId: claims?.sub ?? null,
    tenantId: claims?.tenant ?? null,
    locale: (req.headers["x-openai-locale"] as string) || "en-US",
  };
}

I servizi backend/REST interni possono così evitare di doversi occupare dell’analisi di header HTTP grezzi e token e ricevere invece un context già normalizzato con userId, tenantId e locale. Le raccomandazioni della documentazione MCP dicono chiaramente: non implementate la validazione dei token «da zero», usate librerie affidabili e token a breve durata.

Logging, tracing e metriche

Il terzo ruolo è l’osservabilità. Il gateway vede tutte le richieste MCP in ingresso e tutte le risposte, quindi è il luogo ideale per impostare un correlation‑id, loggare i parametri degli strumenti (senza dati sensibili), registrare il tempo di risposta e lo stato.

Un’idea semplicissima:

app.use((req, res, next) => {
  const requestId = crypto.randomUUID();
  (req as any).requestId = requestId;

  const start = Date.now();
  res.on("finish", () => {
    const ms = Date.now() - start;
    console.log(
      `[${requestId}] ${req.method} ${req.url} -> ${res.statusCode} in ${ms}ms`
    );
  });

  next();
});

Più avanti, nel modulo sull’osservabilità, potrete inviare questi dati non solo su console.log, ma in un archivio strutturato e costruirci dashboard.

Controllo base del carico

La quarta, ma comunque importante, attività è il controllo primario del carico. Sul gateway è comodo impostare contatori di chiamate per utenti, organizzazioni, strumenti ed endpoint, per evitare che un client «scatenato» bruci il vostro cluster e il budget per i modelli.

In questo modulo per ora fissiamo solo l’idea: rate limiting e code vivono a livello di gateway; i dettagli di implementazione (Redis, token bucket, leaky bucket) verranno approfonditi nella prossima lezione sulla protezione del perimetro.

Arricchimento delle richieste con contesto

Infine, il gateway è un buon posto per trasformare il contesto grezzo del client MCP in argomenti puliti per gli strumenti interni.

Per esempio, ChatGPT può passare la locale dell’utente tramite openai/locale e _meta["openai/userLocation"]. Il gateway può:

• selezionare il servizio regionale corretto (server RU, server EN ecc.);
• aggiungere locale agli argomenti della chiamata dello strumento, anche se lo strumento non lo richiede esplicitamente nello schema JSON (ad esempio come campo facoltativo).

In modo condizionale:

function enrichToolArgs(args: any, ctx: GatewayContext) {
  return {
    ...args,
    locale: args.locale ?? ctx.locale,
    tenantId: ctx.tenantId,
  };
}

Di conseguenza, il Gift API riceve subito un «contesto ricco» e può, per esempio, recuperare descrizioni dei regali in russo per "ru-RU" e in inglese per "en-US".

5. Cosa MCP Gateway NON dovrebbe fare

Quando uno sviluppatore ha tra le mani un «punto magico attraverso cui passa tutto», nasce il desiderio naturale di infilarci ciò che prima stava nei singoli servizi. Così il gateway rischia di diventare un mostro.

Ci sono alcune cose che, di norma, non dovrebbero vivere in questo livello.

Per prima cosa, logica di business complessa. Scelta dei regali, regole di sconto, calcolo dei costi di consegna, logica ACP — tutto ciò deve rimanere all’interno dei servizi backend/commerce specializzati. Il gateway può al massimo fare una leggera validazione preliminare (ad esempio controllare che il prezzo non sia negativo), ma non deve scegliere SKU né calcolare le imposte per regione.

In secondo luogo, stato utente di lunga durata. Il gateway è tipicamente un servizio stateless. Deve scalare orizzontalmente senza problemi, non dipendere dalla memoria locale e poter essere riavviato senza conseguenze. Se iniziate a conservarvi, per esempio, lo stato del wizard di checkout o il contenuto temporaneo del carrello, finirete rapidamente con problemi di sincronizzazione tra istanze.

In terzo luogo, funzioni specifiche che ha più senso collocare dentro gli stessi servizi backend (Gift API, Commerce API). Per esempio, se il backend Gift vuole mettere in cache il risultato della ricerca dei regali, lo faccia da sé, magari usando Redis. Il gateway non deve conoscere questa ottimizzazione interna. Parleremo a parte della protezione del perimetro, e lì sottolineeremo proprio questo: il gateway si occupa di funzioni di rete e cross‑servizio, non di regole di business per le raccomandazioni.

In quarto luogo, calcoli pesanti. Se all’interno del gateway iniziate a chiamare modelli LLM, fare trasformazioni e aggregazioni complesse, smetterà di essere un front leggero e diventerà un altro backend pesante, difficile da scalare e fare debug.

6. Gateway, localizzazione e versioni dei servizi

Abbiamo esaminato le responsabilità di base del gateway e ciò che è meglio non metterci dentro. Ora guardiamo un paio di attività «avanzate» tipiche che è comodo risolvere proprio a questo livello: localizzazione e versioning dei servizi. Un altro ruolo interessante del gateway è il routing intelligente in base alla locale e alle versioni dei servizi.

Quando ChatGPT chiama la vostra App, ha già un’idea della lingua dell’utente (openai/locale) e, spesso, della sua geolocalizzazione (_meta["openai/userLocation"]). Il gateway può usare queste informazioni per inviare le richieste ai servizi backend appropriati.

Per esempio, si può costruire un’architettura «un gateway — molti server backend monolingui»:

• RU‑Gift API — solo catalogo e testi in russo.
• EN‑Gift API — solo inglese.
• JP‑Gift API — giapponese (quando deciderete di conquistare il mondo).

In questo caso il gateway funge da server MCP per ChatGPT e, in base a locale e userLocation, sceglie il servizio interno corretto.

In modo condizionale:

function pickGiftBackendByLocale(ctx: GatewayContext): Backend {
  if (ctx.locale.startsWith("ru")) return giftRuBackend;
  if (ctx.locale.startsWith("ja")) return giftJpBackend;
  return giftEnBackend;
}

È anche comodo implementare lì un semplice routing canary. In questo modulo sull’architettura di produzione proponiamo proprio di usare il gateway per mandare una parte del traffico al nuovo cluster del servizio e il resto al vecchio.

Esempio di canary molto grossolano:

function pickGiftBackendCanary(ctx: GatewayContext): Backend {
  const hash = hashUser(ctx.userId ?? "anonymous");
  const bucket = hash % 100;
  return bucket < 5 ? giftBackendV2 : giftBackendV1; // il 5% del traffico va su v2
}

Così si possono rilasciare in sicurezza nuove versioni del Gift API, osservando metriche ed errori, senza rompere subito tutto il prod.

7. Architetture tipiche: da «tutto in uno» al Gateway

In precedenza nel corso avete già visto diverse varianti di architettura di produzione per le App ChatGPT. In questo modulo evidenziamo tre topologie di base, sufficienti nel 90 % dei casi.

La prima — «tutto in uno». Il widget dell’App (Next.js), il server MCP, la logica degli Agents e un semplice backend commerce vivono in un unico servizio, spesso in un unico repository e persino in una sola app Vercel. Pro: quasi zero DevOps, deploy semplice, latenza minima. Contro: scalare parti separate è difficile, una feature calda può buttare giù tutta l’applicazione e i confini tra componenti sono sfumati.

La seconda — App + MCP Gateway + più servizi backend. Qui il widget Next.js vive separato (per esempio su Vercel) e tutto il traffico MCP passa attraverso il Gateway, che instrada le richieste verso Gift REST API, Commerce REST API, il servizio Agents, l’ACP‑backend e altri. È proprio lo schema che stiamo analizzando ora in GiftGenius e che si adatta al 90 % dei casi reali in produzione.

La terza — la stessa cosa, ma in più regioni (multi‑region), con un bilanciatore globale davanti al gateway. Allora l’utente europeo finisce nel cluster EU, quello dagli USA nel cluster US, e ogni regione è costruita secondo lo schema «Gateway + più servizi backend». È uno scenario per progetti già abbastanza grandi con pubblico globale.

Per noi ora è importante non tanto memorizzare tutte le varianti, quanto abituarci a pensare al gateway come a un componente logico separato dell’architettura, anche se nelle prime fasi il suo ruolo è svolto, per esempio, da un monolite MCP o dal backend della vostra App.

8. Dove vive fisicamente MCP Gateway

Buona notizia: MCP Gateway non è necessariamente un enorme servizio separato su Kubernetes. Molto spesso attraversa diverse fasi di maturazione.

Su scala minima il ruolo di gateway può svolgerlo lo stesso server MCP. In questo caso basta strutturare il codice con cura: estrarre instradamento, autenticazione e logging in un modulo, e la logica degli strumenti in altri. In questo modulo sottolineiamo che, nei sistemi piccoli, le funzioni del gateway possono vivere dentro il server MCP o nella parte backend dell’App (per esempio in una API route di Next.js).

Passo successivo — un servizio Node/TypeScript separato. Può essere un’app Express/Fastify che ascolta "/mcp" e chiama internamente vari servizi HTTP. Per molti team è un’opzione confortevole: si integra bene con gli strumenti DevOps abituali.

Scheletro semplicissimo di un servizio del genere:

const app = express();
app.use(express.json());

app.post("/mcp", handleMcpRequest); // qui avviene tutta la magia del gateway

app.listen(4000, () => {
  console.log("MCP Gateway listening on :4000");
});

A un ulteriore livello di maturità, il gateway può essere realizzato sopra soluzioni gestite: AWS API Gateway, Cloudflare Workers/Routes, NGINX/Envoy con config di routing e script Lua/JS. È importante capire che è un cambiamento di implementazione, non di concetto. Architettonicamente ChatGPT continua a parlare con un solo punto, e tutti i dettagli li gestisce il gateway.

9. Mini‑esempio: un semplice MCP Gateway per GiftGenius

Abbiamo già visto separatamente instradamento, contesto e gestione di tools/list. Ora uniamo tutto in un esempio chiaro ma piccolo. Supponiamo di avere due servizi REST interni:

• GIFT_API_BASE = "https://gift-api.internal";
• COMMERCE_API_BASE = "https://commerce-api.internal".

E un gateway a cui ChatGPT si collega all’indirizzo "https://gateway.giftgenius.com/mcp".

Per prima cosa definiamo un paio di tipi:

type Backend = "gift" | "commerce";

type ToolRoute = {
  backend: Backend;
  method: "GET" | "POST";
  path: string;
};

const TOOL_ROUTES: Record<string, ToolRoute> = {
  suggest_gifts: {
    backend: "gift",
    method: "POST",
    path: "/api/gifts/suggest",
  },
  checkout_start: {
    backend: "commerce",
    method: "POST",
    path: "/api/checkout/start",
  },
  get_order_status: {
    backend: "commerce",
    method: "GET",
    path: "/api/orders/status",
  },
};

Poi implementiamo la scelta del backend e la chiamata:

async function callBackend(toolName: string, mcpReq: McpRequest, ctx: GatewayContext) {
  const route = TOOL_ROUTES[toolName];
  if (!route) {
    throw new Error(`Unknown tool: ${toolName}`);
  }

  const base =
    route.backend === "gift" ? GIFT_API_BASE : COMMERCE_API_BASE;

  const url = base + route.path;

  // argomenti arrivati nella chiamata MCP tools/call
  const args = {
    ...(mcpReq.params?.arguments ?? {}),
    locale: ctx.locale,
  };

  const res = await fetch(url, {
    method: route.method,
    headers: { "content-type": "application/json" },
    body: route.method === "POST" ? JSON.stringify(args) : undefined,
  });

  const data = await res.json();

  // Incapsuliamo la risposta del servizio REST nella risposta MCP
  return {
    result: data,
  } satisfies McpResponse;
}

Infine, l’handler principale che:

1. Costruisce il contesto dagli header (auth, locale).
2. Sceglie il backend.
3. Oppure aggrega tools/list, oppure inoltra tools/call.

app.post("/mcp", async (req, res) => {
  const mcpReq = req.body as McpRequest;
  const ctx = buildContextFromHeaders(req);

  if (mcpReq.method === "tools/list") {
    // Il gateway dichiara da sé gli strumenti e i loro schemi
    const tools = [
      {
        name: "suggest_gifts",
        description: "Suggerisce regali in base al budget e agli interessi.",
        inputSchema: { /* ... JSON Schema ... */ },
      },
      {
        name: "checkout_start",
        description: "Crea una bozza d'ordine e avvia il checkout.",
        inputSchema: { /* ... */ },
      },
      // ...
    ];

    return res.json({ result: { tools } });
  }

  if (mcpReq.method === "tools/call") {
    const toolName = mcpReq.params?.name;
    const backendRes = await callBackend(toolName, mcpReq, ctx);
    return res.json(backendRes);
  }

  res.status(400).json({ error: { message: "Unsupported MCP method" } });
});

Questa è ovviamente una versione semplificata, ma mostra già le idee chiave:

• il gateway non sa come il Gift API scelga i regali;
• si limita a instradare con cura, arricchire gli argomenti e, se necessario, loggare e applicare limiti alle chiamate.

10. Come tutto questo si collega ai temi successivi del modulo

MCP Gateway è una parte fondamentale di tutto ciò che discuteremo nelle restanti lezioni del modulo:

• Nella prossima lezione parleremo di protezione del perimetro: rate limiting, code e backpressure. Tutto questo vive innanzitutto a livello di gateway, perché è lui a vedere tutto il traffico in ingresso e a poter «tagliare l’eccesso» prima che le richieste travolgano il backend.
• Poi discuteremo della resilienza: timeouts, circuit breaker, bulkhead. Il gateway è il punto in cui è comodo impostare in modo centralizzato i timeout delle chiamate esterne e abilitare/disabilitare i servizi problematici (per esempio «staccare» temporaneamente il Commerce API se inizia a dare errori).
• Infine, parlando di scalabilità e deploy, considereremo il gateway come un cluster separato che si può bilanciare, rilasciare secondo schemi blue/green e canary e fare rollback in modo indipendente dai servizi MCP interni.

In sostanza, se prima pensavate «ho l’App e il server MCP», ora lo schema si estende a «ho l’App, l’MCP Gateway, più cluster backend/Agents e un commerce‑backend». E proprio il gateway consente di non complicare la configurazione per ChatGPT — che continua a vedere un unico punto MCP.

11. Errori tipici nell’uso di MCP Gateway

Errore n. 1: trasformare il gateway in un «mostro di business».
Trappola frequente: siccome tutto passa dal gateway, perché non aggiungerci il calcolo degli sconti, la scelta degli SKU, regole complesse di categorizzazione o la validazione dei codici promo. Alla fine ottenete un servizio grasso, difficile da scalare e cambiare, e perdete il senso della separazione tra Gift API, Commerce API e gli altri componenti specializzati. Meglio mantenere il gateway come sottile livello di rete e lasciare tutto ciò che è specifico del dominio dentro i servizi dedicati.

Errore n. 2: conservare nel gateway stato utente di lunga durata.
L’idea «salviamo il carrello dell’utente direttamente in memoria nel gateway» sembra allettante finché avete un’istanza sola. Appena ne compare una seconda, iniziano i dolori: dove sta il carrello «vero», nell’istanza A o B? Che succede dopo un riavvio? Il gateway deve rimanere stateless: al massimo un piccolo cache di handshake o di configurazioni, mentre tutto lo stato di sessioni e ordini va conservato nel DB o in servizi specializzati.

Errore n. 3: rendere ChatGPT consapevole della topologia interna dei servizi.
Se iniziate a esporre a ChatGPT più server API contemporaneamente (Gift API separato, Commerce API separato) e usare il gateway «a tratti», perdete il vantaggio principale: un ingresso unico e controllo centralizzato. Al cambio di topologia dovrete aggiornare la configurazione in più punti. Molto più semplice impostare una volta l’MCP Gateway come endpoint ufficiale per l’App e nascondere dietro di lui tutti i cambiamenti interni.

Errore n. 4: duplicare la logica cross‑servizio in tutti i backend.
Talvolta i team provano a implementare autenticazione, rate limiting, logging e localizzazione in ciascun servizio REST separatamente. Risultato: nel Gift API una politica dei permessi e dei limiti, nel Commerce API un’altra e il comportamento dell’App diventa imprevedibile. Proprio per questo serve il gateway: verificare il token, determinare tenant e locale, loggare la chiamata, applicare i limiti e solo dopo andare al servizio specifico.

Errore n. 5: sovraccaricare il gateway con calcoli pesanti e chiamate LLM.
Tecnicamente nulla vi impedisce di chiamare da gateway un altro modello LLM, fare aggregazioni complesse o operazioni batch lunghe. Ma così lo trasformerete rapidamente in un altro backend pesante, impossibile da scalare e isolare bene. Il gateway deve rimanere veloce e prevedibile: al massimo leggere trasformazioni e instradamento. Tutto ciò che è pesante — dentro i servizi REST o in code/worker, di cui parleremo più avanti nel modulo.

Errore n. 6: complicare troppo presto l’infrastruttura.
L’estremo opposto — montare subito un cluster Kubernetes separato, stack NGINX, Cloudflare Workers e un mare di configurazioni complesse per una piccola App didattica. Non ha senso finché non avete carico reale e requisiti di resilienza. È perfettamente normale iniziare con un monolite MCP o un semplice gateway Node e solo poi, con la crescita, spostare i componenti in cluster e servizi gestiti.