Pagina 1 di 1
L'architettura event-driven è potente per disaccoppiare componenti che altrimenti crescerebbero in monoliti impossibili da modificare. È anche facile da rovinare: eventual consistency sottovalutata, eventi sbagliati come contratto, pattern saga implementati ad hoc. Richiede disciplina architetturale.
In questa categoria scrivo di architetture event-driven applicate: Kafka, RabbitMQ, Redis pub/sub, pattern saga, CQRS. Parliamone, scopri il mio approccio.
Un'azienda di spedizioni aveva cinque sistemi legacy che dovevano scambiarsi eventi in tempo reale. REST era troppo fragile, RabbitMQ non reggeva i volumi. Ho introdotto Kafka con un client PHP su Swoole: 50.000 eventi al giorno con perdita zero e consumer che ripartono dall'ultimo offset in caso di crash. Continua a leggere
Un gestionale ordini con 14 side effect per ogni conferma d'ordine: email, aggiornamento magazzino, contabilità, notifiche. Tutto in un controller. Ho refactorizzato verso event-driven: un evento OrderConfirmed, undici handler indipendenti, deployment graduale. Il codice è passato da ingestibile a modificabile. Continua a leggere
Un cliente mi ha chiesto di trasformare il suo monolite Laravel in microservizi 'perché lo fanno tutti'. Ho fatto l'analisi: 15 sviluppatori, 3 domini di business ben separati, un servizio con requisiti di scaling indipendenti. Alla fine ne abbiamo estratti due soli. Vi racconto i criteri di decisione reali. Continua a leggere
