گزارش فنی — پلتفرم شارژ و تاپ‌آپ موبایل

۱ خلاصه‌ی مدیریتی

پروژه یک پلتفرم پرتراکنش شارژ/تاپ‌آپ موبایل است که به‌عنوان واسط بین شرکت‌های خدمت‌گیرنده و اپراتورها عمل می‌کند. جنس پروژه از نظر منطق کسب‌وکار پیچیده نیست؛ چالش اصلی، مهندسیِ کارایی در مقیاس است: نگه‌داشتن نرخ تراکنش بالا (TPS) و پاسخ‌دهی در حد میلی‌ثانیه، در شرایطی که حجم داده در طول ماه‌ها مدام رشد می‌کند و سیستم باید پایدار، بدون خطا و دارای دسترس‌پذیری بالا (HA) بماند.

پیشنهاد ما یک معماری میکروسرویس، رویداد-محور و کانتینری با بک‌اند Python (FastAPI + asyncio) است که دقیقاً برای همین کلاس از مسائل — تراکنش‌های I/O-bound با هم‌روندی بالا — طراحی می‌شود و با معماری چندلایه‌ی فعلی و بستر Docker که تیم ما در آن تجربه‌ی عملیاتی دارد، کاملاً هم‌راستاست.

۲ درک ما از پروژه

برای اطمینان از هم‌ترازی، برداشت فنی ما از سامانه را خلاصه می‌کنیم:

چرخه‌ی اصلی (یک سیکل تکراری)

شرکت خدمت‌گیرنده درخواست شارژ را با چند پارامتر ارسال می‌کند ← پلتفرم اطلاعات را دریافت و بر اساس قرارداد غنی‌سازی می‌کند ← همان لحظه به اپراتور ارسال می‌شود ← اپراتور فعال‌سازی می‌کند ← تأییدیه به خدمت‌گیرنده بازگردانده می‌شود.

دو نوع سرویس

شارژ آنلاین (Top-Up)آنی و برخط؛ درخواست همان لحظه به اپراتور می‌رود و تأییدیه‌ی زنده برمی‌گردد. مسیر بحرانی و حساس به زمان است.

شارژ پین/کارتی (Serial/PIN)آفلاین از دیتابیس داخلی سرو می‌شود و نیازی به تماس لحظه‌ای با اپراتور ندارد.

نکته‌ی معماری مهم

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

۳ چالش‌های اصلی فنی

۳.۱ — نرخ تراکنش بالا و تأخیر میلی‌ثانیه‌ایمسیر «کاربر نهایی → خدمت‌گیرنده → پلتفرم → اپراتور» باید در کسری از ثانیه کامل شود. هر تراکنش شامل فراخوانی خارجی (اپراتور) و ذاتاً I/O-bound است؛ معماری باید هزاران تراکنش هم‌زمانِ منتظرِ پاسخ را بدون بلوکه‌شدن مدیریت کند.

۳.۲ — افت کارایی با رشد حجم داده (حساس‌ترین نکته)سیستم در روزهای اول عالی کار می‌کند، اما پس از چند ماه انباشت تراکنش، زمان پاسخ خراب می‌شود. ریشه معمولاً در مدل داده، ایندکس‌گذاری و راهبرد ذخیره/بایگانی تراکنش‌هاست.

۳.۳ — دسترس‌پذیری بالا و پایداری تراکنشسامانه مالی/عملیاتی است؛ هر تراکنش گم‌شده یا دوباره‌شمرده مستقیماً پول و اعتماد است. در پیک فروش باید rollback، failover و یکپارچگی داده تضمین شود.

۳.۴ — مدیریت خطای دقیق و قابل‌ردیابیکدهای خطای متعدد (مثلاً کد ۵-) بین پلتفرم و اپراتور رد و بدل می‌شود که هرکدام باید طبق manual تفسیر، هندل و در صورت لزوم retry یا reverse شوند.

۳.۵ — جداسازی چندمستأجری (Multi-Tenancy)هر خدمت‌گیرنده لایه و دیتابیس مستقل دارد. بار یا خطای یک مشتری نباید روی دیگران اثر بگذارد و باید مقیاس‌پذیری مستقل هر مشتری ممکن باشد.

۴ راهکار پیشنهادی — نگاشت چالش به راه‌حل

چالش	راهکار معماری
۳.۱	بک‌اند async (FastAPI/asyncio) برای هم‌روندی بالای I/O + connection pooling به اپراتورها
۳.۲	پارتیشن‌بندی زمانی/بایگانی جداول تراکنش، ایندکس‌گذاری هدفمند، جداسازی مسیر داغ از انبار تحلیلی
۳.۳	الگوی Saga/Outbox، Idempotency Key، صف پیام پایدار، استقرار چندنمونه‌ای پشت Load Balancer
۳.۴	موتور قواعد خطا مبتنی بر manual + سیاست retry/reverse + مشاهده‌پذیری کامل
۳.۵	دیتابیس/اسکیمای مجزا به‌ازای خدمت‌گیرنده + محدودسازی منابع هر مستأجر

اصول معماری کلیدی

معماری رویداد-محور (Event-Driven)مسیر تراکنش به یک خط لوله‌ی پیام تبدیل می‌شود: دریافت → صف → پردازش/تماس با اپراتور → صف نتیجه → تأییدیه. مقاوم در برابر کندی موقت اپراتور، با retry خودکار و مقیاس‌پذیری افقی مستقل هر مرحله.

