رویداد را مستقل از ارسال تعریف کنید
بنویسید هر رویداد چه معنایی دارد، چه زمانی ایجاد می‌شود و کدام منبع را توصیف می‌کند. به رویداد یک شناسه پایدار بدهید که هنگام تلاش دوباره برای ارسال نیز ثابت بماند. این هویت را از یک درخواست HTTP یا تلاش ارسال جدا نگه دارید. نسخه schema و زمینه کافی را وارد کنید تا سیستم دریافت‌کننده بتواند رکورد مرجع را پیدا کند. مصرف‌کنندگان را مجبور نکنید از یک اعلان مبهم مثل «چیزی تغییر کرد» گذار تجاری را حدس بزنند. با payloadهای نمونه، فیلدهای اختیاری، مقدارهای حذف‌شده و تغییرات رکوردهای موجود را توضیح دهید. توافق کنید پیام یک snapshot کامل است یا فقط سیگنالی برای دریافت وضعیت فعلی.
نحوه برخورد با تکرارها و ترتیب را مشخص کنید
فرض کنید ارسال ممکن است تکرار شود یا پس از پیامی جدیدتر برسد. برنامه دریافت‌کننده باید ثبت کند کدام رویدادها را پردازش کرده و اقدام تجاری حاصل را برای تکرار ایمن کند. دریافت دوباره یک اعلان نباید دو مجوز یا دو پرونده پشتیبانی ایجاد کند، مگر اینکه صراحتاً همین قصد وجود داشته باشد. برای تغییراتی که به ترتیب وابسته‌اند، یک مرجع ترتیب یا بررسی در برابر وضعیت فعلی منبع تعریف کنید. زمان رسیدن را بدون توضیح، جایگزین ترتیب تجاری نکنید. پیش از انتخاب پیاده‌سازی، مجموعه‌ای از رویدادهای عمداً به‌هم‌ریخته را آزمایش کنید و نتیجه مورد انتظار را توضیح دهید. هر دو تیم باید بدانند کدام سیستم تعارض‌ها را حل می‌کند.
خطاها را بدون تلاش‌های بی‌پایان قابل مشاهده کنید
مشخص کنید چه چیزی ارسال پذیرفته‌شده محسوب می‌شود و خطاهای موقت را از درخواست‌هایی که بدون تغییر موفق نمی‌شوند جدا کنید. از سیاست تلاش مجددِ محدود با تاریخچه تلاش‌های قابل مشاهده استفاده کنید، سپس رویدادهای حل‌نشده را به وضعیتی قابل بازبینی منتقل کنید. اپراتورها به شناسه رویداد، مقصد، آخرین تلاش، دسته پاسخ و اقدام برنامه‌ریزی‌شده بعدی نیاز دارند. فیلدهای حساس payload را در لاگ‌ها و داشبوردها محافظت کنید. timeout می‌تواند فرستنده را نامطمئن بگذارد، حتی اگر گیرنده کارش را تکمیل کرده باشد؛ بنابراین بررسی باید از شناسه‌های پایدار در هر دو طرف استفاده کند. دکمه تلاش مجدد باید توضیح دهد چه چیزی را تکرار می‌کند و هویت رویداد اصلی را حفظ کند، نه اینکه یک رخداد تجاری تازه بسازد.
برای مالکان یکپارچه‌سازی راهنمای عملیاتی کاربردی فراهم کنید
راه‌اندازی، تأیید endpoint، چرخش secret، رویدادهای آزمایشی و روند توقف موقت ارسال را مستند کنید. مشخص کنید مالک endpoint دریافت‌کننده کیست و تغییرات پیکربندی چگونه بازبینی می‌شوند. راهی برای بررسی یک رویداد نمونه بدون افشای secretهای تولید فراهم کنید و برچسب‌های محیط را کاملاً واضح بگذارید. در مرحله پذیرش، گیرنده در دسترس نبودنی، payload نامعتبر، رویداد تکراری و بازیابی پس از اصلاح پیکربندی را تمرین کنید. علاوه بر صفحه ارسالِ فرستنده، رکوردهای حاصل در سمت مشتری را هم بررسی کنید. خروجی مفید، یک اتصال قابل اتکا با رفتار قابل توضیح است، نه صرفاً نشان سبز موفقیت از یک درخواست در زمان نمایش.