تعریف کنید ایندکس دقیقاً چه چیزی را نمایش می‌دهد
ایندکسر، بخش‌های انتخاب‌شده‌ای از فعالیت زنجیره را به رکوردهایی تبدیل می‌کند که یک اپلیکیشن بتواند آن‌ها را جست‌وجو و نمایش دهد. کار را با فهرست‌کردن پرسش‌هایی شروع کنید که باید پاسخ داده شوند: انتقال‌های مربوط به یک آدرس، پوزیشن‌های یک حساب، یا تاریخچه یک قرارداد مشخص. این مدل خواندن را از تصمیم‌های تجاری مثل پرداخت یک فاکتور یا اعطای دسترسی به محصول جدا نگه دارید. مشخص کنید کدام رویدادها روی هر نما اثر می‌گذارند و چه تعداد تأیید اجازه می‌دهد اقدامات بعدی انجام شوند. با این کار می‌توان یک نمایش را دوباره ساخت، بدون آنکه ناخواسته همه اقدام‌های تجاری‌ای که در ابتدا پس از آن رویدادها انجام شده‌اند تکرار شوند.
اتصال زنده را به‌عنوان شتاب‌دهنده در نظر بگیرید
سابسکریپشن‌های Geth رویدادهای جاری را تحویل می‌دهند و با بسته‌شدن اتصال از بین می‌روند؛ آن‌ها جایگزین بازیابی تاریخی نیستند. از به‌روزرسانی‌های زنده برای کاهش تأخیر استفاده کنید، در کنار اسکن محدود و کنترل‌شده‌ای که از پیشرفت ذخیره‌شده ادامه پیدا می‌کند. مشخص کنید این دو مسیر چگونه بدون ایجاد رکورد تکراری به هم می‌رسند. پیشرفت ذخیره‌شده باید داده‌ای را توصیف کند که با موفقیت ثبت شده است، نه صرفاً پاسخی که از یک ارائه‌دهنده دریافت شده. از تأمین‌کننده بخواهید هنگام دمو، جریان را قطع کند، فعالیت آزمایشی ایجاد شود و سپس اتصال دوباره برقرار گردد. بازه ازدست‌رفته باید با فرایندی قابل‌مشاهده بازیابی شود، نه اینکه برای تعمیر دستی دیتابیس رها شود.
برای توضیح هر رکورد، هویت کافی نگه دارید
شناسه تراکنش به‌تنهایی ممکن است یک رویداد اپلیکیشنی را مشخص نکند. رکوردها را با شبکه، قرارداد، ارجاع بلاک، تراکنش و موقعیت رویدادِ لازم برای زنجیره پشتیبانی‌شده طراحی کنید. وقتی برای توضیح اصلاحات مفید است، مشاهده اولیه را جدا از تفسیر فعلی نگه دارید. تعریف کنید مشاهده‌های تکراری چگونه شناسایی می‌شوند و نسخه‌های پارسر چگونه ردیابی می‌گردند. برای خریدار، یک پرسش پذیرش مفید ساده است: آیا اپراتور می‌تواند از یک ردیف در داشبورد شروع کند و آن را تا دقیق‌ترین شواهد زنجیره‌ای و نسخه پردازشی‌ای که آن را تولید کرده دنبال کند؟
مسیر مشخصی برای سازمان‌دهی مجدد زنجیره طراحی کنید
Geth می‌تواند زمانی که سازمان‌دهی مجدد زنجیره، بلاک‌ها را جایگزین می‌کند، لاگ‌های حذف‌شده را گزارش دهد. بنابراین یک یکپارچه‌سازی به سیاستی برای رکوردهایی نیاز دارد که دیگر به تاریخچه canonical تعلق ندارند. علامت‌گذاری مشاهده‌های تحت‌تأثیر، محاسبه دوباره نماهای وابسته و بازپخش بازه جایگزین را در نظر بگیرید. عوارض جانبی تجاری برگشت‌ناپذیر را پشت سیاست تأیید صریح نگه دارید و آن‌ها را از نمایش‌های موقت جدا کنید. در بازبینی طراحی، یک دنباله کوچک از بلاک‌های جایگزین‌شده را روی کاغذ مرور کنید. مشخص کنید چه چیزی در دیتابیس تغییر می‌کند، مشتری چه می‌بیند، و کدام هشدار اپراتوری اصلاح را توضیح می‌دهد بی‌آنکه آن را به‌صورت یک تراکنش جدید نشان دهد.
تأخیر و عدم‌قطعیت را قابل‌مشاهده کنید
پیشرفت را نسبت به یک سر زنجیره مشخص، خطاهای ارائه‌دهنده، بازه‌های حل‌نشده و سن آخرین به‌روزرسانی موفق پایش کنید. ورکری که در حال اجراست همچنان ممکن است عقب بیفتد. وقتی تاریخچه کامل نیست، انتظار مشتری را روشن کنید: نمایش زمان یا وضعیت موقت مفیدتر از آن است که اطلاعات قدیمی بی‌سروصدا به‌عنوان داده فعلی نمایش داده شود. برای اپراتورها کنترل‌های بازیابی محدود و مشخص فراهم کنید، از جمله بازه‌ای که باید بازپخش شود و دلیل انجام آن. از دکمه بازپخش نامحدود که می‌تواند بدون پیش‌نمایش روشن از اثر خود، اقدامات پایین‌دستی را دوباره فعال کند پرهیز کنید.
رفتار پس از راه‌اندازی مجدد را پیش از سنجش توان پردازش آزمایش کنید
از فیکسچرهای کنترل‌شده برای آزمون رویدادهای تکراری، بازه ازدست‌رفته، بلاک تغییریافته، محدودیت ارائه‌دهنده و کرش بین ذخیره رکوردها و جلو بردن پیشرفت استفاده کنید. بررسی کنید که راه‌اندازی مجدد همان نمای موردنظر را تولید می‌کند که اجرای بدون وقفه تولید می‌کرد. سپس توان پردازش را با قراردادها و الگوهای کوئری واقعی‌ای که انتظار پشتیبانی از آن‌ها را دارید اندازه‌گیری کنید. همراه تحویل، دستورالعمل مهاجرت و فرایند بازسازی را درخواست کنید. قوی‌ترین شاهد این نیست که داشبورد یک‌بار سریع به‌روزرسانی شود؛ بلکه بازیابی مستندی است که پس از شرایطی که اپراتورهای شما سرانجام با آن روبه‌رو می‌شوند، رکوردهای صحیح را برمی‌گرداند.