تضمین یک‌بار-پردازش (Idempotency)هر درخواست با کلید یکتا دنبال می‌شود تا در صورت timeout و retry، تراکنش دوبار روی اپراتور اعمال نشود.

الگوی Outbox / Sagaهماهنگی تراکنش توزیع‌شده بین دیتابیس داخلی و اپراتور خارجی بدون قفل شکننده، با قابلیت جبران در صورت شکست.

جداسازی مسیر داغ از تحلیلیتراکنش‌های زنده روی ذخیره‌ساز سریع، داده‌ی تاریخی به انبار داده منتقل می‌شود تا رشد حجم مسیر بحرانی را کند نکند.

۵ استک فناوری پیشنهادی (بک‌اند Python)

چرا Python مناسب این پروژه است

بار اصلی سیستم I/O-bound است (انتظار برای پاسخ اپراتور، خواندن/نوشتن دیتابیس و کش)، نه CPU-bound. مدل asyncio دقیقاً برای همین ساخته شده: یک worker می‌تواند هزاران تراکنشِ در حال انتظار را هم‌زمان و بدون بلوکه‌شدن مدیریت کند. اکوسیستم بالغ Python نیز توسعه‌ی سریع و قابل‌اتکا را ممکن می‌کند.

FastAPI — فریم‌ورک بک‌اند (ASGI)

غیرهمزمان بومی، سریع، با اعتبارسنجی خودکار (Pydantic) و مستندسازی OpenAPI. اجرا با Uvicorn + Gunicorn چندworker.

Kafka / RabbitMQ — صف پیام

ستون فقرات معماری رویداد-محور؛ بافر تراکنش‌ها، retry و جداسازی مراحل. Kafka برای throughput بالا و بازپخش، RabbitMQ برای مسیریابی ساده‌تر.

Redis — کش و ذخیره‌ساز سریع

شارژ پین آفلاین، کلیدهای idempotency، نگه‌داری بسته‌های اپراتور و کش داده‌های داغ برای کاهش فشار دیتابیس.

PostgreSQL — دیتابیس چندلایه

پایدار و تراکنش‌محور، با پشتیبانی عالی از پارتیشن‌بندی و ایندکس — کلید حل چالش رشد داده. اسکیما مجزا به‌ازای هر خدمت‌گیرنده.

Celery / Workerهای async — پردازش پس‌زمینه

retry، مغایرت‌گیری (reconciliation) و تسویه.

Docker + Kubernetes — کانتینر و ارکستراسیون

مقیاس‌پذیری خودکار، self-healing و استقرار بدون قطعی برای تضمین HA — هم‌راستا با تجربه‌ی Docker تیم ما.

Prometheus + Grafana + OpenTelemetry — مشاهده‌پذیری

پایش زنده‌ی TPS، تأخیر (p95/p99) و نرخ خطا تا افت کارایی پیش از بحران دیده شود.

Locust — تست بار (بومی Python)

شبیه‌سازی پیک واقعی و تولید داده‌ی حجیم برای اثبات پایداری زیر بار پیش از استقرار.

نمای کلی جریان یک تراکنش

Client ──> API Gateway ──> FastAPI (async)
                              |
                              |- validate + detect operator (Redis)
                              |- idempotency check
                              v
                         Kafka (request queue)
                              v
                     Transaction Worker (async)
                              |- call operator (pool + timeout + retry)
                              |- persist to PostgreSQL (Outbox)
                              v
                         Kafka (result queue)
                              v
                     return confirmation to Client

۶ رویکرد اجرا و همکاری

گام ۰ — بازبینی و هم‌ترازی. دریافت سورس و مستندات پروژه‌ی فعلی و بررسی معماری موجود. تصمیم آگاهانه درباره‌ی «ادامه‌ی کد موجود» در برابر «بازنویسی هدفمند»؛ حفظ منطق سالم، و بازنویسی لایه‌به‌لایه در صورت لزوم با استفاده از کد قبلی به‌عنوان مرجع دامنه.
گام ۱ — پایلوت. شروع با یک دامنه‌ی کوچک و کنترل‌شده (یک اپراتور/یک خدمت‌گیرنده) برای اثبات معماری و گرفتن تأییدیه‌ی اولیه.
گام ۲ — توسعه‌ی ایتریشنی. پیشبرد در قالب اسپرینت با جلسات دوره‌ای، تحویل گام‌به‌گام و اعتبارسنجی مستمر با کارفرما.
گام ۳ — گسترش و سخت‌سازی. افزودن خدمت‌گیرنده‌ها/اپراتورها، تست بار سنگین، تنظیم HA و failover و آماده‌سازی برای مقیاس کامل عملیاتی.

۷ چرا تیم ما

شرکت ما سابقه‌ی ساخت و اجرای عملیاتی سیستم‌های نرم‌افزاری جدی را دارد:

CRM اختصاصیتجربه‌ی طراحی سیستم‌های داده‌محور با منطق کسب‌وکار پیچیده، مدیریت داده و کاربران متعدد.

سایت‌ساز (Site Builder)محصولی چندمستأجری و مقیاس‌پذیر — دقیقاً همان الگوی «هر مشتری، فضای مستقل خود» که در این پروژه محوری است.

بستر Dockerاستقرار کانتینری در محیط عملیاتی، پایه‌ی مستقیم معماری کانتینری/Kubernetes پیشنهادی برای این پروژه.

این سوابق نشان می‌دهد تیم ما هم در منطق کسب‌وکار و هم در زیرساخت مقیاس‌پذیر و کانتینری توانمندی عملی دارد و آماده‌ی انجام پروژه‌ای در این کلاس است.