Everyone talks about the technical challenges of microservices: network latency, distributed transactions, service discovery. Nobody talks about the knowledge challenge.
When you split a monolith into 30 services, you don't just distribute the code. You distribute the understanding. And unlike code, understanding doesn't scale horizontally.
The Knowledge Distribution Problem
In a monolith, any engineer can grep for a function and trace its behavior. In microservices, understanding a single user flow might require reading code in 5 different repositories owned by 3 different teams.
The result: knowledge silos form along service boundaries. The payments team understands payments. The onboarding team understands onboarding. Nobody understands the full picture.
This is Conway's Law applied to knowledge, not just architecture.
What It Actually Costs
Incident response. An incident in the checkout flow touches the cart service, payment service, and notification service. Three teams get paged. Each team understands their slice but not the interaction between slices. Debugging takes 3x longer because the problem is in the integration, not any single service.
Architecture decisions. When nobody holds a complete mental model, every cross-service change requires a committee. "How does this affect the event bus?" becomes a multi-day question because the answer spans three teams.
Onboarding. New engineers join a team and learn one service deeply. But to be effective, they need to understand the services their service depends on. That understanding lives in other teams' heads.
How to Detect Knowledge Silos
Look at your git history across all repos:
# Who commits to which repos?
for repo in service-a service-b service-c; do
echo "=== $repo ==="
cd $repo
git log --since="90 days" --format='%aN' | sort | uniq -c | sort -rn | head -5
cd ..
done
If each repo has a completely different set of contributors, you have siloed knowledge.
More sophisticated approaches use codebase intelligence to map knowledge distribution across your entire org — showing not just who commits where, but who can actually understand and debug each service.
5 Fixes That Actually Work
1. Cross-Service Code Reviews
Require at least one reviewer from a different team for PRs that change API contracts or event schemas. This forces knowledge transfer at the integration points where silos cause the most damage.
2. Rotation Programs
Engineers spend one sprint per quarter embedded in a different team. Not just reading their code — actually shipping features. This builds empathy and understanding that no documentation can replace.
3. Architecture Decision Records (ADRs)
When you make a cross-service decision, document it in a shared location (not in any single repo). Include: the decision, the alternatives considered, and the constraints that drove the choice.
4. Shared On-Call for Integration Flows
For critical user flows that span multiple services, create a shared on-call rotation with members from each team. During incidents, they debug together. The shared context compounds over time.
5. Living Dependency Maps
Maintain an always-up-to-date map of which services depend on which. Not a stale Confluence diagram — a living dependency map derived from actual code and API calls.
The Microservices Tax
Microservices have a knowledge tax that monoliths don't. Every service boundary is a potential knowledge silo. Every API contract is a potential misunderstanding waiting to happen.
This doesn't mean microservices are wrong. It means you need to budget for knowledge distribution the same way you budget for infrastructure. If you're not spending 10-15% of engineering time on cross-team knowledge sharing, your silos are growing quietly.
The bus factor for individual services might be fine. But what's the bus factor for understanding how they all fit together? For most teams, that number is dangerously low.
Glue maps knowledge silos across your entire microservices architecture — showing which services have the highest concentration risk and where cross-training is needed most.
Top comments (0)