در سامانه‌هایی که اجزای آن‌ها با رویدادها به یکدیگر مرتبط می‌شوند، خطایی ظریف اما مکرر کمین می‌کند: انتشار خبر وقوع یک رویداد، پیش از آنکه واقعیت امر در حافظه ثبت شده باشد. این خطا بسیار خاموش و بی‌صداست؛ معمولاً در مراحل آزمایش خود را نشان نمی‌دهد و تنها در محیط عملیاتی و زیر بار سنگین ترافیک نمایان می‌شود. با این حال، رعایت قاعده‌ای ساده می‌تواند این مشکل را از ریشه نابود کند: اول ذخیره، بعد انتشار.

کالبدشکافی مشکل

تصور کنید مؤلفه‌ای وظیفه‌ای را به پایان رسانده است و باید دو اقدام انجام دهد: ذخیرهٔ نتیجه در یک حافظهٔ پایدار، و انتشار رویدادی که اعلام می‌کند «کار تمام شد». اگر این ترتیب را معکوس کنید — یعنی ابتدا رویداد را منتشر کنید و سپس عملیات ذخیره‌سازی را انجام دهید — بازه‌ای بحرانی و خطرساز ایجاد می‌شود. مؤلفهٔ دریافت‌کنندهٔ رویداد ممکن است بلافاصله واکنش نشان داده و برای خواندن نتیجه به سراغ حافظه برود؛ اما از آنجا که عملیات ذخیره‌سازی هنوز تکمیل نشده، نتیجه‌ای در کار نخواهد بود. در این حالت، مصرف‌کننده با داده‌ای قدیمی یا خالی مواجه می‌شود و زنجیرهٔ خطا دقیقاً از همین نقطه آغاز می‌شود.

ترتیب صحیح مراحل

راهکار حل این مسئله، رعایت ترتیب صحیح گام‌هاست: ابتدا نتیجه را در حافظهٔ پایا بنویسید، از ثبت کامل آن اطمینان حاصل کنید و تنها پس از آن رویداد را منتشر سازید. اکنون هر مؤلفه‌ای که پیام رویداد را دریافت می‌کند، اطمینان دارد که به هنگام مراجعه به حافظه، واقعیت امر در آنجا ثبت شده است. این همان اصل کلیدی در معماری رویدادمحور است: رویداد صرفاً یک محرک برای آگاهی‌بخشی است و مرجع نهایی حقیقت همواره در حافظه جای دارد. تا زمانی که حقیقت ثبت نشده باشد، نباید پیام محرکی فرستاد.

چرا رعایت این قاعده اهمیت دارد

این قاعده با اصل مهم دیگری نیز همخوانی دارد: رویداد نباید حامل داده باشد، بلکه تنها باید شناسه را منتقل کند. اگر داده‌ها را درون رویداد بگنجانید، وسوسه می‌شوید که آن را پیش از ذخیره‌سازی ارسال کنید و دقیقاً در همین دام خواهید افتاد. اما وقتی رویداد تنها حاوی یک شناسه باشد و مصرف‌کننده ناگزیر شود حقیقت را از حافظه بخواند، رعایت ترتیب «ابتدا ذخیره، سپس انتشار» دیگر یک انتخاب نیست، بلکه به ضرورتی منطقی تبدیل می‌شود.

تحویل حداقل یک‌باره، نه حداکثر یک‌باره

پذیرش یک پیامد مهم دیگر نیز در این میان ضرورت دارد. در سامانه‌های پایا، رویکرد تحویل رویداد معمولاً به‌صورت «دست‌کم یک‌بار» است؛ بدین معنی که احتمال دارد یک رویداد دو بار به مقصد برسد. این یعنی مصرف‌کنندگان پیام باید خنثی‌پذیر باشند؛ به گونه‌ای که پردازش تکراری یک رویداد، به بروز نتایج نادرست نینجامد. تلفیق سازوکار «ابتدا ذخیره، سپس انتشار» با مصرف‌کنندگان خنثی‌پذیر، سامانه‌ای استوار پدید می‌آورد که نه پیام‌ها در آن گم می‌شوند و نه تکرار آن‌ها آسیبی به روند کار می‌زند.

جمع‌بندی

شاید این قاعده در ظاهر ساده و کوچک به نظر برسد، اما مرز میان سامانه‌ای است که زیر بار ترافیکی سنگین پایدار می‌ماند و سامانه‌ای که هر از گاهی دچار خطاهای گذرا و غیرقابل‌ردیابی می‌شود. با اصلاح تقدم و تأخر کارها — یعنی ابتدا ثبت واقعیت و سپس انتشار خبر آن — رستهٔ کاملی از خطاهای رقابتی به‌سادگی از میان می‌روند. در طراحی سامانه‌های پایا، اغلب همین ترتیبات ساده هستند که بیشترین اهمیت را دارند.