L'ingegneria di Vowly Event: inviti di nozze digitali e RSVP online

Vowly Event fa una cosa che sembra semplice finché non la si costruisce: invia inviti di nozze digitali e raccoglie le risposte online. Una coppia, una lista di invitati, centinaia di persone che devono ricevere qualcosa di personale e rimandare indietro qualcosa. Il prodotto lo costruiamo e lo gestiamo noi: ecco come ragioniamo sulle parti più difficili di quanto sembrino.

Il prodotto è la lista degli invitati

Quasi tutti pensano che il prodotto sia l'invito. Non lo è. L'invito è la superficie visibile; la lista degli invitati porta tutto il peso. Viene modificata di continuo, fino alla settimana del matrimonio. I nomi si correggono, compaiono accompagnatori, dopo una telefonata con un genitore si aggiunge un'intera famiglia e qualcuno viene tolto in silenzio.

Il modello dei dati non può quindi trattare un invitato come una riga scritta una volta sola. Un invitato è una piccola storia: invitato, ha aperto, ha risposto, ha cambiato idea, è tornato indietro. Modellare solo lo stato corrente significa rinunciare a rispondere alla domanda che le coppie fanno davvero — non «quanti vengono», ma «chi non ha ancora risposto, e l'ha almeno aperto».

Nuclei familiari, non individui

La seconda scelta di modellazione che ripaga è il raggruppamento. Gli inviti vanno ai nuclei familiari, non alle persone. Una famiglia di quattro riceve un invito e risponde una volta, ma disposizione dei tavoli, conteggio del catering e note alimentari richiedono i singoli. Sbagliarlo presto costringe ogni funzionalità successiva a girarci intorno: entità invitato ed entità invito vanno separate dal primo commit.

Traffico che arriva a ondate

Il traffico di un matrimonio non è una curva regolare. La coppia manda gli inviti una domenica sera e gran parte della lista apre il link nelle due ore successive. Poi per una settimana non succede quasi nulla. Poi arriva un secondo picco quando parte il promemoria.

Questa forma premia scelte precise. La pagina dell'invito dovrebbe essere statica o quasi e servita da una cache di bordo, perché è identica per tutti gli invitati di un nucleo ed è ciò che incassa l'ondata. Il percorso di scrittura — l'invio dell'RSVP — è l'unica parte che deve davvero raggiungere un database ed è una frazione minima delle richieste. Separarli significa dimensionare l'infrastruttura costosa per le risposte, non per le visualizzazioni.

La parte difficile e poco glamour: la consegna

Inviare qualche centinaio di messaggi è facile. Far sì che arrivino tutti no. Gli inviti passano da canali che il mittente non controlla, e un messaggio finito nello spam è, dal punto di vista della coppia, indistinguibile da un invitato che li ignora.

• Autenticare correttamente il dominio di invio — SPF, DKIM e DMARC non sono facoltativi quando l'intero prodotto dipende dalla consegna.
• Tracciare aperture e clic per invitato, così la coppia vede chi davvero non ha visto l'invito invece di tirare a indovinare.
• Ogni link deve funzionare senza account. Un muro di login tra un invitato e il modulo RSVP costa risposte.
• Dare per scontato che alcuni invitati telefoneranno alla coppia. L'inserimento manuale dev'essere un percorso di prima classe, non un espediente da pannello di amministrazione.

Dove si colloca l'app

Vowly Event esiste anche come app su App Store e Google Play. La divisione utile è questa: la superficie web appartiene all'invitato, l'app alla coppia. All'invitato non si deve mai chiedere di installare nulla; riceve un link e un modulo. La coppia, che aprirà il prodotto decine di volte nell'arco di mesi, ottiene la superficie più ricca in cui vive la lista.

Cosa diremmo a un altro team

Costruite prima la lista degli invitati, poi i design degli inviti. Trattate la recapitabilità come un problema di ingegneria con metriche, non come un'impostazione da configurare una volta. E dimensionate per l'ondata di lettura, non per la media — la media non significa nulla quando il traffico arriva in ondate di due ore.