In large systems, problems often don't stem from bad code—they stem from bad boundaries.
I started thinking deeply about how services are sliced: who owns data, how cross-service communication is managed, and what defines a unit of deployment. These aren’t just technical decisions—they’re architectural contracts.
Some takeaways from my experience:
- If two services talk too frequently, maybe they shouldn't be separate.
- If every change needs 5 teams to coordinate, you're over-coupled.
- Good boundaries align with business capabilities, not just technical layers.
This thinking later led me to adopt domain-driven design (DDD) as a lens for structuring scalable systems. Not everything needs to be DDD-heavy, but the principles help ground architectural decisions in real-world context.