Event Driven Architecture: The Hard Parts

Quick takeaways Start with synchronous architecture by default - it’s simpler to understand, debug, and maintain for most use cases Async architecture improves scalability and resilience - message queues and events help handle traffic spikes and failures Design matters more than the technology choice - tight coupling creates the same problems in both sync and async approaches Consider team experience - async architecture require more experienced teams and better tooling to handle new challenges Adjust as your system grows - external APIs, heavy operations, or the need to handle failures gracefully are good use cases Hybrid approach - use both sync and async where they fit best, rather than forcing one over the other Introduction In this episode, we discuss when to choose synchronous versus asynchronous architecture for backend systems.

Quick takeaways Solve real problems first - successful open source projects start by addressing actual needs, not by looking for problems to fit a solution Keep breaking changes minimal - Watermill stayed on v1 for 6 years with no breaking changes in the core library, building trust with users Examples and documentation are crucial - provide real-world examples with automated tests, not just simple “hello world” demos Promotion matters - creating a great library isn’t enough; you need to actively share it through conferences, blog posts, and communities Be patient with growth - Watermill took 7 years to reach 8,000 stars; overnight success in open source is rare Introduction In this episode, we share the story of how Watermill, our event-driven library for Go, grew from a side project to a popular open source library with over 8,000 GitHub stars and 100+ contributors.