Retryer Implementation

Airbnb's "Retryer Implementation" interview question focuses on designing a robust retry mechanism for handling transient failures in distributed systems. It emphasizes object-oriented principles, design patterns like Strategy and Decorator, and sophisticated error classification.

Problem Statement

Design and implement a configurable Retryer class that executes a given task (e.g., an API call or database operation) with automatic retries on failure. The retryer must:

• Support exponential backoff with jitter to avoid thundering herd problems
• Classify errors as retryable (e.g., timeouts, 5xx server errors) vs non-retryable (e.g., 4xx client errors, validation failures)
• Allow pluggable retry policies (fixed count, exponential, linear)
• Provide circuit breaker functionality to prevent cascading failures
• Expose metrics for monitoring (success rate, retry counts, latency percentiles)
• Handle idempotency concerns for operations that might be retried

The implementation should be thread-safe and extensible for different execution contexts (HTTP, gRPC, database).[1][3]

Core Requirements

class Retryer { execute(Task task) -> Result withMaxRetries(int count) withBackoff(BackoffStrategy strategy) withErrorClassifier(ErrorClassifier classifier) withCircuitBreaker(CircuitBreaker cb) withTimeout(Duration timeout) }

Input/Output Examples

Example 1: Basic Exponential Retry

`java Retryer retryer = new Retryer() .withMaxRetries(3) .withBackoff(new ExponentialBackoff(100ms, 2.0, 0.1)) // base=100ms, factor=2x, jitter=10% .withErrorClassifier(new HttpStatusClassifier());

Result result = retryer.execute(() -> externalApi.call(userId)); ` Expected behavior:

• Attempt 1: immediate (fails with 503)
• Attempt 2: wait ~100ms ± jitter (fails with timeout)
• Attempt 3: wait ~250ms ± jitter (succeeds)
• Returns success result with retryCount=2, totalDelay=~350ms

Example 2: Circuit Breaker Trips

`java Retryer retryer = new Retryer() .withCircuitBreaker(new CircuitBreaker(5, 30s)); // 5 failures → OPEN for 30s

// First 5 calls fail rapidly → circuit OPEN Result r1 = retryer.execute(slowService::call); // immediate failure: "Circuit open"

// After 30s half-open, then success → circuit CLOSED Result r2 = retryer.execute(slowService::call); // succeeds **Metrics emitted**: retryer.circuit.state: OPEN → HALF_OPEN → CLOSED retryer.failure_rate: 100% → 20% retryer.total_retries: 12 `

Example 3: Non-Retryable Error (Early Exit)

java retryer.execute(() -> { throw new ValidationException("Invalid userId format"); // 400-equivalent }); // Immediately fails without retries, logs "Non-retryable error"

Constraints & Edge Cases

• Max retries: 0-10 attempts (0 = no retries, fire-and-forget)
• Timeout: Total execution ≤ 30 seconds across all attempts
• Backoff bounds: Minimum 50ms, maximum 5 seconds per attempt
• Error classification: | Category | Examples | Retry? | |----------|----------|--------| | Retryable | 5xx, ConnectTimeout, SocketTimeout | ✅ Yes | | Non-retryable | 4xx, ValidationError, AuthFailure | ❌ No | | Ambiguous | Unknown exceptions | Configurable |
• Concurrency: Thread-safe for 1000+ concurrent executions
• Metrics: Must emit structured metrics (Prometheus format) for:
  • retryer_attempts_total{outcome="success|failure|timeout"}
  • retryer_duration_seconds{quantile="0.5|0.9|0.99"}
  • retryer_circuit_state
• Idempotency: Operations must be idempotent or use client-provided idempotency keys

Design Patterns Required

• Strategy: Pluggable BackoffStrategy, ErrorClassifier
• Decorator: Wrap existing Task with retry logic
• Circuit Breaker: State machine (CLOSED → OPEN → HALF_OPEN)
• Builder: Fluent configuration API
• Observer: Metrics emission on state transitions

Production Considerations

` Real Airbnb constraints from their payments system:

• 99.99% uptime requirement
• P99 latency < 2 seconds
• Handle 10K QPS spikes during peak booking
• Zero double-charging (idempotency critical)
• Graceful degradation during outages `

This matches Airbnb's real-world needs for payments, booking, and search services where transient failures are common but double-charging or infinite retries are catastrophic.[3][4]