Architecture and performance

Design-to-delivery integration

For complex architectural design, consider design-to-delivery: a dependency/flow diagram, brainstorming, linked spec and tasks can reveal boundary mistakes and contract inconsistencies. Adapt or simplify the sequence using engineering judgment, and use this skill's boundary/tradeoff criteria in the selected artifacts. Preserve existing architecture decisions and evidence. Focused architecture or optimization work need not create a full package; explicit artifact requests remain deliverables.

Purpose

Choose a maintainable boundary or a measured optimization without unnecessary rewrites.

When to use

Architecture mode for structural decisions; performance mode for performance requests or an evidenced bottleneck. A routine edit does not trigger a full redesign or benchmark campaign.

Preconditions

Read project layering, dependencies, shared types, analogous modules and affected tests. Know the authorized scope. Performance mode needs a representative safe workload and a baseline metric.

Workflow

1. Architecture mode: map the current dependency direction and requested change. Reuse existing feature modules and abstractions. Put transport, business decisions and persistence at their established boundaries; keep validation contracts shared where already supported.
2. Create an abstraction only for actual reuse, an independently testable boundary or a concrete integration seam. Explain tradeoffs before introducing a new layer/dependency; do not transplant one project's architecture into all projects.
3. Performance mode: define the metric (latency, query count, render work, memory, bundle size), workload and baseline. Profile or inspect query plans/traces locally; distinguish measured facts from hypotheses.
4. Fix the dominant cost with the smallest change: repeated requests, N+1 queries, unbounded work, unnecessary renders or a poor algorithm. Caching needs ownership-aware keys, invalidation, bounded lifetime and memory; concurrency needs limits and cancellation.
5. Preserve outputs, ordering, consistency and failure behavior. Run contract/regression tests and compare the same workload before/after. Account for warmup and variability; report data rather than unsupported percentages.

Rules

No speculative memoization, caching, indexing or framework migration. If measurement is unavailable, offer an evidenced opportunity and report impact as unverified. Do not run load tests against live services without explicit authorization.

Common mistakes

Moving business rules into UI/controllers; a new layer for one call; optimizing cold synthetic work unrelated to users; stale/unsafe caches; claiming a speedup from code inspection.

Validation

Architecture: dependencies respect project layers, changed callers and contracts are checked. Performance: same workload/metric, real before/after values and unchanged behavior; report limits when measurements cannot be obtained.