The situation
What needs investigation
A container service receives more traffic and starts to show latency, errors, or uneven target health. Larger tasks or more replicas may help, but they can also hide a slow dependency, a worker-concurrency limit, a weak scaling metric, or a load-balancer configuration issue.
Signals we look for
Application
- request latency by route
- error rate and timeouts
- worker / concurrency limits
- per-request processing time
Containers
- CPU and memory pattern
- task requests and limits
- startup time and image size
- restart / OOM events
Traffic path
- load-balancer target health
- connection and queue pressure
- traffic distribution
- health-check behaviour
Dependencies
- database latency
- cache hit rate
- connection pool limits
- downstream errors
How we investigate
Each step is validated against the workload before the next change.
- 01
Inventory
Map the request path, runtime configuration, container limits, load balancer, and dependent services.
- 02
Baseline utilisation
Compare latency, errors, CPU, memory, and dependency behaviour across normal and peak traffic.
- 03
Identify the constraint
Separate application saturation from database, cache, connection, or load-balancer bottlenecks.
- 04
Model changes
Test task sizing, worker settings, replica count, and scaling signals against representative load.
- 05
Implement safely
Apply the smallest change with health checks, monitoring, and a known rollback action.
- 06
Measure
Check the same latency, error, saturation, and cost signals after the change.
Architecture / decision path
Example engineering decision
Illustrative workload signal — not customer data
Task allocation8 vCPU / 16 GB memory
Observed CPUaround 75–80%
Observed memorybelow 25%
Engineering interpretation
Low memory use does not by itself mean the task is oversized. A CPU-bound workload may become slower or throttle if the whole task size is reduced.
Possible next investigation
- Review CPU profiles and worker concurrency.
- Check per-request processing time and queue depth.
- Test horizontal scaling response under load.
- Compare an alternative compute size before changing production capacity.
Trade-offs we consider
Response time
A faster scale-out action may still be too late for sudden traffic.
Capacity cost
Warm capacity reduces delay but costs more when traffic is quiet.
Application limits
More replicas do not fix serialized work or a saturated dependency.
Scaling delay
Image pull, startup, and health checks affect when new capacity is useful.
What the engagement can produce
Typical outputs for this type of work
Scope depends on the environment and the problem being investigated.
- runtime and dependency inventory
- utilisation and latency baseline
- scaling-signal recommendation
- task or container sizing plan
- monitoring and alert changes
- safe rollout and rollback plan