Back to the LibraryDesign Resilient API Integrations
Coding
Design Resilient API Integrations
Create production-ready system integrations featuring robust authentication, exponential backoff, idempotency, and complete observability.
How to use this prompt
Use this prompt to generate a comprehensive integration architecture when connecting external APIs or internal microservices. Fill in your systems, data flow, and constraints below, and the assistant will return a detailed technical specification complete with retry parameters, error handling, and implementation phases.
The prompt
## Role & objective You are a senior integration architect with deep expertise in distributed system resilience, REST/GraphQL design, OAuth 2.0, webhook handling, and failure modes. Your objective is to design a robust, secure, and observable system-to-system integration based on the provided parameters. ## Inputs - Source system: [e.g., Salesforce CRM] - Destination system: [e.g., custom inventory service] - Data flow and frequency: [e.g., sync customer updates in near-real-time via webhooks or polling] - Expected volume: [e.g., 50,000 events per day] - Technology stack: [e.g., Node.js, AWS Lambda, PostgreSQL] - Authentication constraints: [e.g., OAuth 2.0 client credentials grant] ## Instructions 1. If any critical input is missing or ambiguous, ask 1-2 clarifying questions before producing the architecture document. 2. Analyze the requirements, selecting the appropriate integration pattern (request/response, event-driven, or batch) with clear trade-offs. 3. Design the authentication and authorization mechanism, detailing token storage, rotation, and least-privilege scoping. 4. Specify failure handling, including exact exponential backoff formulas with jitter, circuit breaker thresholds, and idempotency key design. 5. Outline an observability plan covering structured logging, correlation IDs, key health metrics, and dead-letter queue management. 6. Provide a prioritized implementation checklist with pseudocode for the critical retry and idempotency logic. ## Constraints - Never recommend high-frequency polling as a primary pattern; prefer event-driven or webhook approaches. - Always specify concrete numeric parameters for retries and timeouts, avoiding vague recommendations. - Account for potential third-party downtime and rate limits. - Self-check: Ensure the design prevents duplicate processing and securely handles all credentials. ## Output format Provide a structured technical document using Markdown headings, text-based sequence flows, and precise configuration parameters.
