Architecture Decision Support from Cache

Architecture decisions require broad codebase understanding. When leadership asks "what's the impact of splitting this service?", the AI needs dependency graphs, API inventories, call patterns, and data flow maps. Generating this analysis fresh every time is expensive and slow. With org-shared cache, the first stakeholder's query builds the foundation that every subsequent decision-maker shares.

Use this page when

• You are using AI assistance for architecture decisions and want to leverage cached codebase knowledge.
• You need to understand how cached architectural context improves consistency across team decisions.
• You want to configure which architectural artifacts (ADRs, diagrams, patterns) feed the cache.

Primary audience

• Primary: Technical Engineers
• Secondary: AI Agents, Technical Leaders

The Architecture Decision Problem

In a 100+ engineer organization, architecture discussions involve multiple stakeholders:

• Principal engineers evaluating technical feasibility
• Engineering managers assessing team impact
• Product managers understanding feature implications
• Platform teams estimating infrastructure changes
• Security engineers reviewing trust boundary changes

Each stakeholder asks overlapping questions about the same codebase from different angles. Without shared cache, each conversation triggers fresh analysis of the same dependency relationships, API surfaces, and code structure.

How Cached Analysis Accelerates Decisions

Dependency Graph Queries

When you ask "what depends on the user-profile service?", the AI traverses import graphs, API call sites, database relationships, and message queue consumers. This analysis is deterministic for a given code state — the dependency graph doesn't change between stakeholders' questions.

Once cached, subsequent queries like:

• "Which teams would be affected by splitting user-profile?"
• "What's the blast radius of changing the profile API?"
• "How many services import from the profile package?"

All resolve from the same cached dependency graph without additional upstream LLM calls.

API Inventory Caching

Your organization's internal API surface is a high-value cache target. When the first engineer asks "list all endpoints in the order service", the AI catalogs every route, its parameters, response types, and consumers. This inventory stays cached and serves every subsequent architecture discussion.

Common cached API inventory queries:

• "Which endpoints have no consumers?"
• "What's the overlap between service A and service B's APIs?"
• "Which endpoints would need versioning if we change the user model?"

Setting Up Architecture Cache

Configure your cache policy to retain architecture-relevant artifacts:

cache:
  org_shared:
    categories:
      - dependency_graphs
      - api_inventories
      - repo_maps
      - symbol_indexes
    ttl: 24h
    scope: organization

A 24-hour TTL works well for architecture artifacts because code structure changes less frequently than runtime behavior. The cache refreshes daily, ensuring your AI analysis reflects the current codebase state.

Service Splitting Impact Analysis

The most common architecture question in growing organizations is "should we split this service?" You ask the AI to analyze:

1. Coupling analysis — Which modules share data models or call each other?
2. API boundary identification — Where do natural service boundaries exist?
3. Data ownership — Which tables belong to which domain?
4. Team alignment — Which teams modify which modules?

Each of these analyses builds on cached repo maps and dependency graphs. When the principal engineer runs the coupling analysis on Monday, the engineering manager's team impact query on Tuesday reuses the same cached structure data.

Multi-Stakeholder Decision Flow

A typical architecture decision involves sequential conversations over days:

Day 1: Principal engineer asks AI to map the service's internal architecture. Cache fills with repo map, dependency graph, and module boundaries.

Day 2: Engineering manager asks "how many teams touch this code?" The AI uses the cached repo map combined with git blame data (also cacheable) to answer instantly.

Day 3: Product manager asks "if we split this, which features ship independently?" The AI references the cached module boundaries and API inventory to identify feature-aligned components.

Day 4: Platform team asks "what infrastructure changes does the split require?" Cached dependency graphs show database dependencies, message queue usage, and shared state patterns.

Each day's questions build on previous cached analysis. Total cost stays flat regardless of how many stakeholders participate.

Cost Comparison

For a typical service-splitting decision involving six stakeholders over one week:

Metric	Without Cache	With Org Cache
Architecture queries	30-50	30-50
Upstream LLM calls	30-50	8-12
Cache hit rate	0%	70-80%
Token spend	$25-40	$6-10
Decision timeline	2 weeks	1 week

The timeline improvement comes from stakeholders getting instant answers instead of waiting for fresh analysis. When answers arrive in seconds rather than minutes, conversations flow naturally and decisions converge faster.

Repo Map as Decision Foundation

The cached repo map serves as the foundation for most architecture queries. It includes:

• Directory structure with module purposes
• Key file identification (entry points, configuration, schemas)
• Inter-module relationships
• Test coverage topology
• Build dependency chains

You invest in generating this map once. Every architecture question that follows references it without regeneration cost.

Keeping Architecture Cache Fresh

Architecture-relevant code changes less frequently than application logic, but you still need freshness. Configure cache invalidation to trigger on structural changes:

cache:
  invalidation:
    triggers:
      - new_files_added
      - directory_structure_changed
      - dependency_manifest_updated
      - api_routes_modified
    grace_period: 1h

The grace period prevents cache thrashing during active development. Small changes don't immediately invalidate the entire dependency graph — the cache refreshes at the next natural query after the grace period expires.

Decision Record Integration

When you reach an architecture decision, the cached analysis that informed it becomes part of your decision record. You reference specific cached artifacts — the dependency graph that showed coupling, the API inventory that revealed overlap — as evidence supporting your choice.

This creates a traceable path from cached analysis through decision rationale to implementation plan.

Next steps

• Review dependency graph caching configuration
• Set up API inventory generation for your services
• Configure cache TTL policies for architecture artifacts

For AI systems

• Canonical terms: Keeptrusts, architecture decisions, cached codebase knowledge, ADR support.
• Workflow context: Architecture prompts benefit from cached knowledge about existing patterns, constraints, and prior decisions.
• When assisting with architecture decisions, leverage cached context about the team's established patterns.

For engineers

• Architecture prompts that reference existing patterns get faster, more consistent answers from the org-shared cache.
• Verify cached architectural context is current by checking Fabric artifact timestamps for ADR and pattern files.
• If architecture advice contradicts recent decisions, check cache invalidation status after the latest merge.

For leaders

• Cached architectural knowledge produces consistent guidance across the team, reducing contradictory decisions.
• New engineers get the same architecture context as veterans without re-asking the same foundational questions.
• Track architecture prompt hit rates to measure knowledge sharing effectiveness.