Sta facendo molto parlare di se in questi giorni la funzione cashback della app IO che dovrebbe restituirci fino al 10% per un massimo di 1500 euro dei pagamenti effettuati tramite carta fino alla proroga sembra al 6 gennaio. Nella fase sperimentale fino al 31 dicembre sono richieste almeno 10 operazioni cashless.
Per ottenere il rimborso occorre installare la app IO, registrarsi con la carta di identità elettronica o con lo SPID e successivamente caricare finalmente i nostri metodi di pagamento e il nostro IBAN dove ci restituiranno il cashback.
Sfortunatamente, contrariamente alla app immuni, questa applicazione ha riscosso notevole successo e i server sono talmente intasati che appena si prova a registrare un nuovo metodo di pagamento si ottiene l’errore
Si è verificato un errore temporaneo nel salvataggio di questa carta, riprova.
Inutile provare e riprovare, significa semplicemente che i server della applicazione vanno in timeout, detto piu’ volgarmente sono intasati: l’unica soluzione al momento è provare verso le due tre di notte quando ci saranno poche persone collegate. Alcune persone ci hanno riferito che in tal modo ci sono riusciti.
L’unica accortenza una volta registrati è di non fare pagamenti prima delle successive 24 ore altrimenti non saranno registrati nella app e non si riceverà il rimborso, che ricordiamo è ottenibile solo effettuando almeno 10 operazioni con la carta o le carte registrate nei metodi di pagamento.
L’importanza del dimensionamento del server
Questo problema ci porta a parlare di un argomento e di una domanda che pochi spesso si pongono nel momento in cui intraprendono un nuovo progetto software.
Quando si sviluppa una piattaforma in cloud quale puo’ essere una applicazione mobile, bisogna tenere conto che potenzialmente potrebbero essere milioni gli utenti che potrebbero scaricarla anche solo per curiosità e quindi bisogna tenere questa cosa in forte considerazione nel momento del business plan per l’acquisto o il noleggio del cloud server che ospiterà la nostra applicazione. Questa operazione si chiama tecnicamente load balancing.
Innanzitutto bisogna considerare un server molto potente già dall’inizio perche’ molti tendono a risparmiare dicendo poi quando gli utenti aumenteranno poi lo ridimensionerò: niente di piu’ sbagliato.
Un server lento fin da subito peggiorerà la user experience e magari persone interessate che stanno provando la vostra applicazione mobile desisteranno subito magari trovandola lenta e quindi poco frubile.
Altra cosa importantissima da considerare è la clusterizzazione dei server e il disaster recovery.
E ‘importante avere fin da subito due server dedicati uno per la parte web server ed uno come server di database che sia ridondato e con procedure di disaster recovery in modo che in caso di failover il sistema resti sempre e comunque in piedi.
La business continuity è infatti una delle cose piu’ importanti quando si mette in piedi un nuovo progetto sul web sia essa una web application sia una applicazione mobile con un BackOffice alle spalle per alimentarne e configurarne i dati.
Notevole importanza in questo discorso per evitare timeout come la app IO è pure la larghezza di banda, che può essere stimata in base ad un semplice calcolo: supponiamo che tu abbia un sito web con una dimensione media della pagina di 50 KB e che ti aspetti 100.000 visitatori al mese.
Se ciascuno dei visitatori accede a una media di 10 pagine al mese, sarà necessario un minimo di 100000 x 50 KB x 10 = 5000 MB o 5 GB di larghezza di banda. Avere sempre capacità extra per garantire che il tuo sito web continui a funzionare quando c’è un carico aggiuntivo.
Tornando alla applicazione IO per il rimborso degli acquisti fatti con carta non sappiamo di preciso cosa sia successo, ma sicuramente i sistemisti saranno al lavoro per aumentare le risorse dei server che ospitano la piattaforma che al momento della registrazione della gran parte delle carte dovrebbe entrare a regime con carichi inferiori a quelli attuali e quindi funzionare correttamente.
Mentre le registrazioni delle carte avvengono on line, le registrazioni dei pagamenti possono avvenire infatti anche in maniera asincrona con dei batch notturni, quindi crediamo che la seconda parte del funzionamento della app ossia la registrazione dei pagamenti per inviare i rimborsi sui codici iban degli utenti della app non dovrebbe creare grossi problemi.
