Concept questionMedium~7 minResilience & Dependency Failures Essentials / 16 of 16

Interview question

Why use IHttpClientFactory, and what problems can still occur with handler lifetime, DNS changes, and outbound concurrency?

IHttpClientFactory, handler lifetime, DNS, and socket reuse

Explains how IHttpClientFactory separates short-lived clients from pooled handlers and how concurrency, DNS, resilience, and DI lifetimes still require judgment.

1Say itAnswer out loud first

2CompareCompare with Core answer

3RefineRefine with Stronger and Advanced

TL;DR

IHttpClientFactory centralizes outbound client configuration and pools underlying message handlers, so creating a factory client for an operation does not create a fresh TCP connection each time. Reusing handlers avoids socket exhaustion, while handler rotation lets new clients eventually observe DNS changes. Named or typed clients also keep base addresses, headers, logging, and resilience policies in one place. The factory does not make unlimited parallel requests safe or decide the correct timeout and retry policy for the dependency.

Full answer below

Practice focus

IHttpClientFactory, HttpClient, SocketsHttpHandler, connection pooling, DNS refresh, handler lifetime, typed clients, resilience, and concurrency limits.

Answer first

Answer path

Core answer first, then checkpoints toward a stronger answer.

Start
Core answer
Start here. This is the direct spoken answer to practice first.
Why this question matters
HttpClient lifetime advice sounds contradictory until the client object is separated from the underlying handler and connection pool. That distinction determines whether an API reuses sockets, observes DNS changes, and survives downstream load.
IHttpClientFactory centralizes outbound client configuration and pools underlying message handlers, so creating a factory client for an operation does not create a fresh TCP connection each time. Reusing handlers avoids socket exhaustion, while handler rotation lets new clients eventually observe DNS changes. Named or typed clients also keep base addresses, headers, logging, and resilience policies in one place. The factory does not make unlimited parallel requests safe or decide the correct timeout and retry policy for the dependency.
Checkpoint
Stronger answer
Optional upgrade with examples, trade-offs, and sharper phrasing.
I request the factory client when the operation needs it and avoid capturing a typed client inside a singleton longer than its handler lifetime. For very long-lived clients, a deliberately configured SocketsHttpHandler.PooledConnectionLifetime can recycle connections for DNS changes instead. I set an overall deadline, propagate cancellation, bound MaxConnectionsPerServer or upstream concurrency where needed, and retry only transient, replay-safe operations. Per-request headers and tokens stay on the request message rather than mutating shared default headers.
Finish
Advanced answer
Optional deeper angle for production judgment and nuance.
In production I model the downstream as a constrained dependency. Handler rotation should not synchronize connection churn across a fleet, and nested retries in gateway, API, and SDK layers must fit one budget. I distinguish DNS staleness, connection-establishment failure, pool queuing, remote latency, and caller cancellation in telemetry. High HTTP/1.1 concurrency can still open many connections when no idle connection is available, so the factory alone does not prevent socket pressure. I configure connection limits, HTTP/2 where supported, timeouts, circuit breaking, and load shedding from measured capacity. Typed clients remain transient dependencies; a singleton that captures one can pin its handler and miss DNS changes. Tests use a controllable handler for request behavior and an integration environment for DNS, timeout, and connection-reuse assumptions. During incidents I inspect dependency duration, active requests, connection counters, retry volume, and name-resolution changes before increasing limits.

Review signals

Use these to catch weak phrasing, shallow reasoning, and risky claims.

Common mistakesCandidateCommon mistakesMistakes that weaken the answer or signal shallow understanding.Open details

Details

Creating and disposing a raw handler for every request.
Capturing a typed client in a singleton indefinitely.
Assuming the factory limits outbound concurrency automatically.
Adding retries to non-idempotent writes without an operation design.

Red flagsCandidateSigns the approach is fragileSignals that an interviewer may treat as risky.Open details

Details

Every dependency call starts a fresh connection under normal traffic.
An old client remains pinned while the service endpoint changes address.
Retry attempts multiply across several infrastructure layers.
Per-user authorization headers are placed in mutable shared defaults.

Follow-up prompts

Quick interviewer prompts inside this drill.

Follow-up questionsCandidateFollow-up questionsLikely next questions after the main answer.Open details

Details

Treat these as the next interviewer turn. Answer one out loud, then save the gap in your practice notes.

Why are factory-created HttpClient instances safe to dispose?
How can a typed client miss DNS changes?
What would you monitor during outbound socket pressure?

Continue practice

Move to the linked follow-up, next path step, prerequisite, or deeper variant.