API Gateway

Executive summary

Quando un sistema software è composto da decine o centinaia di servizi indipendenti, gestire l'accesso dall'esterno diventa un problema concreto: ogni servizio ha regole di sicurezza, limiti di traffico e formati di comunicazione diversi, e i programmi che vi accedono non dovrebbero conoscere questa complessità interna. Questo articolo analizza i componenti infrastrutturali che fungono da punto di ingresso unico tra il mondo esterno e i servizi interni, esaminando come gestiscono il controllo degli accessi, la regolazione del traffico e l'instradamento delle richieste. L'analisi mostra che le soluzioni più efficaci sono quelle che separano nettamente le responsabilità infrastrutturali da quelle applicative, e che la tendenza attuale è verso una convergenza tra il controllo del traffico in ingresso e quello interno al sistema, con l'obiettivo di ridurre la complessità operativa senza sacrificare la flessibilità.

Background

L'evoluzione dalle architetture monolitiche ai microservizi ha trasformato radicalmente la superficie di comunicazione di un sistema software. In un monolite, il traffico esterno raggiunge un singolo processo attraverso un reverse proxy; in un'architettura a microservizi, centinaia di servizi indipendenti espongono endpoint distinti, ciascuno con requisiti specifici di autenticazione, rate limiting, trasformazione del payload e versionamento. Richardson [1] formalizza l'API gateway pattern come risposta a questo problema: un componente che funge da single entry point per tutti i client esterni, incapsulando la topologia interna del sistema e centralizzando le cross-cutting concern che altrimenti dovrebbero essere replicate in ogni servizio.

Il pattern non è nuovo in senso assoluto. I reverse proxy come NGINX e HAProxy hanno storicamente gestito il routing e il bilanciamento del carico a livello di trasporto. L'innovazione dell'API gateway risiede nell'operare a livello applicativo (layer 7), con consapevolezza della semantica HTTP, dei protocolli API (REST, gRPC, GraphQL, WebSocket) e della logica di autenticazione e autorizzazione. La distinzione è architetturalmente significativa: un reverse proxy instrada pacchetti, un API gateway comprende richieste. Questa differenza determina la capacità di implementare trasformazioni del payload, aggregazione di risposte da servizi multipli, e policy di accesso granulari per endpoint.

Newman [2] ha introdotto il pattern Backend for Frontend (BFF) come specializzazione dell'API gateway: anziché un unico gateway generalista, si deploya un gateway dedicato per ciascun tipo di client (web, mobile, IoT), ottimizzato per le esigenze specifiche di quel frontend. Il BFF aggrega e trasforma le risposte di più microservizi in una struttura adatta al client specifico, spostando la logica di composizione dal frontend a un layer server-side dedicato. La distinzione rispetto all'API gateway generico è funzionale: il gateway gestisce concern infrastrutturali (autenticazione, rate limiting, routing), mentre il BFF contiene logica di presentazione specifica per il client. In architetture complesse, i due pattern coesistono: il BFF si colloca dietro l'API gateway, delegando a quest'ultimo le responsabilità trasversali [2].

