Katkat
Back

Design an extensible request Retryer

AirbnbSoftware Engineer · Technical Screen
MediumSoftware EngineerTechnical ScreenSoftware Engineering Fundamentals

Last updated

This question evaluates a candidate's ability to design extensible and robust retry mechanisms, covering competencies in API/interface design, fault tolerance, backoff and jitter strategies, cancellation/deadline handling, idempotency considerations, and observability.

Problem

You are building a small library component called a Retryer that wraps an operation (typically a network call) and retries it on failure.

Requirements

  1. Default behavior
  • Provide a “default retryer” implementation that retries an operation when it fails.
  • The default should support common retry features:
  • Maximum attempts (or max retries)
  • Delay/backoff strategy (e.g., fixed, exponential)
  • Optional jitter
  • Stop conditions (e.g., do not retry on certain exception types / status codes)
  • Ability to honor a caller-provided cancellation/deadline (e.g., timeout)
  1. Extensibility
  • The design must be extensible so that callers can plug in custom behavior without modifying the retryer’s core logic. Examples:
  • Custom backoff policy
  • Custom “should retry?” policy
  • Hooks/observers for logging/metrics
  • Handling server-provided retry hints (e.g., a Retry-After value)
  1. Usability
  • The API should be easy to use for common cases, while still allowing advanced customization.

What to deliver

  • Propose the public API (interfaces/classes) for the Retryer.
  • Explain how the default retryer works.
  • Explain how customizations are added (e.g., strategies, composition, configuration objects).
  • Call out key edge cases and pitfalls (e.g., thundering herd, non-idempotent operations, deadlines).