
Event-Driven Architecture: The Hard Parts
Quick takeaways Event-driven architecture (EDA) is powerful but tricky – it’s great for scaling and decoupling, but has many hidden traps. Observability is essential – debugging async systems without tracing, logs, and correlation IDs is almost impossible. Use the outbox pattern – it’s the safest way to publish events without losing data. Design events carefully – large, generic events can lead to tight coupling and painful refactors.

Synchronous vs Asynchronous Architecture
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.

When to avoid DRY in Go
In case you’re here for the first time, this post is the next in our Business Applications in Go series. Previously, we introduced Wild Workouts, our example application built in a modern way with some subtle anti-patterns. We added them on purpose to present common pitfalls and tips on how to avoid them. In this post, we begin refactoring of Wild Workouts.

When using Microservices or Modular Monolith in Go can be just a detail?
Nowadays we can often hear that monolithic architecture is obsolete and responsible for all evil in IT. We often hear that microservices architecture is a silver bullet which helps to kill all this monolithic evil. But you probably know that there are almost no silver bullets in IT and every decision entails trade-offs. One of the most favored advantages of microservices architecture is good modules separation.
Series
Popular articles
- The Go libraries that never failed us: 22 libraries you need to know
- Safer Enums in Go
- Common Anti-Patterns in Go Web Applications
- How to implement Clean Architecture in Go (Golang)
- The Repository pattern in Go: a painless way to simplify your service logic
- Introduction to DDD Lite: When microservices in Go are not enough
Tags
- go
- golang
- watermill
- ddd
- clean-architecture
- domain-driven design
- events
- web-applications
- anti-patterns
- event-driven
- ci
- firestore
- software-development
- architecture
- cloudrun
- gcloud
- googlecloud
- serverless
- testing
- advanced
- databases
- devops
- firebase
- gitlab
- microservices
- reactive
- repository
- backend
- basics
- building-business-applications
- building-in-public
- cqrs
- frameworks
- kafka
- mysql
- nats
- pipelines
- scalability
- software-architecture
- transactions
- amqp
- authentication
- balance
- bounded-context
- c4
- cicd
- code-quality
- code-review
- design-patterns
- diagrams
- docker
- dry
- e-book
- efficiency
- enums
- event-storming
- gamedev
- generics
- google-cloud
- grpc
- htmx
- intermediate
- iteration
- javascript
- learning
- libraries
- maintainability
- metrics
- monolith
- open-source
- openapi
- over-engineering
- overengineering
- parallelism
- productivity
- programming-languages
- prometheus
- pull-requests
- python
- rabbitmq
- retrospective
- security
- sql
- sse
- startups
- strategic-ddd
- swagger
- terraform
- tips
- unpopular-opinions
- versioning