La Kubernetes Gateway API [3], sviluppata dal SIG-Network e raggiunta la general availability con la versione 1.0 nell'ottobre 2023, rappresenta il tentativo più significativo di standardizzare le interfacce di configurazione degli API gateway in ambienti cloud-native. La specifica introduce una separazione esplicita dei ruoli tramite risorse distinte: il GatewayClass (gestito dal provider dell'infrastruttura), il Gateway (gestito dall'operatore del cluster) e le HTTPRoute/GRPCRoute (gestite dai team applicativi). Questa separazione riflette un principio di design fondamentale: chi gestisce l'infrastruttura non deve controllare il routing applicativo, e viceversa. La versione 1.2, rilasciata nell'ottobre 2024, ha aggiunto il supporto per WebSocket, timeout e retry al canale standard; la versione 1.4, rilasciata nell'ottobre 2025, ha introdotto BackendTLSPolicy per il TLS tra gateway e backend [3]. L'adozione della specifica da parte di oltre 25 implementazioni, tra cui Envoy Gateway, Kong, Istio e il recente supporto GA di AWS Load Balancer Controller, indica una convergenza dell'ecosistema verso un'interfaccia dichiarativa comune.

Architettura e pattern fondamentali

Flusso di una richiesta attraverso il gateway

Il processing di una richiesta in un API gateway segue una pipeline sequenziale di fasi, ciascuna implementata come un filtro o plugin indipendente. L'ordine tipico è: terminazione TLS, decodifica del protocollo, autenticazione, autorizzazione, rate limiting, trasformazione della richiesta, routing verso il servizio upstream, trasformazione della risposta, logging e metriche. Questa architettura a pipeline, comune a Kong [4], Envoy [5] e alle implementazioni conformi alla Gateway API, consente di comporre comportamenti complessi combinando filtri atomici, e di modificare il comportamento del gateway senza alterare il codice dei servizi downstream.

La scelta tra un modello a plugin interpretati e uno a filtri compilati ha implicazioni significative sulle prestazioni e sull'estensibilità. Kong [4] adotta un'architettura basata su OpenResty (NGINX + LuaJIT): i plugin sono moduli Lua eseguiti in un runtime JIT all'interno del ciclo di eventi di NGINX, con accesso a un Plugin Development Kit (PDK) che astrae le fasi del ciclo di vita della richiesta (access, header_filter, body_filter, log). Questo modello privilegia la facilità di sviluppo (un plugin Lua può essere scritto e deployato senza ricompilare il gateway), ma introduce un overhead di interpretazione e limita il controllo sulla gestione della memoria. Envoy [5] adotta il modello opposto: i filtri sono catene di componenti C++ compilati, configurati dinamicamente tramite il protocollo xDS. L'estensibilità è garantita da WebAssembly (Wasm): i filtri custom vengono compilati in moduli Wasm eseguiti in una sandbox isolata, con overhead contenuto ma con un modello di sviluppo più complesso rispetto a Lua.

Configurazione dinamica: il protocollo xDS

Uno dei contributi architetturali più rilevanti di Envoy è il protocollo xDS (x Discovery Service) [5], che disaccoppia completamente il data plane (il proxy che gestisce il traffico) dal control plane (il componente che determina la configurazione). Il protocollo definisce una famiglia di API di discovery: Listener Discovery Service (LDS) per le porte di ascolto, Route Discovery Service (RDS) per le regole di routing, Cluster Discovery Service (CDS) per i backend, Endpoint Discovery Service (EDS) per le istanze dei servizi, e Secret Discovery Service (SDS) per certificati e chiavi. Ogni aggiornamento viene propagato dal control plane al data plane tramite gRPC streaming, senza necessità di restart o reload del proxy.

Il modello xDS ha due varianti operative: state-of-the-world, in cui ogni aggiornamento contiene l'intera configurazione (l'assenza di una risorsa implica la sua rimozione), e delta, in cui vengono trasmesse solo le risorse aggiunte, modificate o rimosse. La variante delta riduce significativamente il volume di dati trasmessi in cluster con migliaia di endpoint, ma introduce complessità nella gestione della consistenza: il control plane deve tracciare lo stato di ogni connessione xDS per calcolare correttamente i delta. L'Aggregated Discovery Service (ADS) risolve il problema dell'ordinamento degli aggiornamenti tra servizi diversi, garantendo che un aggiornamento di routing non faccia riferimento a cluster non ancora propagati [5]. Questo modello è stato adottato come standard de facto dall'ecosistema CNCF: Istio, Kuma, Consul Connect e la maggior parte dei service mesh utilizzano xDS come interfaccia tra control plane e data plane.

Pattern di routing: path-based, header-based e weighted

