פתרון ארכיטקטורה עם גבולות ברורים

הבדיקה של המפה המלאה ממלאת מזהים חדשים עד 64. בקשה חדשה נוספת מחזירה full. בקשה קיימת עם אותו תוכן מחזירה duplicate, כי החיפוש נעשה לפני בדיקת הקיבולת. שינוי התוכן עם אותו מזהה מחזיר conflict גם תחת עומס.

הבעלות על המצב נמצאת בשירות ובjournal שלו. הממשק מחזיק תצוגה של המצב, והworker מחזיק את ביצוע הניסיון הנוכחי. לכן סגירת הממשק אינה מוחקת עבודה, וקריסת worker אינה מתירה לclient להניח שלא בוצע דבר.

בסגירת UI מפסיקים subscriptions ומסיימים שימוש בdispatcher, אבל native context נשאר חי עד סוף חוזה הcallback. בקריסת worker השירות בודק איזה שלב נרשם ומהי סמנטיקת הפעולה לפני ניסיון חוזר. בניתוק query הלקוח שומר מזהה ומנסה לשאול שוב, בלי להמציא מזהה חדש לאותה בקשה.

הסרה של תהליך worker יכולה לחסוך serialization וcontext switches, אך אז קריסה טבעית שלו תפגע גם בשירות. ההחלטה תלויה בדרישת הבידוד ובעלות על קוד הרחבה, ואינה נקבעת לפי מספר שכבות שנראה מרשים בתרשים.

המודל שבקוד אינו durable ואינו thread safe. אלה גבולות מפורשים של ניסוי קבלת ההחלטה. המימוש המשולב מוסיף serialization של state או נעילה מתאימה, journal וחוזה פינוי לרשומות ישנות. פינוי לפני סוף חלון הretry מבטל הבטחה שהלקוח עדיין מסתמך עליה.