One action, multiple reactions

Building event-driven systems changed how I think about software.

Services shouldn't call each other constantly. They should react to events.

Example:

User signs up → Auth emits an event
→ Notification service sends the welcome email
→ Analytics service records the signup
→ User service continues onboarding

One action. Multiple reactions.

The biggest shift is mental: you stop designing request chains and start designing system reactions. The signup service doesn't need to know who cares that a user signed up — it publishes the fact, and the system reacts.

The honest cost: debugging gets harder. A request chain fails in one place, with a stack trace. An event fans out, and the failure can hide inside any of the reactions — so observability stops being optional, and patterns like the transactional outbox (write the event in the same transaction as the state change, so the two can never disagree) stop being nice-to-haves.

I run an email platform built this way: a send is one action, and delivery, bounces, complaints and suppression are all reactions to provider events. It's the only shape I've found that scales without the services strangling each other.

Next in this series: code evolves quickly, databases remember everything. I write about backend systems that look small until they aren't — follow along if that's your world; the longer pieces live on my Substack.