Le strategie di routing implementate dagli API gateway si articolano su tre livelli di complessità crescente. Il routing path-based, il più elementare, mappa prefissi o pattern URL a servizi upstream specifici (e.g., /api/v1/users verso il servizio utenti). Il routing header-based aggiunge la capacità di instradare in funzione di header HTTP arbitrari, un meccanismo essenziale per il canary deployment, dove una percentuale controllata di traffico viene instradata verso una nuova versione del servizio in base a un header di versione o a un cookie. Il weighted routing distribuisce il traffico tra versioni multiple di un servizio secondo pesi configurabili, consentendo rilasci graduali con rollback automatico basato su metriche di errore.

La Kubernetes Gateway API [3] formalizza questi pattern attraverso le risorse HTTPRoute e GRPCRoute, che supportano nativamente match su path, header, query parameter e method, con backend multipli pesati. La specifica estende il modello con i filtri di richiesta e risposta (RequestHeaderModifier, URLRewrite, RequestMirror), che consentono trasformazioni inline senza plugin aggiuntivi. Questo livello di espressività supera significativamente le capability dell'Ingress API originale di Kubernetes, che supportava esclusivamente routing path-based con un singolo backend per regola, una delle ragioni principali della migrazione verso la Gateway API.

Meccanismi di autenticazione e autorizzazione

OAuth 2.0 e JWT: il modello dominante

Il framework OAuth 2.0 [6] e il formato JSON Web Token (JWT) [7] costituiscono il modello di autenticazione prevalente negli API gateway moderni. Il flusso tipico prevede che il client ottenga un access token da un authorization server esterno (tramite uno dei grant type definiti in RFC 6749: authorization code, client credentials, device code), e lo presenti all'API gateway in ogni richiesta successiva tramite l'header Authorization: Bearer. Il gateway valida il token verificando la firma crittografica, la scadenza, l'issuer e l'audience, senza contattare l'authorization server, operando interamente in modo stateless.

La validazione locale del JWT è il fattore che rende questo modello scalabile: a differenza dei token opachi, che richiedono un'introspezione sincrona verso l'authorization server per ogni richiesta (con conseguente latenza aggiuntiva e single point of failure), un JWT firmato contiene tutte le informazioni necessarie per la validazione. Il costo è la perdita di revoca immediata: un JWT rimane valido fino alla scadenza, indipendentemente da eventuali revoche lato authorization server. Le strategie di mitigazione includono la riduzione del tempo di vita del token (TTL di 5-15 minuti) combinata con refresh token rotation, e l'implementazione di token revocation list distribuite, un compromesso tra latenza di revoca e overhead operativo.

RFC 9068 [8] standardizza il profilo JWT per access token OAuth 2.0, definendo i claim obbligatori (iss, exp, aud, sub, client_id, iat, jti) e le regole di validazione. La standardizzazione è rilevante per l'interoperabilità tra gateway e authorization server di vendor diversi: prima di RFC 9068, ogni implementazione definiva una struttura JWT proprietaria, rendendo la migrazione tra provider un'operazione non banale.

Autorizzazione fine-grained: dal gateway al servizio

L'API gateway gestisce tipicamente l'autenticazione (chi sei?) e un primo livello di autorizzazione coarse-grained (puoi accedere a questo endpoint?), ma l'autorizzazione fine-grained (puoi modificare questa specifica risorsa?) richiede contesto applicativo che il gateway non possiede. La separazione è architetturalmente importante: delegare al gateway decisioni che dipendono dallo stato del dominio crea un accoppiamento che viola il principio di single responsibility e complica il testing.

Il pattern emergente prevede che il gateway inietti i claim del JWT validato (e.g., user_id, roles, scopes) come header della richiesta instradata al servizio upstream, il quale implementa la logica di autorizzazione nel proprio dominio. AWS API Gateway [9] implementa questo modello attraverso i Lambda authorizer: funzioni serverless che eseguono logica di autorizzazione custom e restituiscono una IAM policy che il gateway applica alla richiesta. Il risultato viene cachato per un periodo configurabile, ammortizzando il costo di invocazione della funzione Lambda su richieste successive con lo stesso token.

