مسئله: کاتالوگ، سبد خرید، سفارش و موجودی — جایی که Read-Heavy (کاتالوگ) و Write-critical (سفارش/موجودی) در یک محصول جمعاند و باید جدا مهندسی شوند.
۱-۳) نیازمندی و طرح کلان
- کاتالوگ و جستجو: Read-Heavy خالص → کش تهاجمی + CDN + Elasticsearch؛ کهنگی چندثانیهای مجاز.
- سبد خرید: داده per-user پرتغییر و قابل بازیابی → Redis (با TTL بلند) + پشتوانه DB برای login بین دستگاهها.
- سفارش و پرداخت: مقدس — ACID ،idempotency، صفر گمشدگی.
- موجودی: مرز جنگ — همزمانی بالا روی کالای محدود.
DIAGRAMثبت سفارش
Checkout svc
→
DB تراکنشی — سفارش + رزرو موجودی
→
Outbox → Kafka
→
ایمیل
انبار
تحلیل
۴) عمق — موجودی و فروش ویژه
- ضدـoversell: هرگز check-then-write جدا؛ یا UPDATE اتمی شرطی (SET stock=stock-1 WHERE stock>0) یا شمارنده اتمی Redis که از DB سرچشمه میگیرد.
- رزرو دومرحلهای: افزودن به سبد ≠ رزرو؛ رزرو در checkout با TTL (مثلاً ۱۰ دقیقه) — انقضا برگرداندن خودکار.
- Flash Sale: صف/waiting room جلوی checkout، موجودی در Redis اتمی، بقیه مسیر async — فصل ۴ را زنده کن.
- قیمت و تخفیف در لحظه ثبت «فریز» میشود — تغییر بعدی قیمت، سفارش قبلی را عوض نمیکند (snapshot).
- سفارش = state machine با رویدادها (placed → paid → shipped → delivered)؛ هر مصرفکننده (انبار، ایمیل) idempotent.
به زبان ساده
فروشگاه آنلاین یعنی کاتالوگ خواندنیِ کشپذیر، سبد خرید سبک، و یک مسیر پرداخت باریک ولی بسیار سختگیر که همه انعطاف سیستم را میبلعد.
مثال واقعی
در حراج، صفحه محصول را CDN و کش تحمل میکنند؛ گلوگاه واقعی checkout است — آنجا موجودی با UPDATE شرطی کم میشود تا دو نفر آخرین کالا را نخرند.