Retry & Resilience Policy

📅 Last Updated: 2026-01-15 👥 Engineering Ops & Platform Architecture 🔒 Internal & Partner Access

1. Policy Overview

Aevum Zenth operates a distributed, multi-tenant infrastructure spanning 400 subsidiaries across 62 countries. To maintain system stability, data integrity, and consistent client experiences, all internal and external API integrations must adhere to a standardized retry and resilience framework.

ℹ️

This policy applies to all REST, GraphQL, and event-driven interfaces managed by Zenth Digital Systems. Non-compliant implementations may be rate-limited or deprecated.

Core principles driving this policy include exponential backoff with jitter, strict idempotency enforcement, circuit breaker patterns for inter-service communication, and comprehensive observability for all retry events.

2. Technical Standards

All retry logic must follow the parameters defined below. Deviations require architectural review and written approval from the Platform Stability Council.

Parameter	Value / Behavior	Rationale
Max Attempts	3 (initial + 2 retries)	Prevents cascade failures while allowing transient recovery
Base Delay	1,000 ms	Allows upstream load balancers & auto-scalers to respond
Multiplier	2.0 (Exponential)	Standard backoff curve matching 99th percentile latency budgets
Max Delay	30,000 ms	Caps waiting time to avoid timeout accumulation
Jitter	Full jitter (0 to delay)	Eliminates thundering herd effects on origin servers
Idempotency	Required for all non-GET methods	Guarantees safety of repeated identical requests

                    
                    RetryConfiguration {
  maxAttempts: 3,
  baseDelayMs: 1000,
  maxDelayMs: 30000,
  multiplier: 2.0,
  jitterStrategy: "FULL_JITTER",
  retryableStatusCodes: [408, 429, 500, 502, 503, 504],
  requireIdempotencyKey: true
}
                

3. Status Code Handling

Retry behavior must be explicitly mapped to HTTP status codes. Blind retries on client errors will result in immediate throttling.

Status Code	Category	Retry Policy
400, 401, 403, 404, 422	Client Error	❌ Never retry. Log & fail fast.
408	Request Timeout	✅ Retry permitted (max 2)
429	Rate Limited	⏸️ Respect `Retry-After` header. If absent, apply exponential backoff.
500, 502, 503, 504	Server/Network Error	✅ Retry permitted (max 2)
Network Timeout / DNS Failure	Infrastructure	✅ Retry with increased base delay (2000ms)

⚠️

Never retry on 4xx except 408 and 429. Repeated client-error retries will trigger automated abuse detection and IP/subnet throttling.

4. Implementation Guidelines

When integrating with Aevum Zenth endpoints, follow these architectural best practices:

Idempotency Keys: All POST, PUT, PATCH, and DELETE requests must include a unique X-Idempotency-Key header. Zenth APIs cache responses for 24 hours keyed to this value.
Circuit Breakers: Implement stateful circuit breakers for synchronous calls. Open circuit after 5 consecutive failures. Half-open after 15s. Close on success.
Observability: Log all retry attempts with trace IDs, latency, status code, and jitter values. Forward to your metrics pipeline.
Timeout Budgets: Total request timeout must equal or exceed maxDelayMs * maxAttempts. Recommended: 60s hard timeout.

                    
                    fetch(endpoint, {
  method: 'POST',
  headers: {
    'Content-Type': 'application/json',
    'X-Idempotency-Key': crypto.randomUUID()
  },
  body: JSON.stringify(payload)
})
.then(handleSuccess)
.catch(applyRetryLogic);
                

5. Operational SLA & Client Communication

For business-critical workflows that cannot tolerate retry-induced latency, Aevum Zenth offers synchronous fallback channels and async queueing patterns.

Guaranteed Delivery: Event webhooks include exactly-once processing semantics. Duplicates are deduplicated server-side.
Outage Notification: During P1/P2 incidents, retry policies are dynamically relaxed via feature flags. Clients are notified via status page status.aevumzenth.com.
SLA Credits: Retry exhaustion resulting in failed critical operations triggers automatic SLA credit calculation per the Enterprise Agreement.

🚨

Do not implement infinite retry loops. They guarantee resource exhaustion and violate Section 4.2 of the Zenth Partner Agreement.

6. Policy Exceptions & Support

Legacy systems, third-party constraints, or specialized infrastructure may require policy deviations. Exception requests are reviewed on a case-by-case basis.

Submit architectural proposals via the Partner Engineering Portal or contact the Platform Stability team directly.

Request Exception View Policy Changelog