// Topics / Patterns
Patterns
Definition
Patterns coverage in this archive spans 9 posts from Sep 2018 to Jul 2026 and deals with structural tradeoffs: coupling, failure boundaries, and long-term change cost. The strongest adjacent threads are architecture, ai, and go. Recurring title motifs include patterns, agent, go, and event.
Key claims
- Most pieces recommend choosing the simplest architecture that can be operated confidently.
- Early posts lean on event and patterns, while newer posts lean on patterns and agent as constraints shifted.
- This topic repeatedly intersects with architecture, ai, and go, so design choices here rarely stand alone.
Practical checklist
- Define failure domains and data boundaries before introducing additional services or protocols.
- Start with the newest post to calibrate current constraints, then backtrack to older entries for first principles.
- When boundary questions appear, cross-read architecture and ai before committing implementation details.
Failure modes
- Breaking systems into many parts without clear ownership of cross-service behavior.
- Choosing architecture for trend alignment rather than workload constraints.
- Applying guidance from 2018 to 2026 without revisiting assumptions as context changed.
Suggested reading path
- Start here (current state): AI Engineering Is Its Own Discipline Now
- Then read (operating middle): Structured Output from LLMs: A Go Implementation Guide
- Finish with (foundational context): Serverless: What Works, What Doesn’t, and What Will Bite You
Related posts
- AI Engineering Is Its Own Discipline Now
- AI-Native Architecture Patterns 2026
- Agent Orchestration: Four Patterns, Honest Tradeoffs
- Agent Patterns That Survive Production
- Structured Output from LLMs: A Go Implementation Guide
- Go Concurrency Patterns I Use in Every Service
- Distributed Systems Patterns I Keep Reaching For
- Event Sourcing in Practice: What I Learned Building Financial Event Pipelines
References
8 entries tagged “Patterns”