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

Louie Giglio