Performance Antipatterns

Most production slowness is one of a small number of recognisable shapes. Knowing their names is useful because it turns "the page is slow" into a specific hypothesis you can test.

Chatty I/O — many small round trips where a few larger ones would do. Latency, not bandwidth, is the cost: 200 calls at 5ms each is a second of waiting no matter how small the payloads are. The database version is the N+1 query: fetch a list, then issue one query per row. Fix by batching, joining, or eager-loading.

Extraneous fetching — pulling far more data than the operation needs. SELECT * to read one column, or fetching a full object graph to display a name. It wastes network, memory, and cache space, and it hides behind "the query is indexed".

Busy database — pushing work into the database that the application should do, so the hardest component to scale horizontally becomes the bottleneck.

Busy frontend — the opposite: heavy work on the request thread that should be queued, so the thing users wait on is doing something they never asked to wait for.

Synchronous I/O — blocking a thread on a call that could be awaited. Throughput collapses under load because threads sit idle holding memory rather than serving other requests.

Noisy neighbour — one tenant or workload consuming shared capacity and degrading everyone else. The defence is isolation: quotas, separate pools, rate limits per tenant.

Retry storm — every client retrying a failing dependency at once, turning a blip into a sustained outage. The defence is exponential backoff with jitter, a retry budget, and a circuit breaker.

Improper instantiation — creating an expensive client, connection, or parser per request instead of reusing one. It looks like a memory problem and is really a lifetime problem.