L'API gateway sviluppato internamente ci ha permesso di risparmiare il 38% sui costi delle chiamate a terze parti, ma abbiamo incontrato problemi nell'adattamento alle diverse regioni.

La scorsa settimana il nostro team di strumenti di e-commerce del sud-est asiatico ha appena rivisto la fattura del costo tecnico di Q1, il collega responsabile dell 'interfaccia di pagamento quasi saltato: dopo aver sostituito il gateway di terze parti utilizzato in precedenza con uno studio personale, il costo mensile di chiamata API è stato ridotto del 38%, ma nel test di scala di grigio prima della grande promozione, il tasso di successo del pagamento degli utenti del nodo di Singapore è improvvisamente diminuito di 6 punti percentuali, dopo aver verificato che le regole di fusione tra regioni del gateway non sono state adattate.

Prima di tutto: cos'è esattamente un gateway personalizzato?

In poche parole, scrivete un programma di ingresso di traffico, mettendo tutte le richieste API esterne, callback di terze parti e chiamate cross-service attraverso questo livello, sostituendo i servizi di gateway di terze parti acquistati prima. La versione che stiamo utilizzando ora è eseguita su 4 server di nodi esteri a 2 core 4G, una singola unità può trasportare 1200 richieste al secondo, coprendo completamente la nostra media giornaliera di 1,8 milioni di richieste di pagamento e di chiamate sincronizzate di merci.

I tre vantaggi concreti che puoi ottenere sono:

• Prima di tutto, i costi possono davvero essere ridotti. Il gateway di terze parti che utilizzavamo in precedenza addebitava una tariffa in base al numero di chiamate, con un costo mensile di 2100 dollari. Ora, con il server che abbiamo costruito internamente e i costi di monitoraggio, il costo mensile è inferiore a 1300 dollari, inoltre non siamo soggetti a aumenti di prezzo progressivi.
• In secondo luogo, le regole sono completamente gestite da noi stessi. In precedenza, il limitazione del traffico gestita dai gateway di terze parti era uniforme; durante le promozioni, dovevamo richiedere temporaneamente quote di limitazione per le interfacce di pagamento, e per farlo era necessario inviare una richiesta di lavoro che richiedeva 3 giorni lavorativi. Ora, modificando la configurazione direttamente dal backend, tutto entra in vigore in soli 10 secondi.
• Infine, non è necessario utilizzare terze parti per l’elaborazione dei dati. Poiché sviluppiamo strumenti per il commercio elettronico, dobbiamo gestire i callback di pagamento di molti utenti. In precedenza, tutte le richieste passavano attraverso i server dei fornitori di servizi terzi, ma ora tutti i dati sensibili vengono elaborati direttamente sui nostri server, il che ha ridotto notevolmente i costi legati alla conformità alle normative.

Non affrettarti a costruire qualcosa; prima diamo un’occhiata ai problemi che abbiamo già incontrato.

Il primo problema è quello dell’adattamento della rete tra diverse regioni. All’inizio abbiamo posizionato il nodo principale del gateway a Singapore; quando abbiamo aperto il sito in Malesia, abbiamo semplicemente reindirizzato il traffico direttamente verso di esso. Di conseguenza, le richieste degli utenti locali dovevano prima passare per Singapore per poi essere inviate al sito in Malesia, causando un ritardo di rete di 200 millisecondi. Molti utenti, non potendo attendere, hanno semplicemente chiuso la pagina di pagamento. Abbiamo impiegato una settimana per completare la configurazione dei nodi di edge in Malesia.

Il secondo problema è rappresentato da una lacuna nelle regole di sicurezza. In precedenza, i gateway di terze parti includevano di default funzionalità per la protezione contro attacchi DDoS e l’intercettazione di richieste malintenzionate; tuttavia, quando abbiamo implementato il sistema da soli, abbiamo dimenticato di includere queste funzionalità. Nel terzo giorno di attività, il sistema ha ricevuto 200.000 richieste invalidi da parte di bot, il che ha quasi causato il blocco dell’interfaccia di gestione degli stock.

Il terzo problema è che i costi di manutenzione e gestione sono più elevati del previsto. In precedenza, quando c’erano problemi con i gateway di terze parti, ci si rivolgeva direttamente al servizio clienti; ora, i tre sviluppatori del backend devono turnarsi per fare il turno di notte per monitorare i gateway. Solo lo scorso mese, la risoluzione dei guasti ai gateway ha occupato il 15% del tempo di lavoro di tutti.

Quali tipi di squadre sono adatte per collaborare? Con quali invece non sprecare tempo?

Se il tuo team effettua più di un milione di chiamate API al giorno, se hai una grande quantità di dati sensibili da gestire, o se sei stanco dei limiti di traffico imposti dai gateway di terze parti e dei loro processi di gestione delle richieste, allora costruire un gateway interno è sicuramente un investimento che vale la pena.

Ma se il tuo team ha meno di 2 sviluppatori del lato server, o se l’attività aziendale è ancora in una fase di rapido tentativo ed errore in cui le regole delle interfacce cambiano ogni settimana, allora non c’è davvero bisogno di investire tempo in questo. È sufficiente utilizzare un gateway di terze parti per il momento; potrai cambiare più tardi, quando l’attività sarà più stabile.

3 consigli pratici per chi lo fa per la prima volta

1. Iniziamo con un singolo scenario, senza sostituire tutto all’improvviso. All’inizio abbiamo spostato il traffico delle interfacce di pagamento verso il nostro gateway interno, e dopo due settimane di funzionamento senza problemi, abbiamo iniziato a migrare anche le altre interfacce. In questo modo, se dovesse verificarsi un problema, riguarderebbe soltanto lo scenario di pagamento e non l’intero sito web.
2. È essenziale eseguire test di stress a livello regionale. Soprattutto per le attività internazionali, non basta testare solo in locale prima di lanciare il prodotto: è necessario utilizzare i nodi di test del mercato target per eseguire test di stress continuativi per 24 ore, al fine di verificare se ci sono problemi di latenza o tassi di perdita di pacchetti.
3. Non risparmiare sul pannello di monitoraggio: tieni d’occhio almeno tre indicatori chiave, ovvero il numero di richieste, il tasso di successo e i tempi di latenza. Imposta dei valori di soglia per gli avvisi, in modo da scoprire tempestivamente eventuali problemi con il gateway, prima che gli utenti inizino a lamentarsi.

Problemi comuni

Domanda: È obbligatorio scrivere il codice in Go o Rust?
No, la nostra prima versione è stata scritta in Node.js e riesce comunque a gestire i picchi di traffico. Utilizzate semplicemente il linguaggio con cui il vostro team è più a suo agio; potrete cambiare in seguito, se si verificano problemi di prestazioni.

Domanda: Qual è migliore rispetto ai gateway forniti dai provider di cloud?
I gateway forniti dai provider di cloud sono più flessibili rispetto a quelli di terze parti, ma comunque non offrono la stessa libertà di utilizzo rispetto a quelli creati internamente all’azienda. Se non si desidera essere vincolati a un determinato provider di cloud, costruire il proprio gateway rappresenta una scelta più vantaggiosa.