سوالات بیزینسی و راه حل :
- سرویس باید درخواستها رو به یه provider (مثلا بانکی یا پرداختی) فوروارد کنه. Provider محدودیت داره (مثلا ۱۰ درخواست در ثانیه). و اگر درخواست ۱۱ بفرستیم جواب نمی ده ، راه حل
جواب : صف (Queue) بین سرویس و پروایدر درخواستهای ورودی رو مستقیم به provider نمیزنید . اینطوری اگر ۱۰۰۰ درخواست توی یک ثانیه بیاد، ۹۹۰ تاش توی صف میمونه و به مرور ارسال میشن
اگر صف پر شد ، قدیمیترین درخواستها رو بندازید دور و به کلاینت بگید بعدا دوباره تلاش کنه .
- اگر Provider جلوی IP رو بلاک کرد، چه fallback یا contingency plan ای داری؟
اگر Provider جلوی IP ما رو بلاک کنه، چند لایه fallback دارم: اول multi-IP یا multi-region تا سریع روی مسیر سالم سوییچ کنیم. دوم اگر کل provider در دسترس نبود، failover به provider پشتیبان. سوم اگر هیچکدوم جواب نداد، درخواستها رو در queue نگه میدارم تا بعداً دوباره replay کنم. Circuit breaker و مانیتورینگ هم هست تا retry بیپایان نکنیم و سریع alert بگیریم. در سطح بیزنس هم با SLA و قرارداد جلوی بلاک ناگهانی رو میگیرم و تجربه کاربری رو با پیام شفاف مدیریت میکنم
- یه سرویس سفارش (Order Service) طراحی کن که گارانتی قوی برای consistency داشته باشد
فرض ها
هر سفارش exactly-once created شود (نه دوبار، نه صفر بار).
وضعیت سفارش و عملیات مربوط (رزرو موجودی و پرداخت) اتمی جلو برود؛ یا کامل، یا هیچی.
در برابر خرابیها (leader failover، retry کلاینت، قطع شبکه) مقاومت داشته باشد
جواب
من Order Service را با Single-Writer Leader, Idempotency-Key سختگیرانه، Coordinator با الگوی TCC برای پرداخت/موجودی، Isolation SERIALIZABLE و Transactional Outbox طراحی میکنم؛ این ترکیب هم exactly-once ایجاد سفارش را میدهد، هم در خرابیها با جبران و ریکاوری consistency قوی حفظ میشود
خواندنهایی که به “تازگی” حساسن (مثلاً بلافاصله بعد از ایجاد سفارش بخوای status رو ببینی) → باید از Leader خونده بشه.
بقیه خواندنها (report، سرچ، لیست سفارشها) میتونن از Replica بیان چون چند میلیثانیه تاخیر مهم نیست.
جزییات
-
خوندن و نوشتن هر دو نباید از رپلیکا باشه
-
باید ترنس اکشن اتمیک باشه