Designing Retry vs Skip Policy in Production

The retry-vs-skip choice is driven by exception class semantics, not by a single tunable.

Map exceptions to actions:

• Transient infrastructure (deadlock, 503, timeout) → retry with exponential backoff
• Permanent data defects (parse, validation, business rule violation) → skip with SkipListener
• Fatal logic errors (NullPointerException, OutOfMemoryError) → fail fast

Custom RetryPolicy when you need nuance:

• ExceptionClassifierRetryPolicy for per-class retry limits
• Custom canRetry() for circuit-breaker behavior — bail out after N total failures across the step
• RetryPolicy decides whether to retry; BackOffPolicy decides how long to wait — they compose

Custom SkipPolicy when absolute counts aren't enough:

• PercentageSkipPolicy — fail fast if more than 5% of items skip after a warmup window
• Tiered policy — allow 1000 parse errors but only 10 integrity violations
• Stateful policies need AtomicLong for multi-threaded steps

Always pair skip with a SkipListener:

• Write skipped items to a Kafka topic, file, or audit table
• Without this you've created a silent data-loss vector

Anti-patterns to avoid:

• skip(Exception.class) — masks real bugs
• Retry without backoff — retry storms compound the original failure
• Retrying on non-idempotent processors — duplicate side effects
• The same policy for transient and permanent errors

The ambiguous case:

• DataIntegrityViolationException — UNIQUE constraint may be a permanent duplicate (skip) or a transient race (retry)
• Inspect the cause or message and route accordingly

In an interview I'd emphasize that the retry-vs-skip choice starts with exception classification, and that production-grade policies often need custom implementations to capture business risk tolerance.