# A hot record can limit the whole workflow

More application instances do not remove contention on one shared resource. Measure where work serialises before adding capacity.

By Cobnex editorial. Published 2026-09-10. Updated 2026-09-11.

## Find the shared point

A system may spread requests across many servers while every request updates one daily counter or account balance. That record becomes a coordination point regardless of the number of application instances.

Measure waiting and retry behaviour by operation class and resource pattern. Overall CPU utilisation can remain low while requests spend most of their time waiting for access to the same state.

Use controlled diagnostic sampling to locate hot resources without exposing customer data or creating unbounded metric labels.

## Understand the serial work

If each operation must hold exclusive access to the same resource for a measured 20 milliseconds, that protected section permits roughly 50 sequential operations per second before other overhead. This is an illustrative upper bound for that simple model, not a database benchmark.

Shortening the protected section may help more than adding servers. Move unrelated calculations and external calls outside it when doing so preserves correctness.

Do not move the decision itself outside the boundary merely to reduce measured lock time. A faster invalid result is not additional useful capacity.

## Consider changing the data model

Some counters can be partitioned and combined later when an approximate or delayed total is acceptable. Other rules, such as a hard shared capacity limit, require stronger coordination.

Explain the semantic change before adopting partitioning. Splitting one balance across workers can complicate the exact question the application must answer.

For high-contention workflows, a queue or explicit reservation model may make waiting more predictable. It also changes latency and recovery behaviour, so compare it with the current requirement rather than presenting it as a universal optimisation.

## Budget for retries and fairness

Measure attempts per completed operation. Aggressive retries can consume capacity without increasing successful throughput, especially when many callers retry together.

Use bounded retries and appropriate delay. Decide how the product handles callers that repeatedly lose contention so one customer or job is not starved indefinitely.

Load-test the real skew in demand. Uniformly random keys can make a design look scalable while hiding the one popular resource that causes production delays. Capacity planning should describe completed business operations under that skew, including their waiting time and failure outcomes.

## Sources

- [PostgreSQL: explicit locking](https://www.postgresql.org/docs/17/explicit-locking.html)