یک مهاجرت بزرگ

میخواهم درباره یک مهاجرت بزرگ صحبت کنم. وقتی که با م کارفرمای یکی از پروژه ها تصمیم به بازسازی سرویس گرفتیم.

سرویس مورد نظر یک سرویس ختم گروهی قرآن بود که بیش از 2000 ختم در آن انجام شده بود یعنی چیزی حدود 3 میلیون رکورد ثبت شده برای هر صفحه.

سرویس ابتدا با pure php و بدون فریمورک نوشته شده بود. یک api که با app ارتباط برقرار میکرد و یک ربات تلگرام که مستقیا به دیتابیس وصل میشد!

فاجعه!

قطعاً نمیتوانید همچین چیزی بزنید جز آنکه یک بی تجربه به  تمام معنا باشید.

دیتابیس پروژه mysql بود و کاملاً غیراصولی نوشت شده بود.

یک سری از استانداردهای طراحی پایگاه داده کلا رعایت نشده بود و همیشه مجبور به repair کردن جداول بودیم.

حتی از بی تجربگیم میتونم بگم که یک کران جاب طراحی کرده بودم تا هر دو روز یکبار، یکبار همه جداول رو repair کنه

اما به اینجا ختم نمیشد

هیچکدوم از کلاینت های دیتابیس بسته نمیشدند و عملا به حال خودشون رها شده بودند در نتیجه توی رم سرور با فاجعه رو به رو بودید.

وقتی که رممون رو از 512 به 1 و بعد از 1 به 2 ارتقا دادیم و همچنان بیش از 90 درصد رم مشغول بود ( البته که تعداد کاربرها و سرویس ها هم در حال افزایش بود )

توی پیک شلوغی مخصوصا ماه های رمضون اوضاع کاملا به هم میریخت. عنان کار از دت میرفت . گهگاه موقع سحر با کابوس یا اس ام اس کارفرمام از خواب بیدار میشدم تا مشکل رو حل کنم.

یک بخشی از ربات بود که به کاربرایی که علاقه داشتن یک تایم از روز یک صفحه از قرآن میفرستاد مثل یکجور آلارم.

دم اذان صبح و ساعت 12 شب بیشتر از هزار پیام باید فرستاده میشد. یعنی ما در طول روز به طور معمول دو الی سه ختمهر ختم 604 صفحه ) اشتیم و تو این دو تا زمان به اندازه ترافیکی که تو کل روز پخش میشد ترافیک وجود داشت.

این رو بذارید کنار اون محدودیتی که تلگرام برا ربات ها گذاشته!

هر ثانیه فقط 30 کاربر پیامتو میگیرن !!

و یک مشکل بزرگتر! هیچوقت براش یک پنل طراحی نکرده بودیم. تا حداقل مشکلات ساده تر از طریق پنل حل بشه .

مشکل بعدی این بود که به دلیل های متعدد ارتباط با کاربر ها عملا ممکن نبود و نمیتونستیم یک پیام به همه بفرستیم .

اینطور شد که تصمیم گرفتیم مهاجرت کنیم و قصه این مهاجرت رو براتون تعریف میکنم .