AMA #1: Go and AI, Clean Architecture, Learning, Event-Driven
Episode notes: https://threedots.tech/episode/ama-1/Quick takeawaysGo 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 PythonArchitecture 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 shouldCareer transitions: Switching roles within tech is easier internally. Moving from sysadmin to developer works better within the same company where people already trust youGo 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 layersDistributed systems: Async communication often solves sync timeout issues. When dealing with chains of service calls, consider using messages instead of increasing timeoutsIn 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!
--------
1:22:01
--------
1:22:01
How to Create PRs That Get Merged The Same Day
Full episode notes: https://threedots.tech/episode/prs-that-get-merged-the-same-day/Quick takeawaysPrioritize reviews over new work - treat PRs as work that’s almost done and needs to be pushed to production quicklyBig PRs create a dead loop - when reviews take ages, developers make even bigger PRs to avoid multiple long waitsKnowledge sharing is the hidden benefit - code reviews aren’t just gatekeeping, they spread understanding of how things work across the teamOne-day cycle time is possible - start work in the morning and merge by end of day with proper team culture and practicesSplit work vertically and horizontally - break features into small slices and layers that multiple people can implement in parallelIn 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
--------
1:27:44
--------
1:27:44
Event Driven Architecture: The Hard Parts
Full episode notes and transcript: https://threedots.tech/episode/event-driven-architecture/Quick takeawaysEvent-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.
--------
1:25:10
--------
1:25:10
Synchronous vs Asynchronous Architecture
Full episode notes: https://threedots.tech/episode/sync-vs-async/Quick takeawaysStart with synchronous architecture by default - it’s simpler to understand, debug, and maintain for most use casesAsync architecture improves scalability and resilience - message queues and events help handle traffic spikes and failuresDesign matters more than the technology choice - tight coupling creates the same problems in both sync and async approachesConsider team experience - async architecture require more experienced teams and better tooling to handle new challengesAdjust as your system grows - external APIs, heavy operations, or the need to handle failures gracefully are good use casesHybrid approach - use both sync and async where they fit best, rather than forcing one over the otherIn 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 trainingWatermill - our open-source Go library for working with message streamsEvent Storming - a design technique with a great unfinished ebook by Alberto BrandoliniCQRS (Command Query Responsibility Segregation) - a pattern that works well with both sync and async approachesOur CQRS article and Server-Sent Events postMessage brokers mentioned: RabbitMQ, Kafka, NATS, Google Cloud Pub/SubEvent schemas: Protobuf, Avro, CloudEventsEvent Sourcing - a pattern mentioned in context of recreating state from eventsClean Architecture/Hexagonal Architecture - architectural patterns mentioned for making sync/async migration easierIntroductionShow Notes
--------
1:27:11
--------
1:27:11
Watermill: from a hobby project to 8k stars on GitHub
Episode notes: http://threedots.tech/episode/history-of-watermill/Quick takeawaysSolve real problems first - successful open source projects start by addressing actual needs, not by looking for problems to fit a solutionKeep breaking changes minimal - Watermill stayed on v1 for 6 years with no breaking changes in the core library, building trust with usersExamples and documentation are crucial - provide real-world examples with automated tests, not just simple “hello world” demosPromotion matters - creating a great library isn’t enough; you need to actively share it through conferences, blog posts, and communitiesBe patient with growth - Watermill took 7 years to reach 8,000 stars; overnight success in open source is rareIn 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 GoWatermill repositoryGo Event-Driven training that complements WatermillReal World Examples
Based on nearly 20 years of working together on various projects, we discuss when it makes sense to move fast rather than aim for perfect code, and how to avoid technical debt that can kill your project.
We focus on making mindful engineering decisions instead of blindly following rules like “always do X” or “never do Y”. Different situations need different approaches to code quality.
Österreich