Skip to content
Berktug Berke Ates
Berktug Berke Ates

Software Engineer

Blog

Design event-driven per backend di prodotto

· 8 min di lettura

Gli eventi aiutano i prodotti a scalare i workflow—se li tratti come contratti, non come firehose.

Emetti fatti sul business

Gli eventi utili descrivono qualcosa di significativo che è successo: ordine effettuato, registrazione elaborata, membership aggiornata. Non sono un dump di righe di database o una remote procedure call mascherata. Nomina gli eventi al passato e includi abbastanza contesto perché i consumer agiscano senza callback chiacchieroni.

Versiona il payload. I consumer evolvono a ritmi diversi, e un rename breaking di un campo può cascatare in fallimenti silenziosi tra team.

Isola i consumer di proposito

Ogni consumer deve possedere un esito specifico: inviare email, aggiornare l’indice di ricerca, provisionare entitlement o notificare l’analytics. Condividere un worker gigante per side effect non correlati ricrea un monolite con modalità di fallimento peggiori.

Backpressure, retry e dead-letter queue appartengono a ciascun consumer. Un messaggio tossico nelle notifiche non deve bloccare l’indicizzazione di ricerca.

  • Rendi gli handler idempotenti di default
  • Preferisci delivery at-least-once con chiavi di deduplicazione
  • Documenta le garanzie di ordinamento con onestà
  • Traccia i flussi di produzione tra publish e consume

Accetta il tradeoff di consistenza

I sistemi event-driven spesso abbracciano la consistenza eventuale. Copy di prodotto e UI devono riconoscere che alcuni stati si allineano in modo asincrono. Mostrare uno stato di elaborazione è meglio che fingere che ogni side effect sia istantaneo.

Dove serve forte consistenza—saldi, prenotazioni di inventario, vincoli di unicità—tieni quella logica in un confine transazionale ed emetti eventi dopo il commit.

Opera la coreografia

Senza correlation ID, metriche di lag e strumenti di replay, i sistemi a eventi diventano misteriosi. Costruisci la capacità di riprocessare in sicurezza una finestra di eventi dopo un bug fix. Misura il lag dei consumer come segnale di affidabilità rivolto all’utente.

Il design event-driven ripaga quando i team possono estendere il comportamento del prodotto aggiungendo consumer senza destabilizzare il percorso transazionale centrale.


Pubblicato il 24 luglio 2024 da Berktug Berke Ates.