Mutual TLS e zero-trust

In architetture zero-trust, l'autenticazione non si limita al traffico north-south (client-gateway) ma si estende al traffico east-west (servizio-servizio). Il mutual TLS (mTLS) richiede che entrambe le parti di una connessione presentino un certificato, autenticando sia il client sia il server. L'API gateway, in questo contesto, termina il mTLS dal client esterno e stabilisce una nuova connessione mTLS verso il servizio upstream, agendo come trust boundary tra la rete esterna e il mesh interno. La Kubernetes Gateway API v1.4 [3] ha introdotto BackendTLSPolicy proprio per standardizzare la configurazione del TLS tra gateway e backend, un aspetto precedentemente delegato ad annotazioni specifiche di ciascuna implementazione.

Rate limiting: algoritmi e implementazioni distribuite

Token bucket e leaky bucket

Il rate limiting è la prima linea di difesa contro l'abuso delle API, il sovraccarico dei servizi upstream e il denial-of-service accidentale o intenzionale. I due algoritmi fondamentali, token bucket e leaky bucket, implementano filosofie diverse di controllo del traffico.

Il token bucket opera con un contenitore che accumula token a una frequenza costante $r$ (fill rate), fino a una capacità massima $b$ (burst size). Ogni richiesta consuma un token; se il bucket è vuoto, la richiesta viene rifiutata o accodata. Formalmente, il numero di token disponibili al tempo $t$ è $\min(b, \, tokens_{t-1} + r \cdot \Delta t)$, dove $\Delta t$ è l'intervallo trascorso dall'ultimo aggiornamento. Il vantaggio del token bucket è la tolleranza ai burst: un client può emettere $b$ richieste istantaneamente se il bucket è pieno, purché il rate medio non superi $r$ nel lungo periodo. AWS API Gateway [9] utilizza esplicitamente il token bucket per il throttling delle richieste, restituendo un errore HTTP 429 quando il bucket è esaurito.

Il leaky bucket, al contrario, impone un rate di output rigorosamente costante: le richieste entrano in una coda di capacità finita e vengono processate a frequenza fissa. I burst vengono assorbiti dalla coda ma non accelerano il processing, producendo un traffico verso i backend perfettamente regolare. Questo comportamento è preferibile quando i servizi upstream hanno limiti rigidi di throughput e non tollerano picchi, ma introduce latenza aggiuntiva proporzionale alla lunghezza della coda.

Rate limiting distribuito

In un deployment multi-istanza, il rate limiting locale (per-nodo) è insufficiente: se il limite è di 100 richieste/secondo e il gateway ha 10 repliche, il rate effettivo percepito dal backend è 1000 richieste/secondo. Il rate limiting distribuito richiede un meccanismo di coordinamento tra le istanze del gateway.

Envoy [5] implementa due modelli distinti. Il local rate limit opera per-istanza senza coordinamento, applicando limiti tramite un token bucket locale configurato come filtro HTTP o network. Il global rate limit delega la decisione a un servizio esterno di rate limiting, contattato tramite gRPC per ogni richiesta (o per ogni richiesta che matcha un insieme di descriptor). Il servizio di rate limiting, tipicamente il progetto open-source envoyproxy/ratelimit [10] basato su Redis come backend di conteggio, mantiene i contatori centralizzati e risponde con una decisione allow/deny. L'architettura è esplicitamente eventual consistent: sotto carico estremo, la latenza del round-trip verso il servizio di rate limiting può consentire un breve overshoot del limite configurato.

