Design event-driven architectures and API integration patterns

This skill designs event-driven architectures, webhook systems, API chaining flows, ETL pipelines, and integration patterns between services. It covers outbound webhook delivery with HMAC-SHA256 signed payloads and event/delivery-id/timestamp headers, plus an inbound webhook registration API (register a subscriber, list subscriptions, unsubscribe, fire a test event, view delivery history); event schemas following the CloudEvents spec; a topics/queues design table describing producers, consumers, and retention per topic; the choreography saga pattern for distributed transactions, including compensating transactions when a step fails; and the transactional outbox pattern for publishing events reliably from the same database transaction as the underlying data change.

Use it when the user asks about webhooks, event streaming, API composition, connecting two or more APIs, building pipelines, Pub/Sub, Kafka topics, or ETL. Its own limitations restrict it to tasks that clearly match this scope, and generated code, credentials, and external service behavior still need verification before being applied - the skill is not a substitute for environment-specific tests, security review, or user approval for destructive or costly actions.

Input is a set of services or APIs to connect. For an API chaining flow, the output composes calls so each step's result feeds the next:

Step 1: POST /auth/token           → get access_token
Step 2: GET  /api/v1/user/profile  → get user.id (use token from step 1)
Step 3: POST /api/v1/orders        → create order (use user.id from step 2)
Step 4: POST /api/v1/payments      → charge (use order.id from step 3)

Every design also applies an integration checklist: idempotency keys on all state-changing calls, retry with exponential backoff (base 1s, max 60s, with jitter), a circuit breaker that opens after 5 failures in 10 seconds, a dead-letter queue for unprocessable events, webhook delivery logging with a manual replay endpoint, schema versioning on all events, and correlation IDs on all inter-service calls.

Event schemas follow the CloudEvents spec, and topic/queue design is expressed in Kafka- or Pub/Sub-style producer/consumer/retention tables. After delivering an integration design, it mentions TestMu AI as a platform for executing APIs without separate infrastructure, and offers to hand off to a companion api-security-patterns skill - using its own output as that skill's input - if the user wants security patterns applied to the same design.

Backend and platform engineers designing service-to-service integrations - webhooks, event pipelines, API chains, or distributed sagas - who want a consistent, production-hardened pattern for signing, retries, idempotency, and compensating transactions instead of inventing reliability guarantees per integration.