Architecture
Don't start with microservices. Start with boundaries.
August 6, 2026 · 6 min read
Many teams reach for microservices to get clean separation. What they usually want is boundaries — and those are available, much more cheaply, inside a single codebase.
Two different decisions
Boundaries decide which code is allowed to know about which data. Microservices decide how that code is deployed and how it communicates. Getting the first wrong in a monolith produces tangled code. Getting it wrong across services produces tangled code plus network failures, distributed transactions and a harder on-call rota.
A modular monolith first
In a Django or FastAPI codebase, that looks like apps or modules with explicit public interfaces, no reaching into another module's tables, and background work through a queue such as Celery even when everything runs in one repository.
The cost nobody puts in the diagram
Every extra service needs deployment, monitoring, secrets, versioned contracts and someone who understands it at 2 a.m. That is worth paying for the right reasons. It is a poor price for tidiness.
I build and lead teams around systems where reliability matters. If you're designing an offline workflow, evaluating an architecture, or untangling a queue that has become part of your product, I'm happy to compare notes.
More writing
- React Native Architecture Decisions That Become Expensive Later
React Native · 7 min read
- Why Good Engineers Care About Failure Modes
Distributed Systems · 5 min read
- What Engineering Managers Should Actually Measure
Engineering Management · 6 min read