Un approccio più sofisticato è il Rate Limit Quota Service (RLQS) [5], un protocollo sperimentale in cui il servizio centrale assegna quote a ciascuna istanza Envoy in base al carico reale osservato. Ogni istanza riporta periodicamente il proprio rate di richieste, e il servizio ribilancia le quote dinamicamente. Questo modello riduce il numero di round-trip per-richiesta, poiché l'istanza applica la quota localmente, mantenendo un controllo globale adattivo. Il trade-off è una maggiore complessità di implementazione e un periodo di convergenza durante il quale le quote potrebbero non riflettere il carico effettivo.

Kong [4] affronta il rate limiting distribuito attraverso un plugin dedicato che supporta due strategie: cluster, che utilizza il database centrale di Kong (PostgreSQL o Cassandra) per contatori condivisi, e redis, che delega il conteggio a un'istanza Redis esterna. La strategia cluster introduce latenza I/O verso il database su ogni richiesta, rendendola inadatta a scenari ad alto throughput; la strategia redis offre latenza sub-millisecondo ma richiede la gestione operativa di un'infrastruttura Redis dedicata.

Limiti per tenant e API key

Nei sistemi multi-tenant, il rate limiting deve differenziare tra classi di utenti con SLA diversi. Il meccanismo standard è l'usage plan associato a una API key: ogni key identifica un tenant e mappa a un piano con limiti specifici di rate e quota. AWS API Gateway [9] implementa questo modello nativamente, con la precisazione che le API key non sono meccanismi di sicurezza ma esclusivamente identificatori di throttling: l'autenticazione resta delegata a OAuth 2.0 o ai Lambda authorizer. Il rate limiting per-key consente di proteggere i servizi backend dal noisy neighbor problem, dove un singolo tenant consuma una quota sproporzionata di risorse a danno degli altri.

Integrazione con service mesh e osservabilità

API gateway e service mesh: responsabilità complementari

