این مطلب من کجاست!!!

کاربر پست می‌فرسته، صفحه رو Refresh می‌کنه ولی پستش نیست. یه ثانیه بعد ظاهر می‌شه.

این باگ نیست. این مشکله Read-Your-Writes Consistency

این مشکل در کتاب Designing Data-Intensive Applications بصورت خلاصه به این صورت تعریف شده:

"After a user writes data, they should see their own write in subsequent reads — regardless of which replica serves the request."

وقتی یه سیستم Leader/Follower Replication داره، Write به Leader می‌ره ولی Read ممکنه از Followerی بیاد که هنوز sync نشده. نتیجه؟ کاربر داده‌ی خودش رو نمی‌بینه.

حالا چطور میشه این مورد رو حل کرد؟

۱. همیشه از Leader بخونیم
ساده‌ترین راه‌حل و البته بدترین. این روش Leader رو Bottleneck می‌کنه. Followerها بی‌استفاده می‌مونن. در Multi-Device کار نمی‌کنه.

۲. Time Window Routing
بعد از Write، برای ۶۰ ثانیه همون کاربر رو به Leader هدایت کن.
مشکل: اگر Replication Lag از ۶۰ ثانیه بیشتر شد، چی؟

۳. LSN-Based Routing
Leader بعد از هر Write، یه Log Sequence Number برمی‌گردونه.
Read بعدی فقط به Replicaای می‌ره که LSN اون >= lastWriteLSN باشه.
به جای زمان، از موقعیت واقعی Replication استفاده می‌کنه.

۴. Commit Token (روش Oracle BDB) 🎯
Leader یه Token تولید می‌کنه، Client اون رو نگه می‌داره و با هر Read ارسال می‌کنه. Replica چک می‌کنه که آیا به اون Transaction رسیده یا نه.

در پروژه‌های ترکیب Redis + LSN-Based Routing بهترین تعادل بین دقت و scalability رو می‌ده.

حالا به چه صورت؟ بعد از هر Write، commitPosition رو با TTL در Redis ذخیره کنیم. در Read، فقط Replicaای رو انتخاب کنیم که به اون position رسیده.

اگه این مشکل رو داری نادیده می‌گیری، کاربرهات دارن این تجربه رو می‌کنن — و فکر می‌کنن bug. پس اگه سیستمی با تعداد یوزر زیاد و هم زمانی زیاد داری بهتره که حواست به این مورد باشه.

نمونه کد حل این مشکل
blog.mhkarami97.ir/posts/read_write_consistency