وقتی همه صندلی‌های جلوی استیج را می‌خواهند!

فرض کنید بلیت‌های یک خواننده محبوب داخلی — راس ساعت ۱۰ صبح باز می‌شوند.

در کمتر از ۱ ثانیه اول،ده‌ها هزار کاربر همزمان روی «رزرو» کلیک می‌کنند.

چالش این نیست که فقط ترافیک بالاست، بلکه:

✅باید از فروش همزمان و دو بار یک صندلی جلوگیری کرد (Oversell Prevention)

✅سیستم باید زیر ۲۰۰ میلی‌ثانیه به درخواست‌ها پاسخ دهد

✅تجربه کاربری بدون تأخیر و خطا باقی بماند حتی در اوج فشار

🛠 طراحی معماری فنی یک سیستم رزرو مقاوم و سریع

برای چنین شرایطی، ترکیبی از State Machine دقیق، قفل‌گذاری توزیع‌شده، کش هوشمند و معماری میکروسرویس لازم است.

۱️⃣ مدل State Machine برای هر صندلی

چرخه وضعیت هر صندلی به شکل زیر است:

AVAILABLE → RESERVED → BOOKED

📌انتخاب صندلی: وضعیت صندلی به RESERVED تغییر می‌کند و یک تایمر کوتاه (۱۰–۱۵ دقیقه) شروع می‌شود.

📌پرداخت موفق: صندلی به وضعیت BOOKED می‌رود.

📌پرداخت ناموفق یا انقضای تایمر: صندلی دوباره به AVAILABLE بازمی‌گردد.

این مدل به جلوگیری از مشکلات همزمانی (race condition) کمک می‌کند و تضمین می‌کند هر صندلی به صورت منسجم مدیریت شود.

۲️⃣ قفل توزیع‌شده با Redis

وقتی کاربر صندلی را انتخاب می‌کند، سیستم با استفاده از قفل موقت Redis روی آن صندلی قفل می‌کند (TTL مشخص).

TTL قفل به صورت خودکار صندلی را در صورت بی‌فعالیتی کاربر آزاد می‌کند.

سرعت میلی‌ثانیه‌ای Redis امکان هماهنگی لحظه‌ای بین چند سرور را فراهم می‌کند، حتی در برابر میلیون‌ها درخواست همزمان.

⚠️ تنظیم TTL باید دقیق باشد تا هم از آزاد شدن زودهنگام جلوگیری شود و هم از قفل شدن بی‌دلیل.

۳️⃣ کش چندلایه و همگام‌سازی با دیتابیس اصلی

Redis به عنوان کش سریع و منبع وضعیت لحظه‌ای صندلی‌ها عمل می‌کند. وضعیت لحظه‌ای صندلی‌ها در Redis ذخیره می‌شود تا کاربران بتوانند به‌صورت بلادرنگ ببینند چه صندلی‌هایی آزادند.

اما داده‌ها باید در نهایت در دیتابیس اصلی (مثلاً PostgreSQL) به صورت پایدار ذخیره شوند.

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

برای همین:

📌رزروها ابتدا در Redis ثبت و تایید می‌شوند.

📌به صورت دسته‌ای و زمان‌بندی شده (مثلاً هر ۱ دقیقه) یا از طریق صف‌های پیام‌رسان، داده‌ها به دیتابیس اصلی منتقل و ذخیره می‌شوند.

این مدل دو مرحله‌ای، ترکیبی از Write-Through Cache و Batch Persist است که تعادل بین سرعت و پایداری را برقرار می‌کند.

🎯مزایا

✅ سرعت واکنش بسیار بالا (زیر ۲۰۰ میلی‌ثانیه حتی در اوج ترافیک)

✅ جلوگیری موثر از رزرو همزمان یک صندلی (Oversell)

✅ معماری مقاوم، ماژولار و مقیاس‌پذیر

✅ تجربه کاربری روان و قابل اطمینان

⚠️ چالش‌ها

• نیاز به تنظیم دقیق TTL قفل‌های Redis
• مدیریت همگام‌سازی داده‌ها
• هزینه راه‌اندازی کلاستر ردیس و کافکا (درصورت نیاز)

🎯 جمع‌بندی

ساختن یک سیستم رزرو مقیاس‌پذیر برای یک رویداد پرطرفدار فقط به نوشتن کد قفل محدود نمی‌شود.

باید معماری توزیع‌شده و دقیقی داشته باشیم که شامل:

✅ مدل دقیق State Machine برای مدیریت وضعیت صندلی

✅ قفل توزیع‌شده با Redis برای هماهنگی آنی

✅ کش چندلایه با Write-Through و Batch Persist

💡 نکته مهم برای مهندسین داده

ترکیب هوشمندانه دیتابیس‌ها و ابزارهای مختلف می‌تواند چالش‌های روزانه زیرساخت داده را حل کند، اما باید مراقب نقاط مرزی بود؛ مثلاً هنگام آزاد شدن قفل Redis و همزمانی درخواست‌ها که نیاز به Load Testing را ضروری می‌کند.

راه حل حرفه ای تر
برای بار پردازشی بالا و هماهنگی پیچیده، Actor Model گزینه‌ای مقیاس‌پذیر و قابل‌اعتماد است. در این مدل هر Actor یک واحد مستقل با State و Mailbox خودش است و به‌جای قفل‌ها از پیام‌رسانی استفاده می‌شود، بنابراین مشکلاتی مثل Deadlock و Race Condition عملاً حذف می‌شوند. البته پیاده‌سازی آن کمی پیچیده‌تر است و تیم باید با این الگو آشنا باشد.