NO SILVER BULLET

Episode notes: https://threedots.tech/episode/the-distributed-monolith-trap/

We talk about splitting software: when to do it, how to avoid common pitfalls, and why microservices aren’t always the answer. We share stories from past projects where we jumped on the microservices hype train without thinking through the real problems we were trying to solve. The key insight is that splitting software is more about organizing teams and maintaining good boundaries than about technology.

Episode notes: https://threedots.tech/episode/overcomplicated-vs-oversimplified-code/

Quick takeaways

• Complexity comes from two extremes - projects fail both when they’re overcomplicated with unnecessary patterns and when they’re oversimplified for a complex domain
• Essential vs accidental complexity - essential complexity comes from the domain itself and can’t be removed, accidental complexity is created by poor implementation choices
• “Keep it simple” is lazy advice - achieving simplicity takes effort; closing your eyes to complexity just pushes it elsewhere
• Match patterns to the problem - using the same approach everywhere is a red flag; mix simple solutions for simple parts and sophisticated patterns for complex domains
• Ship fast and iterate - if you can’t deploy daily and fear making changes, something is wrong regardless of whether it’s over or under-engineered

We discuss where complexity in software projects comes from and how to deal with it. There are two common extremes: projects that are overcomplicated because someone applied patterns they saw at a conference without understanding them deeply, and projects that started simple but became a tangled mess as they grew.

Both can be equally difficult to work with. The key insight is understanding the difference between essential complexity (inherent to your domain) and accidental complexity (created by your implementation choices). We share diagnostic signals to identify unhealthy projects and practical advice on matching your tools to the actual problem you’re solving.

• No Silver Bullet paper by Fred Brooks - discusses essential vs accidental complexity
• Domain-Driven Design (DDD) - a pattern for tackling complex domains
• Clean Architecture - another approach for managing complexity
• YAGNI (You Aren’t Gonna Need It) - principle against premature generalization
• Defensive programming - validating inputs early to prevent errors propagating
• Canary releases and rollbacks - deployment strategies that can add overhead
• Three Dots Labs blog - articles on Go patterns and architecture
• Go with the Domain ebook - free ebook about DDD in Go with 60,000+ downloads
• Wild Workouts example DDD project - complex Go project demonstrating real-world patterns
• Microservices architecture - discussed as sometimes adding unnecessary complexity
• CRUD applications - simple approach that works for some domains but not others
• The Domain Engineer training - upcoming training mentioned for early next year

Full episode notes: ⁠https://threedots.tech/episode/ddd-toolbox-not-religion/

Quick takeaways

• Domain complexity matters more than technical complexity - Most projects fail not because of technical challenges, but because they don’t handle the business domain well.
• DDD is a toolbox, not a religion - You don’t need to use every pattern from Domain-Driven Design. Pick what solves your actual problems.
• Start with the domain model - Understanding how the business works is more important than designing the perfect schema.
• Avoid solving imaginary problems - Spending months on frameworks or platforms before building actual features often leads to wasted effort.
• Strategic patterns are essential for everyone - Even if you don’t use tactical DDD patterns, thinking about core domains and module boundaries matters in every project.

In this episode, we discuss why software projects become legacy code that nobody wants to touch.

We talk about how Domain-Driven Design can help, but also why it’s often misunderstood or overused.

Instead of treating DDD as an all-or-nothing approach, we suggest to use the ideas pragmatically - picking the patterns that solve real problems in your project.

We share stories to show how focusing on domain complexity rather than technical complexity leads to better software.

In this episode, we talk about why software projects in regular jobs are delivered much slower compared to side projects, and what you can do about it.

We share our journey from building hobby projects as teenagers to working in professional environments, and the differences we encountered.

Developers are often kept isolated from product decisions and treated as “coding monkeys in golden cages” - just receiving tasks without understanding the why behind them.

We discuss techniques like Event Storming that can help break down these barriers, and improve collaboration between developers and product managers.

After the summer break, we're back with a new season of No Silver Bullet. New episodes every second Wednesday.

Episode notes: https://threedots.tech/episode/ama-1/

Quick takeaways

• Go in the AI era: Go is excellent for AI applications, as the built-in concurrency makes orchestrating parallel API calls much easier than languages like Python
• Architecture philosophy: Clean Architecture isn’t always necessary. Start simple and add layers only when you feel the pain of complexity, not because someone said you should
• Career transitions: Switching roles within tech is easier internally. Moving from sysadmin to developer works better within the same company where people already trust you
• Go design patterns: Small interfaces near usage is the Go way. Duck typing allows you to define interfaces where they’re used rather than in separate layers
• Distributed systems: Async communication often solves sync timeout issues. When dealing with chains of service calls, consider using messages instead of increasing timeouts

In this special 10th episode, we answer community questions in our first AMA format before taking a summer break.

We discuss Go’s role in AI development, Clean Architecture implementation, career transitions in tech, and distributed system timeouts.

After the break, we’ll switch to pre-recorded episodes with improved production quality. We still plan running some live episodes like this one, so stay tuned!

Full episode notes: https://threedots.tech/episode/prs-that-get-merged-the-same-day/

Quick takeaways

• Prioritize reviews over new work - treat PRs as work that’s almost done and needs to be pushed to production quickly
• Big PRs create a dead loop - when reviews take ages, developers make even bigger PRs to avoid multiple long waits
• Knowledge sharing is the hidden benefit - code reviews aren’t just gatekeeping, they spread understanding of how things work across the team
• One-day cycle time is possible - start work in the morning and merge by end of day with proper team culture and practices
• Split work vertically and horizontally - break features into small slices and layers that multiple people can implement in parallel

In this episode, we discuss how to make code reviews fast and effective by keeping pull requests small.

We explore why big PRs are problematic, what causes them, and practical strategies to create PRs that can be merged within a day.

Instead of waiting days for reviews with 200 comments, we focus on techniques that help teams achieve smooth, fast review cycles where work flows quickly from code to production.

Introduction

Full episode notes and transcript: https://threedots.tech/episode/event-driven-architecture/

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.
• Avoid over-engineering – sometimes synchronous systems or simple monoliths are just better.
• Start with sync if unsure – it’s easier to migrate from a well-structured synchronous system to async later than the other way around.

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

Episode notes: https://threedots.tech/episode/history-of-watermill/

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

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.

We discuss the key decisions and strategies that helped make Watermill successful, from focusing on solving real problems to maintaining backward compatibility and building a community around the project.

• Watermill documentation — our open-source event-driven architecture library for Go
• Watermill repository
• Go Event-Driven training that complements Watermill
• Real World Examples