# Design a Multi-Vendor Integration Platform ### Prompt Design a platform that connects a product to many third-party vendors such as email and team-messaging providers. A customer authorizes an account, the product invokes vendor actions, and the platform ingests vendor events through webhooks or polling. New connectors should be addable without copying authentication, retry, rate-limit, and observability logic into every integration. Explain the connector contract, authorization and secret handling, execution path, event ingestion, data model, and failure isolation. **Candidate hint:** Separate a stable platform lifecycle from vendor-specific capabilities and payloads. The common model should not pretend every vendor behaves identically. ### Constraints & Assumptions - Vendors differ in authentication, quotas, pagination, webhook guarantees, and error formats. - Customer credentials and event payloads are sensitive. - Requests and events can be duplicated or delivered out of order. - A failing or rate-limited vendor must not stall unrelated connectors. - State assumptions about action latency and how much payload normalization the product requires. ### Clarifying Questions to Ask - Which actions and events must be common across connectors? - Are actions synchronous from the caller's perspective, or may they complete asynchronously? - What freshness is required when a vendor offers no webhook? - Must customers choose data residency or retention policies? ### What a Strong Answer Covers - A connector interface with capability discovery and versioning - Secure authorization, credential rotation, tenant isolation, and revocation - Durable action execution with idempotency, retry classification, and per-vendor rate control - Webhook verification, polling cursors, deduplication, and replay - Isolation, backpressure, schema evolution, auditing, and connector-specific observability - A practical onboarding and test strategy for new vendors ### Follow-up Questions 1. How would you migrate a connector when a vendor introduces a breaking API version? 2. What happens when a customer revokes access while actions are queued? 3. How do you preserve vendor-specific fields without coupling every product consumer to raw payloads? 4. How would you safely replay a week of missed events?