Observatory · Problem education
Architecture problems
What engineers search for before merge — with real graph evidence from open-source repository proofs. Only problems with proof density are indexed; others stay draft until the evidence bar is met.
Homepage → Problems → Repository proofs → Install → Watch
5 published · 5 draft
Most common architecture problems
Each page answers a distinct question — backed by repository proof, not keyword templates.
All problems
- Circular DependenciesPublished
A circular dependency is a closed loop in the module graph: A depends on B depends on C depends on A. Cycles remove a safe order for changes and testing.
Evidence: nx, payload
- High Fan-InPublished
Fan-in is how many modules depend on a given module. High fan-in means many parts of the codebase route through the same file, type bundle, or config hub.
Evidence: payload, nextjs, directus
- Hidden DependenciesPublished
Hidden dependencies are structural edges the team does not expect — transitive imports, indirect config coupling, or paths that do not appear in a local diff but show up in the full module graph.
Evidence: calcom
- Blast RadiusPublished
Blast radius is how many modules can be affected downstream when a given module changes — direct dependents plus transitive impact through the dependency graph.
Evidence: nextjs, nx
- Change ImpactPublished
Change impact analysis answers the question every reviewer asks: what breaks if I change this file? It traces modules, tests, and subsystems affected through the dependency graph — before the change lands on main.
Evidence: nextjs, payload, prisma, directus, nx
- Architectural DriftDraft
Architectural drift is gradual divergence between intended module boundaries and the actual dependency graph — layers that leak, duplicates that compete, or utilities that absorb domain logic.
Tier 2 problem — exemplar mapping pending.
- Dependency SprawlDraft
Dependency sprawl is uncontrolled growth in module count, edge count, and cross-package imports — where the graph is larger than the team’s shared mental model of the system.
Tier 2 problem — exemplar mapping pending.
- God ModulesDraft
God modules accumulate too many responsibilities — imports, exports, config, and domain logic in one file — becoming implicit platforms without explicit boundaries.
Tier 2 problem — exemplar mapping pending.
- Shared Kernel RiskDraft
Shared kernel risk appears when multiple teams or subsystems depend on the same core module — a shared kernel — without a stable contract or versioning strategy.
Tier 2 problem — exemplar mapping pending.
- Tight CouplingDraft
Tight coupling is when modules depend directly on concrete implementations instead of abstractions — or when many subsystems share mutable state through a small set of hubs.
Tier 2 problem — exemplar mapping pending.
Change impact →Circular dependencies →Repository proofs →arc impact →