Full episode notes: https://threedots.tech/episode/sync-vs-async/
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
In this episode, we discuss when to choose synchronous versus asynchronous architecture for backend systems.
We talk about the trade-offs between simple, predictable sync communication and the complexity but resilience of async approaches using message queues and event-driven architecture.
Instead of picking one approach over another, we focus on understanding when each makes sense and how to avoid common pitfalls like distributed monoliths and over-engineering.
- Go Event-Driven training
- Watermill - our open-source Go library for working with message streams
- Event Storming - a design technique with a great unfinished ebook by Alberto Brandolini
- CQRS (Command Query Responsibility Segregation) - a pattern that works well with both sync and async approaches
- Our CQRS article and Server-Sent Events post
- Message brokers mentioned: RabbitMQ, Kafka, NATS, Google Cloud Pub/Sub
- Event schemas: Protobuf, Avro, CloudEvents
- Event Sourcing - a pattern mentioned in context of recreating state from events
- Clean Architecture/Hexagonal Architecture - architectural patterns mentioned for making sync/async migration easier
IntroductionShow Notes
