Multi-Region، CRDT و بازیابی فاجعه — طراحی سیستم نرم‌افزاری

چند AZ یعنی چند ساختمان مستقل در یک منطقهٔ جغرافیایی؛ چند Region یعنی مثلاً دیتاسنتر تهران و فرانکفورت. Region دوم می‌تواند کاربران دور یا خرابی کامل منطقه را پوشش دهد، ولی هماهنگ‌کردن داده بین آن‌ها سخت‌تر و گران‌تر است.

مدل	نوشتن	مزیت	هزینه
Single-region + DR	یک region؛ replica/backup دور	ساده، RPO/RTO روشن	failover کندتر
Active-passive	region دوم آماده یا گرم	کنترل conflict ساده	ظرفیت بلااستفاده و RTO
Active-active	هر region می‌نویسد	تأخیر محلی و تحمل فاجعه	conflict، routing و observability پیچیده

انتخاب بر اساس داده، نه شعار

Home region

هر tenant/user یک region مالک دارد؛ write همان‌جا و read جهانی از replica. راه ساده برای کاهش conflict.

Conflict resolution

last-write-wins ساده ولی ممکن است داده را بی‌صدا حذف کند؛ برای داده مهم rule دامنه یا review لازم است.

CRDT

ساختار داده‌ای که merge آن جابه‌جاپذیر و همگراست؛ مانند G-Counter یا OR-Set. مناسب شمارنده/مجموعه، نه همه business ruleها.

RPO/RTO

باید per-service و عددی باشد: مثلاً پرداخت RPO=0 و RTO=۱۵ دقیقه؛ analytics ممکن است RPO=۱ ساعت تحمل کند.

طرح DR کامل شامل backup immutable، restore آزمایش‌شده، runbook، DNS/traffic failover، رازها و dependencyهای region دوم است. backup بدون تمرین restore، ضمانت نیست. برای active-active، duplicate request بین region و failover وسط پرداخت را با idempotency سراسری و reconciliation تست کن.

به زبان ساده

داشتن دیتاسنتر دوم یعنی کاربرِ دور و خرابیِ کامل یک منطقه پوشش داده می‌شود؛ اما وقتی دو منطقه هم‌زمان می‌نویسند، باید برای تداخل داده‌ها قانون داشته باشی.

مثال واقعی

کاتالوگ فروشگاه جهانی از نزدیک‌ترین region خوانده می‌شود و چند ثانیه کهنگی‌اش مهم نیست؛ ولی آخرین موجودی کفش نباید هم‌زمان در تهران و اروپا کم شود — برای موجودی یک region مالکِ نوشتن است.

انتخاب بر اساس داده، نه شعار

به زبان ساده

مثال واقعی

آزمون درس