Integration and events checklist

Every rule in the integration and events playbook, by chapter, required rules first. Each links to its own page with how we built it and how to check it. This is a lot to check. An Expert can check it for you.

Contracts and schemas

• Required EVT-4 Let a schema registry refuse breaking changes
• Recommended EVT-1 Describe every channel in an AsyncAPI document
• Recommended EVT-2 Wrap every event in one envelope
• Recommended EVT-3 Version event payloads
• Recommended EVT-5 Treat each source schema as a contract

Publishing events

• Required EVT-8 Cap and watch replication slots
• Recommended EVT-6 Send side effects through an outbox
• Recommended EVT-7 Read changes from the database log
• Recommended EVT-9 Choose the partition key for the order you need
• Recommended EVT-10 Deliver events through a shared channel

Consuming events

• Required EVT-11 Process each message once
• Recommended EVT-12 Don't rely on event order
• Recommended EVT-13 Alert when a consumer falls behind
• Recommended EVT-14 Keep events long enough to replay them
• Recommended EVT-15 Undo failed multi-step work with compensating steps

Background jobs and queues

• Required EVT-18 Bound the backlog and push back on producers
• Recommended EVT-16 Move slow work out of the request
• Recommended EVT-17 Give every job a time limit
• Recommended EVT-19 Keep urgent jobs in their own queue
• Recommended EVT-20 Put record IDs in jobs instead of copies
• Recommended EVT-21 Spread scheduled work across the hour
• Recommended EVT-22 Run each scheduled job once at a time
• Recommended EVT-23 Set aside messages that keep failing
• Recommended EVT-24 Replay dead letters with a written procedure

Webhooks

• Required EVT-25 Sign every webhook
• Required EVT-26 Check webhook addresses before sending
• Recommended EVT-27 Retry until the receiver accepts
• Recommended EVT-28 Store each incoming webhook before you act on it
• Recommended EVT-29 Let customers test and inspect their webhook endpoints

Related playbooks

• Reliability

  In the API design playbook. Clients that retry an HTTP request send an idempotency key, the request-side twin of a consumer that runs once.

• Transactions and concurrency

  In the Data and databases playbook. Each consumer records its work and its processed key in one database transaction.

• Alerts and on-call

  In the Operations and observability playbook. Queue age and consumer lag only help when an alert wakes someone.

• Payment events and reconciliation

  In the Payments and billing playbook. Payment webhooks arrive late, twice or never. Reconcile them against the provider every hour.

Show the badge on your project

When your project passes every Required rule, you can show this badge on your site or in your README. It links to this checklist, so anyone can run the same checks.

<a href="https://agentwranglers.se/playbook/events/checklist"><img src="https://agentwranglers.se/badge.svg" alt="Checked against the Agent Wranglers integration and events playbook" width="214" height="20"></a>

[![Checked against the Agent Wranglers integration and events playbook](https://agentwranglers.se/badge.svg)](https://agentwranglers.se/playbook/events/checklist)