Questions 126-150: Resilience, Rate Limiting, Health Checks & Observability.
Open a question for the full answer, code and interview guidance.
The Retry pattern repeats an operation after a transient failure when there is a reasonable chance that a later attempt will succeed. Examples include temporary network errors, throttling, or a briefly unavailable dependency.
Exponential backoff increases the delay between retry attempts, reducing pressure on an unhealthy dependency. A simple sequence might wait 1 second, then 2, then 4, subject to a maximum.
Jitter adds randomness to retry delays so large numbers of clients do not retry simultaneously after a shared failure.
The Circuit Breaker pattern temporarily stops calls to a dependency after failures exceed a configured threshold. Instead of repeatedly waiting for a known-unhealthy service, calls fail quickly or use an appropriate fallback.
The Timeout pattern limits how long an operation is allowed to wait. Distributed calls should not wait indefinitely because a slow dependency can consume threads, connections, memory, and the caller's latency budget.
The Bulkhead pattern isolates resources so failure or overload in one workload does not consume all capacity needed by others. The name comes from compartments in a ship that limit the spread of flooding.
Fallback provides an alternative response or behavior when the preferred dependency or operation is unavailable. Examples include cached data, a reduced feature set, or a safe default.
Retry handles short transient failures by making a small number of additional attempts. Circuit Breaker handles sustained failures by stopping calls for a period.
A resilience pipeline composes policies such as timeout, retry, circuit breaker, rate limiting, and fallback around outbound or internal operations.
Retries multiply traffic. If a dependency is already overloaded, immediate or excessive retries add more requests precisely when it has the least spare capacity.
Rate limiting controls how many requests or operations are accepted during a period or under a concurrency limit. It protects services from overload, abusive clients, accidental loops, and expensive traffic spikes.
Token Bucket maintains a bucket containing tokens that are replenished at a configured rate. Each accepted request consumes a token.
Fixed Window divides time into intervals and allows a configured number of requests in each interval. It is simple to understand and implement.
Sliding Window approximates or tracks request usage over a moving time range rather than resetting all capacity at a fixed boundary.
Concurrency limiting restricts the number of operations executing at the same time rather than the number started during a time window.
Load shedding intentionally rejects or drops work when a system is overloaded so it can preserve capacity for requests it can successfully serve.
Admission control decides whether new work should enter a system based on current capacity, quotas, resource state, or policy.
Health checking exposes or evaluates whether an application instance and its dependencies are in a condition suitable for a particular purpose.
A liveness check asks whether the process is alive enough that restarting it could help. A readiness check asks whether the instance is currently able to receive traffic.
ASP.NET Core provides health-check services and middleware. Applications can register checks for relevant components and expose endpoints used by infrastructure.
Observability is the ability to understand a system's internal state and behavior from the signals it produces. In distributed systems, this is essential for diagnosing failures that cross process and service boundaries.
Structured logging records events as named fields rather than only as preformatted text. This makes logs easier to query, aggregate, correlate, and analyze.
Metrics are numeric measurements aggregated over time. They are efficient for dashboards, alerts, capacity analysis, and identifying changes in system behavior.
Distributed tracing follows a request or workflow across multiple services and dependencies. Each operation is represented by a span, and related spans share a trace context.
OpenTelemetry is an open standard and ecosystem for generating, collecting, and exporting telemetry such as traces, metrics, and logs. It provides vendor-neutral instrumentation concepts and protocols.