Microservices With a Tiny Team
4-person team. 12 microservices. Each developer owns 3 services. The bus factor for each service is 1.
The reality:
- Developer A owns Auth, User, Notification
- Developer B owns Order, Payment, Shipping
- Developer C owns Catalog, Search, Inventory
- Developer D owns Analytics, Reports, Admin
What happens on vacation:
- Dev A goes to vacation → Auth bug → nobody knows the code
- Everyone context-switches constantly
- "Can you look at my service?" becomes daily
- Knowledge silos everywhere
The burnout cycle:
- On-call for 12 services = always on-call
- Feature work fragmented across services
- Deploy 4 services for 1 feature
- Cognitive load is unsustainable
The right size:
- Rule of thumb: 2+ people per service
- 4 people → 2 services max
- Start monolith, extract when team grows
Lesson: Microservices are an organizational scaling strategy. If your team fits in a meeting room, you probably don't need them.