databases کی billing ان کے اصل استعمال کے مطابق

ہر Mythex ایپ جسے ڈیٹا محفوظ کرنا ہو اسے اپنا Postgres database ملتا ہے، اور پبلش شدہ ایپ کے database کا استعمال اسی credit balance سے کٹتا ہے جس سے build ہوتا ہے۔ ستمبر کے آخر تک ہم اس استعمال کا اندازہ اس سے لگاتے تھے کہ ایپ کا سرور کتنی دیر چلا۔ وہ اندازہ ایک ایسے طریقے سے غلط نکلا جو اہم تھا، تو ہم نے اسے بدل دیا: اب ہر database اس compute پر billed ہوتا ہے جو اس کے provider نے واقعی ناپا، ایک مکمل گھنٹے کے حساب سے، اور ہر گھنٹے کی قیمت صرف ایک بار لی جا سکتی ہے۔

databases کیسے کام کرتے ہیں

ہر database serverless Postgres پر چلتا ہے جو صفر تک scale ہوتا ہے: چند منٹ بیکار رہنے کے بعد یہ سو جاتا ہے، اور اگلی query پر جاگ جاتا ہے۔ جاگتے ہوئے یہ لوڈ کے ساتھ اپنی compute کو بڑھا یا گھٹا سکتا ہے۔ اسی سے "ہر ایپ کا ایک database" قابلِ برداشت ہوتا ہے، کیونکہ زیادہ تر ایپس زیادہ تر وقت خاموش رہتی ہیں، اور سوتا ہوا database تقریباً کچھ خرچ نہیں کرتا۔

اس کا مطلب یہ بھی ہے کہ database کی لاگت دو چیزوں پر منحصر ہے جو باہر سے نظر نہیں آتیں: وہ کتنی دیر جاگتا رہا اور جاگتے وقت کتنا بڑا تھا۔

اندازہ کہاں غلط تھا

ہمارے ابتدائی meter میں ایک مفروضہ تھا: پبلش شدہ ایپ کے سرور کے ہر چلنے والے گھنٹے کے لیے، database کو سب سے چھوٹے compute سائز پر چارج کرنا۔

یہ تین طرح سے غلط تھا:

1. سائز غلط تھا۔ databases اصل میں اندازے سے بڑے ڈیفالٹ سائز پر چل رہے تھے۔
2. Databases خود scale ہوتے ہیں۔ لوڈ کے تحت وہ بڑھتے ہیں، اور اندازہ اسے کبھی نہیں دیکھ سکتا تھا۔
3. Databases ایپ کے سرور کے ساتھ نہیں سوتے۔ database جاگتا رہتا ہے جب بھی کچھ بھی اس سے query کرے، ایپ، کوئی scheduled job، یا کوئی script جو اسے poll کرے، چاہے ایپ کا سرور چل رہا ہو یا نہیں۔

خالص نتیجہ: اندازے نے صارفین سے تقریباً آدھی لاگت لی جو databases واقعی خرچ کر رہے تھے۔ یہ ہمارے لیے پائیدار نہیں تھا، اور اس کا مطلب یہ بھی تھا کہ ایپ میں دکھائے گئے استعمال کے اعداد وہ نہیں تھے جو لوگ سمجھتے تھے۔

اندازہ لگانے کے بجائے ناپنا

ہمارا database provider ہر پروجیکٹ کے compute-unit-seconds فی گھنٹہ رپورٹ کرتا ہے، یعنی اس نے واقعی کتنی compute استعمال کی، سائز سمیت۔ تو اب meter اس طرح کام کرتا ہے:

1. ہر database والی پبلش شدہ ایپ کے لیے، لائیو ہونے کے بعد سے ہر مکمل ہونے والے گھنٹے کا ناپا ہوا استعمال حاصل کریں۔
2. اس استعمال کو provider کی قیمت پر لاگت میں بدلیں، plan کی شرح لگائیں، اور ایپ کے مالک کے credits سے کاٹیں۔
3. ہر بار زیادہ سے زیادہ ایک دن پیچھے دیکھیں، تاکہ وہ گھنٹے جو ہماری API کے restart کے دوران چھوٹ گئے، بعد میں بل ہو جائیں۔

Storage الگ سے، اس کے سائز کے حساب سے بل ہوتا ہے، کیونکہ وہ استعمال پر منحصر نہیں۔

ایک گھنٹے کی قیمت دوبارہ کبھی نہ لینا

ایک billing meter جو ایک سے زیادہ سرورز پر چلے اور crash ہو کر دوبارہ کوشش کر سکے، اسے دوگنا چارج کرنے سے بچنا ہوتا ہے۔ ہر database کا ہر گھنٹہ چارج ہونے سے پہلے اپنی ہی database row میں claim ہوتا ہے، جس کے جوڑے (database، گھنٹہ) پر uniqueness constraint ہے۔ اگر دو سرورز، یا ایک retry، ایک ہی گھنٹہ بل کرنے کی کوشش کریں، تو صرف ایک claim کامیاب ہوتا ہے۔

ہم نے نادر ناکامی کے کیس کے لیے ایک جان بوجھ کر فیصلہ کیا: اگر process گھنٹے کو claim کرنے اور اسے چارج کرنے کے درمیان میں crash ہو جائے، تو وہ گھنٹہ claimed لیکن غیر بل شدہ رہتا ہے۔ نادر crash میں آمدنی کا تھوڑا سا حصہ کھونا، کسی سے دو بار پیسے لینے سے بہتر ہے۔

اور جب ناپی ہوئی billing آن ہوئی، تو وہ اگلے مکمل گھنٹے سے شروع ہوئی۔ اس سے پہلے کے گھنٹے پرانے اندازے سے پہلے ہی چارج ہو چکے تھے؛ انہیں ناپے ہوئے ڈیٹا سے دوبارہ بل کرنے سے وہ حصہ دو بار چارج ہو جاتا۔

اگر آپ Mythex پر بناتے ہیں تو اس کا مطلب

• آپ کا database کا بل اس کی اصل کارکردگی دکھاتا ہے۔ کم استعمال ہونے والی ایپ بہت کم خرچ کرتی ہے؛ جو ایپ اپنے database سے مسلسل query کرتی ہے وہ اسے جاگتا رکھتی ہے اور زیادہ خرچ ہوتا ہے۔
• سب سے بڑا leverage اس میں ہے کہ آپ کی ایپ database کو کیسے استعمال کرتی ہے۔ ہر چند سیکنڈ بعد database کو poll کرنا اسے ہر وقت جگائے رکھتا ہے۔ جب AI سے ڈیٹا کو ضرورت پر منگوایا جائے، یا اسے cache کیا جائے، تو database سو سکتا ہے۔ ہمارا database کیا ہوتا ہے کا guide بنیادی باتیں بتاتا ہے۔
• Pro پلانز hosting، databases اور storage کے لیے Free کی شرح کا آدھا ادا کرتے ہیں۔ تفصیلات credits docs میں ہیں۔

ہم نے اس سے کیا سیکھا

• استعمال پر مبنی لاگت کے اندازے وقت کے ساتھ غلط ہو جاتے ہیں۔ جب upstream provider بتا سکے کہ کیا استعمال ہوا، تو اسی سے بل کریں۔
• Billing کو سب سے چھوٹی اکائی پر idempotent بنائیں جس پر آپ چارج کرتے ہیں۔ ہمارے لیے وہ ایک database-گھنٹہ ہے۔
• جب ناکام ہونا ہی ہو، تو گاہک کے حق میں ناکام ہوں۔