Event-Driven Dumpsterfire: Part 1 of 3

Thanks ChatGPT for this lit image

This is part 1 of a 3 part series about event-driven architecture. In this part I cover why EDA is hard to get right, and the subtle shift in reasoning required to avoid architectural pitfalls. In part 2, I address one of the pitfalls: message ordering. And in part 3 I’ll cover the other major pitfall: event schemas.

1. Event-Driven Dumpsterfire: Part 1 of 3
2. (Message) Order out of Chaos: Part 2 of 3
3. Coming soon! Part 3 of 3

I started my career on a backend team building services that communicated through queues. While some had SOAP endpoints (if anyone remembers those), and eventually REST and gRPC endpoints, the bulk of my time was spent on all the asynchronous message passing.

I loved it. Async messaging comes with many benefits: your servers don’t need to be highly-available, you can retry messages, and you can easily protect your dependencies by putting backpressure on your message queue or bus. Then of course—my personal favorite—you usually don’t need to wake up at 3am if something breaks because the messages will still be there to process in the morning!

We were using queue technologies like RabbitMQ, and then eventually SQS, to send tasks from one system to another. Since they were intended for one consumer and were telling the consumer what to…