بازگشت به کتابخانهکتابخانه11.3Case Study: بلیت‌فروشی و Notification Platform
طراحی سیستم نرم‌افزاریSYSTEM DESIGNاز صفر تا تسلط
v1.0.0
01مبانی و تصویر بزرگ
02Scalability و ظرفیت
03لایه داده
04Cache، Queue و جریان
05معماری نرم‌افزار
06قابلیت اطمینان و عملیات
07متد طراحی
08Case Study های واقعی
09سیستم‌های توزیع‌شده عمیق
10مهندسی تولید: داده، امنیت و کارایی
11تمرین پیشرفته و کیس‌استادی‌های مکمل
12زیر کاپوت دیتابیس و معماری داده
13وب بلادرنگ و پروتکل‌های مدرن
14سیستم‌های توزیع‌شده پیشرفته
15SaaS ،SRE ،امنیت و شبکه پیشرفته
16طراحی سیستم در عصر AI
17Case Study های تکمیلی
LESSON 11.3فصل ۱۱تمرین پیشرفته و کیس‌استادی‌های مکمل

Case Study: بلیت‌فروشی و Notification Platform

  • ~۱۸ دقیقه
  • ۲ پرسش
  • متن را انتخاب کن تا هایلایت شود

بلیت‌فروشی یعنی هزاران نفر هم‌زمان برای چند صندلی محدود تلاش می‌کنند. نوتیفیکیشن یعنی یک اتفاق باید به افراد زیادی، از چند کانال و با تنظیمات شخصی برسد. در هر دو، کار اصلی را سریع و مطمئن انجام می‌دهیم و کارهای فرعی را به صف می‌سپاریم.

بلیت‌فروشی Flash Sale

  • CDN و waiting room در لبه، ظرفیت checkout را محدود می‌کند؛ token صف امضاشده و expiry دارد و bypass آن مجاز نیست.
  • منبع حقیقت صندلی در DB تراکنشی است: UPDATE ... WHERE status=free یا unique constraint؛ hold با expiry ثبت می‌شود، سپس payment pending و finally confirm.
  • hold expiry باید job قابل‌اعتماد و idempotent داشته باشد؛ payment timeout = pending + reconciliation، نه آزادسازی حدسی صندلی.
  • هر client action idempotency key دارد؛ وضعیت reservation state machine و audit log دارد.

Notification Platform

  • producer فقط event معتبر منتشر می‌کند؛ policy service audience، consent، quiet hours، template و channel را تعیین می‌کند.
  • هر channel adapter (email/SMS/push) queue و rate limit خودش را دارد؛ provider callback تکراری/دیررس idempotent مصرف می‌شود.
  • dedup key و collapse key از spam جلوگیری می‌کنند؛ preference/opt-out منبع حقیقت و audit‌پذیر است.
  • metrics: accepted، queued، sent، provider-accepted، delivered/clicked (با تعریف دقیق)، bounce و lag. «sent» به معنی «دیده شد» نیست.

به زبان ساده

بلیت‌فروشی یعنی مهار موج در لبه (اتاق انتظار) و رزرو اتمیک با انقضا در مرکز؛ نوتیفیکیشن هم یعنی صف‌های جدا per کانال با احترام به ترجیحات کاربر.

مثال واقعی

صندلی با UPDATE شرطی hold می‌شود و ۱۰ دقیقه مهلت پرداخت دارد؛ اگر پرداخت نامعلوم ماند، صندلی حدسی آزاد نمی‌شود — reconciliation تصمیم می‌گیرد.

دانش‌سنجی

آزمون درس

۲ Q
01
چرا hold صندلی را پس از payment timeout فوراً آزاد نمی‌کنیم؟
02
کدام معیار delivery نوتیفیکیشن دقیق‌تر است؟