La relazione tra API gateway e service mesh è una delle aree di maggiore confusione architetturale nell'ecosistema cloud-native. La distinzione funzionale è chiara: l'API gateway gestisce il traffico north-south (dall'esterno verso il cluster), mentre il service mesh gestisce il traffico east-west (tra servizi interni). In pratica, le capability si sovrappongono: entrambi implementano mTLS, retry, circuit breaking, osservabilità e, in misura crescente, rate limiting.

Istio, il service mesh più diffuso nell'ecosistema Kubernetes, utilizza Envoy come data plane proxy (sidecar o, in modalità ambient, come ztunnel per L4 e waypoint proxy per L7). L'annuncio di Envoy Gateway come unified ingress gateway per Istio ambient mesh [11] segna un punto di convergenza significativo: lo stesso data plane (Envoy) gestisce sia il traffico in ingresso sia quello interno, con un unico modello di configurazione basato sulla Kubernetes Gateway API. La convergenza riduce la complessità operativa (un solo set di filtri, un solo sistema di telemetria, un solo modello di policy), ma richiede un'attenta separazione delle responsabilità: il gateway espone le API esterne con autenticazione e rate limiting, i waypoint proxy gestiscono le policy di routing e resilienza interne.

Il circuit breaker è un esempio di capability che cambia semantica in funzione della posizione nella catena. Implementato nel gateway, protegge il sistema esterno dal propagare errori ai client in caso di failure dei servizi interni: dopo un numero configurabile di errori consecutivi, il circuit si apre e il gateway restituisce immediatamente un errore (tipicamente HTTP 503) senza contattare il servizio upstream, riducendo il carico su un servizio già in difficoltà. Implementato nel service mesh, protegge un servizio interno dal propagare failure a cascata verso i servizi che lo chiamano. I due livelli operano indipendentemente e si complementano, ma configurarli in modo incoerente, ad esempio con timeout del gateway più brevi dei timeout del mesh, introduce comportamenti non deterministici difficili da diagnosticare.

Osservabilità end-to-end con OpenTelemetry

L'API gateway è il punto naturale di iniziazione delle trace distribuite: essendo il primo componente a ricevere la richiesta esterna, genera il root span che accompagna la richiesta attraverso l'intera catena di servizi. L'adozione di OpenTelemetry [12] come standard di telemetria ha unificato la raccolta di metriche, trace e log in un unico framework vendor-neutral, risolvendo il problema storico dell'incompatibilità tra sistemi di tracing proprietari.

L'instrumentazione del gateway con OpenTelemetry produce tre categorie di dati. Le metriche (request rate, error rate, latenza per percentile) alimentano il monitoring e l'alerting. Le trace distribuite, propagate tramite gli header W3C Trace Context, consentono di ricostruire il percorso completo di una richiesta dal gateway attraverso tutti i servizi coinvolti, identificando il servizio responsabile di un incremento di latenza. I log strutturati, correlati al trace ID, forniscono il contesto dettagliato per il debugging.

La correlazione tra le metriche del gateway e quelle del service mesh è fondamentale per il capacity planning: la latenza misurata al gateway include il tempo di processing del gateway stesso, la latenza di rete verso il servizio upstream e il tempo di processing del servizio. Solo disaggregando questi contributi, tramite i span figli nella trace distribuita, è possibile identificare se un degrado delle prestazioni origina nel gateway (ad esempio per un plugin di autenticazione lento), nella rete (ad esempio per un DNS resolution timeout) o nel servizio applicativo.

Implementazioni a confronto: Kong, Envoy Gateway, AWS API Gateway

L'analisi comparativa si concentra su tre implementazioni rappresentative di paradigmi architetturali distinti: Kong come gateway estensibile basato su plugin, Envoy Gateway come data plane programmabile nel contesto CNCF, e AWS API Gateway come servizio managed serverless.

Kong Gateway

Kong [4] è costruito su OpenResty (NGINX + LuaJIT) e adotta un'architettura a plugin in cui ogni cross-cutting concern (autenticazione, rate limiting, trasformazione, logging) è implementata come modulo indipendente. Il Plugin Development Kit (PDK) espone hook nelle fasi del ciclo di vita della richiesta (access, header_filter, body_filter, log, rewrite), consentendo ai plugin di intervenire in punti specifici della pipeline. I plugin possono essere sviluppati in Lua, Go, Python o JavaScript, con Lua come linguaggio nativo e le altre opzioni che operano tramite inter-process communication con overhead aggiuntivo.

I benchmark ufficiali di Kong 3.6 [13] riportano un throughput di 50.000 transazioni al secondo per nodo su istanze AWS c6g (ARM-based), con una latenza P99 che varia significativamente in funzione del numero di plugin attivi nella pipeline. La modalità DB-less, in cui la configurazione è caricata da file dichiarativo senza necessità di un database centrale, riduce la latenza operativa e semplifica il deployment su Kubernetes, ma limita la gestione dinamica delle configurazioni a scenari in cui il ciclo di deployment è accettabile come meccanismo di aggiornamento. Kong Gateway 3.8 ha introdotto l'Incremental Configuration Sync, che trasmette solo le modifiche di configurazione rilevanti al data plane, riducendo significativamente il consumo di CPU e memoria in cluster con migliaia di route [4].

Envoy Gateway

Envoy Gateway [5, 11] è un'implementazione della Kubernetes Gateway API costruita su Envoy Proxy come data plane. A differenza di Kong, che opera come processo monolitico con plugin interpretati, Envoy adotta un'architettura a filtri compilati C++ con estensibilità via WebAssembly (Wasm). Il control plane traduce le risorse Gateway API (GatewayClass, Gateway, HTTPRoute) in configurazione xDS, che viene propagata dinamicamente al data plane Envoy senza restart.

Il vantaggio architetturale di Envoy Gateway risiede nell'integrazione nativa con l'ecosistema service mesh. In un deployment Istio ambient [11], Envoy Gateway funge sia da ingress gateway sia da waypoint proxy per il traffico L7 interno, eliminando la necessità di due componenti separati. Il modello xDS consente aggiornamenti di configurazione in tempo reale (aggiunta di route, modifica di policy, rotazione di certificati) con propagazione nell'ordine di secondi e senza interruzione del traffico. Il trade-off è la complessità operativa: la configurazione di Envoy è significativamente più articolata di quella di Kong, e il debugging richiede familiarità con il modello xDS, le admin API di Envoy e il sistema di logging strutturato.

AWS API Gateway

AWS API Gateway [9] rappresenta il paradigma fully-managed: non esiste un data plane da operare, la scalabilità è automatica, e il pricing è per-richiesta. Il servizio offre tre varianti: REST API (con supporto per usage plan, API key, caching, request validation), HTTP API (ottimizzata per costo e latenza, con funzionalità ridotte) e WebSocket API. L'integrazione con l'ecosistema AWS è profonda: i Lambda authorizer eseguono logica di autenticazione custom, l'integrazione con AWS Lambda consente di implementare backend serverless end-to-end, e il throttling nativo utilizza il token bucket con limiti configurabili per stage, method e API key.

Il limite architetturale principale è il vendor lock-in: la configurazione e le integrazioni sono specifiche di AWS e non portabili verso altri provider cloud o ambienti on-premise. I limiti di throttling massimi (10.000 richieste/secondo per account per regione, incrementabili su richiesta) sono inferiori ai throughput raggiungibili con Kong o Envoy su hardware dedicato, ma il modello serverless elimina completamente l'overhead operativo di capacity planning, patching e scaling. Per workload con traffico variabile e burst imprevedibili, il costo totale di possesso può risultare inferiore a quello di un gateway self-managed, nonostante il costo per-richiesta nominalmente più alto.

Sintesi comparativa

Limiti e problemi aperti

Il single point of failure è il rischio architetturale intrinseco di qualsiasi API gateway centralizzato. Se il gateway diventa indisponibile, l'intero sistema è irraggiungibile dall'esterno, indipendentemente dallo stato dei servizi interni. Le strategie di mitigazione (deployment multi-replica con health check, load balancing a livello DNS o L4, e failover cross-region) riducono il rischio ma non lo eliminano: un errore di configurazione propagato a tutte le repliche (ad esempio una route malformata) può causare un'interruzione totale. Il modello xDS di Envoy mitiga parzialmente questo rischio tramite la validazione delle configurazioni nel control plane prima della propagazione, ma la validazione copre la correttezza sintattica, non quella semantica.

La latenza introdotta dal gateway è un costo non trascurabile. Ogni plugin o filtro nella pipeline aggiunge latenza: un plugin di autenticazione che valida un JWT aggiunge microsecondi, un plugin che contatta un servizio esterno di autorizzazione aggiunge millisecondi. Su percorsi critici con SLA stringenti (e.g., trading ad alta frequenza, real-time bidding), l'overhead cumulativo della pipeline del gateway può eccedere il budget di latenza allocato. In questi scenari, il pattern direct-to-service, in cui il client bypassa il gateway e comunica direttamente con il servizio autenticandosi tramite mTLS gestito dal service mesh, diventa un'alternativa architetturalmente valida, al costo di perdere la centralizzazione delle policy.

Il testing e il versionamento delle configurazioni del gateway sono problemi operativi sottovalutati. Una modifica alla configurazione del rate limiting o delle regole di routing ha un raggio di impatto potenzialmente equivalente a un deploy applicativo, ma raramente riceve lo stesso livello di revisione, testing e rollback controllato. L'adozione di GitOps, dove la configurazione del gateway è versionata in un repository Git e applicata tramite un operatore di reconciliazione, è una best practice emergente, ma gli strumenti di testing specifici per le configurazioni dei gateway (validazione delle regole di routing, simulazione del rate limiting, verifica delle policy di autenticazione) sono significativamente meno maturi rispetto agli strumenti di testing applicativo.

La convergenza tra API gateway e service mesh, pur riducendo la complessità architetturale, introduce nuove sfide di governance. Quando lo stesso data plane (Envoy) gestisce sia il traffico north-south sia quello east-west, le policy di sicurezza e di traffico devono essere coordinate tra team con responsabilità diverse: il team platform che gestisce il gateway e i team applicativi che definiscono le route interne. La Kubernetes Gateway API [3] affronta il problema con il modello role-based (GatewayClass, Gateway, HTTPRoute), ma l'esperienza operativa con questo modello in organizzazioni di grandi dimensioni è ancora limitata, e i pattern di governance efficaci devono ancora consolidarsi.

Infine, l'emergere degli AI gateway, varianti specializzate per il proxying di chiamate a modelli di linguaggio (LLM), introduce requisiti specifici che i gateway tradizionali non gestiscono nativamente: token-based rate limiting (dove il costo di una richiesta dipende dal numero di token nel prompt e nella risposta), streaming di risposte incrementali (server-sent events per la generazione token-by-token), routing semantico basato sul contenuto della richiesta, e caching semantico delle risposte. Il progetto Envoy AI Gateway [14], sviluppato da Tetrate e Bloomberg sotto l'egida della CNCF, è il primo tentativo open-source di integrare queste capability nel data plane Envoy, ma la maturità produttiva di questi componenti è ancora in fase iniziale.

Riferimenti

[1] C. Richardson, Microservices Patterns: With Examples in Java, Manning Publications, 2018. https://www.manning.com/books/microservices-patterns

[2] S. Newman, "Backends For Frontends," Pattern description, 2015. https://samnewman.io/patterns/architectural/bff/

[3] Kubernetes SIG-Network, "Gateway API," Kubernetes official documentation, 2023-2025. https://gateway-api.sigs.k8s.io/

[4] Kong Inc., "Kong Gateway Documentation," 2024-2025. https://docs.konghq.com/gateway/latest/

[5] Envoy Proxy, "Envoy Documentation," CNCF, 2024-2025. https://www.envoyproxy.io/docs/envoy/latest/

[6] D. Hardt (Ed.), "The OAuth 2.0 Authorization Framework," RFC 6749, IETF, 2012. https://datatracker.ietf.org/doc/html/rfc6749

[7] M. Jones, J. Bradley, N. Sakimura, "JSON Web Token (JWT)," RFC 7519, IETF, 2015. https://datatracker.ietf.org/doc/html/rfc7519

[8] V. Bertocci, "JSON Web Token (JWT) Profile for OAuth 2.0 Access Tokens," RFC 9068, IETF, 2021. https://www.rfc-editor.org/rfc/rfc9068.html

[9] Amazon Web Services, "Amazon API Gateway Documentation," 2024-2025. https://docs.aws.amazon.com/apigateway/

[10] Envoy Proxy, "Go/gRPC Rate Limit Service," GitHub repository, 2024. https://github.com/envoyproxy/ratelimit

[11] CNCF, "Use Envoy Gateway as the Unified Ingress Gateway and Waypoint Proxy for Ambient Mesh," CNCF Blog, 2025. https://www.cncf.io/blog/2025/08/26/use-envoy-gateway-as-the-unified-ingress-gateway-and-waypoint-proxy-for-ambient-mesh/

[12] OpenTelemetry Authors, "OpenTelemetry Specification," CNCF, 2024-2025. https://opentelemetry.io/docs/specs/otel/

[13] Kong Inc., "Kong Gateway Performance Benchmarks and Open Source Test Suites," Kong Engineering Blog, 2024. https://konghq.com/blog/engineering/performance-benchmarks-and-open-source-test-suites

[14] Tetrate and Bloomberg, "Envoy AI Gateway," CNCF Blog, 2025. https://www.cncf.io/blog/2024/10/18/open-collaboration-to-bring-ai-gateway-features-to-the-envoy-community/