architecture-and-performancelisted

# Architecture and Performance The unit is the operation from arrival to its promised completion, including work deferred to other services when that completion requires it. Attribute cost to concrete choices: how much data is fetched, how often a boundary is crossed, which calls must wait for others, and how long scarce resources remain occupied. A faster mapper cannot remove database waits; fewer queries cannot remove measured serialization CPU. ## Workflow 1. **Define the operation and workload.** Obtain the latency/throughput objective, measurement boundary, request mix and rate, page/payload sizes, data distribution, concurrency and cache state. Identify the relevant code, SQL/call graph and deployment/framework versions. Without measurements, produce a conditional cost model and ask for the smallest evidence needed to distinguish options; do not announce a bottleneck or predict an empirical speedup. 2. **Map work and waits.** Record query/remote-call counts as functions of input size, rows and bytes returned, serial versus parallel dependencies, retries, queue waits and resource hold intervals. Compare expected work with observed work. Read [request-path-budget.md](references/request-path-budget.md) when attributing a slow path, estimating occupancy or checking whether measurements support a proposal. 3. **Locate the multiplier or limiting resource.** Correlate representative normal and slow requests with SQL, pool, downstream and CPU evide