The situation
What needs investigation
An application is slow, errors increase at peak traffic, or compute usage looks high. Adding larger instances can mask the issue without addressing a slow query, exhausted connection pool, blocking worker, storage latency, or cache miss pattern.
Signals we look for
Request path
- latency by endpoint
- status codes
- queue and concurrency
Compute
- CPU saturation
- memory pressure
- runtime garbage collection
Data
- query timing
- connection pools
- storage I/O latency
Caching & traffic
- cache hit rate
- load-balancer timing
- traffic spikes
How we investigate
Each step is validated against the workload before the next change.
- 01
Capture a baseline
Record representative latency, errors, saturation, and traffic.
- 02
Trace the request
Identify time spent in application work, queues, database, cache, and external calls.
- 03
Check resource pressure
Compare CPU, memory, disk, network, and connection limits.
- 04
Test one constraint
Use a controlled load test or safe experiment to validate the suspected bottleneck.
- 05
Change narrowly
Adjust the constrained component before increasing unrelated compute.
- 06
Measure again
Compare the original request, dependency, and saturation signals.
Architecture / decision path
Example engineering decision
Illustrative latency finding — not customer data
API latencyincreases during traffic peak
CPUbelow 45%
Database waitsincrease with request volume
Engineering interpretation
Low application CPU does not rule out an infrastructure bottleneck. The data layer or connection pool may be limiting throughput before the application process becomes busy.
Possible next investigation
- Inspect slow queries and wait events.
- Check connection-pool size and exhaustion.
- Measure cache hit rate for affected routes.
- Test a query or indexing change before resizing compute.
Trade-offs we consider
Compute
More CPU helps only if application work is the constraint.
Caching
Caching can reduce load but introduces invalidation and consistency concerns.
Database tuning
Indexes and query changes need validation against write overhead.
Load testing
Representative tests are useful only when they resemble production behaviour.
What the engagement can produce
Typical outputs for this type of work
Scope depends on the environment and the problem being investigated.
- performance baseline
- request-path findings
- dependency and saturation analysis
- prioritized experiment plan
- monitoring additions
- safe change and validation plan