RD
Torna al portfolio

Case study di architettura / Booka

Booka: tre applicazioni, un solo modello dati.

Booka è un SaaS verticale per saloni composto da marketplace pubblico, gestionale B2B e console superadmin. Ho progettato un monorepo con deploy separati e una fondazione Supabase condivisa, così ogni prodotto può evolvere senza duplicare identità, prenotazioni e dati dei saloni.

Ruolo
Software architect
Proprietà
Progetto mio e di Giulio
Perimetro
Architettura, delivery, passaggio in produzione
Forma
Monorepo, tre deploy, un database
Stato
In produzione
Apri booka-app.it
01

Il requisito architetturale

Marketplace, gestionale B2B e console superadmin hanno utenti, frequenze di rilascio e profili di rischio diversi. Il sito pubblico cambia con le attività commerciali; il gestionale segue le esigenze operative dei saloni; la console amministrativa richiede maggiore stabilità e accessi più restrittivi.

I tre prodotti condividono però le stesse entità: saloni, prenotazioni e persone. Uno stesso account può essere cliente e titolare di un'attività. Separare anche i dati avrebbe introdotto duplicazioni, sincronizzazioni e ambiguità sull'identità.

L'obiettivo era quindi mantenere indipendenti i cicli di rilascio senza frammentare il modello dati.

02

Le opzioni architetturali

Ho confrontato tre configurazioni rispetto a indipendenza dei rilasci, coerenza dei dati, sicurezza e costo di manutenzione.

  1. Tre repository

    Ogni prodotto ha il suo codice, la sua pipeline, il suo database.

    Autenticazione, accesso ai dati e componenti condivisi verrebbero duplicati. Ogni modifica allo schema richiederebbe coordinamento tra tre sistemi e la stessa persona potrebbe avere identità distinte.

    Scartata: massima indipendenza applicativa, ma costi elevati di sincronizzazione e manutenzione.

  2. Una sola applicazione

    Un unico deploy che mostra un'interfaccia diversa a seconda di chi ha fatto accesso.

    Marketplace pubblico, gestionale e console amministrativa condividerebbero bundle, ciclo di rilascio e raggio di impatto. Una modifica a basso rischio sul sito pubblico potrebbe coinvolgere strumenti operativi più sensibili.

    Scartata: semplicità iniziale, ma isolamento insufficiente tra prodotti con profili di rischio diversi.

  3. Monorepo, tre deploy

    Un repository, una fondazione condivisa, tre applicazioni rilasciate separatamente, un database con proprietà esplicita degli ambienti.

    Richiede confini applicativi espliciti, ownership del codice condiviso e pipeline capaci di distribuire solo le applicazioni interessate da una modifica.

    Scelta: mantiene unico il modello dati e separa i cicli di rilascio.

03

Architettura implementata

La soluzione utilizza tre applicazioni Next.js nello stesso monorepo, distribuite separatamente e collegate a una fondazione Supabase comune. Ogni ambiente e ogni variabile hanno un proprietario esplicito.

La stessa struttura supporta funnel pre-lancio, gestione dei consensi, email transazionali, routing multilingua e il percorso di adeguamento fiscale.

Pipeline, configurazione e documentazione di handover fanno parte dell'architettura: il sistema deve poter essere rilasciato e gestito anche da persone diverse dal suo autore.

04

Benefici operativi

Ogni applicazione può essere rilasciata senza coinvolgere le altre, riducendo il raggio di impatto delle modifiche.

Le migrazioni dello schema vengono definite una sola volta e sono applicate alla stessa base dati, evitando sincronizzazioni tra sistemi paralleli.

L'identità rimane coerente in tutti i prodotti, anche quando una persona ricopre più ruoli.

La piattaforma è passata dalla validazione all'operatività commerciale mantenendo lo stesso modello di delivery.

Serve una decisione architetturale simile?

Lavoro su prodotti che devono separare applicazioni, utenti o cicli di rilascio senza perdere coerenza nei dati e nella gestione operativa.

hello@robertodrago.dev