A retry is useful when failure is temporary, such as a brief connection outage or a service throttling traffic. Repeating an invalid request does not make it valid. Without error classification and idempotency, retries can increase load, extend queue delays, or create duplicate data.
A retry only buys another opportunity
A transient failure can recover without changing the payload: a network timeout, temporarily unavailable database, HTTP 429, or HTTP 503. Retrying gives the dependency time to become ready. A missing required field, wrong type, violated constraint, permanently invalid token, or missing table requires a data or configuration change.
Repeating permanent errors creates work without progress. It consumes worker and destination capacity, delays other messages, and fills logs with the same failure. A system should therefore record whether an error is retryable and why that decision was made.
Classify before rescheduling
| Error example | Initial decision | Action |
|---|---|---|
| Timeout or lost connection | Possibly retry | Back off and check idempotency |
| HTTP 429 | Retry | Honor Retry-After |
| HTTP 400/validation | Do not retry | Correct the payload |
| Duplicate key | Depends on intent | Identify duplicate or conflict |
| Unauthorized | Limited retry | Refresh credentials, then retry once |
HTTP status helps but is insufficient. Some APIs use HTTP 500 for invalid input, while others return HTTP 200 with failure status in the body. An adapter must understand the destination contract and retain technical details so an operator can assess the decision.
A healthy retry policy
- Define retryable failures.
Use structured codes and categories for connection, rate limit, authentication, constraint, and configuration.
- Apply backoff.
Do not resend rapidly while the destination is already in trouble.
- Limit attempts and retention.
A message must not loop forever without an operational decision.
- Use stable identity.
An idempotency key or business key protects the target from repeated effects.
- Record every outcome.
Attempt, time, latest error, and next schedule should be traceable.
Example decisions in an invoice workflow
If a database connection is unavailable before processing, the message may be rescheduled. If a check constraint rejects status, the same payload will always fail; the workflow should identify the rejected value and relevant rule. If an insert response is lost after commit, retrying without stable identity can create a second invoice.
Effects on external APIs are at-least-once. Reuse the same idempotency key across attempts when the API supports it. For an expired login token, one coordinated refresh or re-login may be appropriate, while unlimited authentication retries risk a login storm.
What happens after the retry limit?
A message that cannot succeed during retention should become a visible failed or dropped state, not disappear. Operators need the latest error, relevant node and destination, attempt count, and correlation ID. The next decision may be configuration repair, controlled replay, data correction, or permanent termination.
When evaluating NitroNet or another integration platform, test whether failures can be classified, retries can be controlled, and data-journey states remain understandable. Any queueing mechanism is neither unlimited storage nor a promise that the destination will recover.
Add jitter when many workers may retry at the same time. Backoff without jitter wakes every message together and overwhelms a recovering service again. Apply concurrency limits and rate limits aligned with destination capacity. For priority queues, do not let one problematic message block a whole group unless strict ordering is a business requirement.
Test the policy as a contract, not merely a set of numbers. Simulate timeout before arrival, timeout after destination processing, HTTP 429 with Retry-After, and permanent validation errors. The dashboard should expose attempts and next schedules, while alerts should avoid firing for every transient attempt. Alert on trends, backlog, message age, and work approaching retention so operators can act before the processing opportunity expires.
Review policy from production evidence. If retries for one code almost always fail, classification may be wrong. If a second attempt commonly works but backlog grows, reconsider backoff or capacity. Change policy through Sandbox and failure simulation rather than increasing attempts without analysis.
Limits that retry must not hide
ACID transactions are limited to one database connection. External APIs and email are at-least-once, so destination idempotency and reconciliation remain necessary.
Design failure routes before Production and test them in Sandbox. To explore repetition risk further, read about choosing database operations and the agent-centric flow where queues and agents operate.