Architettura di una piattaforma B2B per l'affiliate tracking e l'attribuzione dei ricavi
Durante lo sviluppo di una piattaforma B2B commerciale nel campo dell'affiliate tracking e dell'attribuzione dei ricavi, una delle sfide principali era progettare un backend in grado di gestire un flusso continuo di eventi e-commerce esterni senza compromettere la logica di business interna.
Nella pratica, questo significava separare un nucleo di dominio stabile da un livello di integrazione ad alto carico. Senza questa separazione, i picchi di traffico esterni — ordini, aggiornamenti di stato, eventi marketplace — avrebbero impattato direttamente le parti critiche del sistema come la logica delle commissioni o le regole finanziarie.
Separazione del nucleo di business e del livello di integrazione
L'architettura si basava su due livelli indipendenti.
Il nucleo di business gestiva tutto ciò che doveva rimanere stabile: strutture aziendali, gerarchie di ruoli, regole di commissione e logica finanziaria. Questa parte del sistema doveva essere prevedibile e rigorosamente controllata.
Il livello di integrazione, al contrario, elaborava i dati esterni — eventi in ingresso, flussi di sincronizzazione e interazioni con i marketplace. Era progettato per assorbire carico e variabilità senza propagare tale complessità nel nucleo del dominio.
Questa separazione ha permesso di scalare il sistema sotto carico elevato mantenendo al contempo la coerenza dei processi interni.
RBAC e spazio di lavoro multi-livello
Un'altra componente importante del sistema era il modello interno di spazio di lavoro e controllo degli accessi.
Per una piattaforma B2B multi-utente, abbiamo implementato un sistema Role-Based Access Control (RBAC) a più livelli.
Il controllo degli accessi era applicato non solo a livello di interfaccia, ma anche su route, operazioni sui dati ed endpoint API. Questo era fondamentale perché ruoli diversi — titolari d'azienda, manager, operatori, agenti, osservatori — interagiscono tutti con lo stesso sistema in modi molto differenti.
Con l'aumentare del numero di ruoli ed entità, questo modello ha permesso di mantenere il comportamento prevedibile anziché caotico.
Architettura API ibrida
Il livello API seguiva un approccio ibrido.
Per le operazioni standard, gli endpoint CRUD venivano generati sulla base dei modelli di dominio e dell'infrastruttura condivisa. Questo manteneva lo sviluppo rapido e coerente.
Ma per la logica critica — operazioni finanziarie, aggregazioni, dashboard, routing personalizzato — tutto era implementato manualmente. Erano le parti in cui perdere il controllo non era un'opzione.
Alla fine, questo equilibrio tra automazione e controllo manuale ha permesso di procedere rapidamente senza introdurre instabilità nel sistema.