- PostgreSQL
- Observability
- Latency
صدکِ ۹۹ که یک کرانجاب بود
سه هفته، صدکِ ۹۹ یک اندپوینت هر شب ساعت ۰۲:۱۰ به نُه ثانیه میرسید و تا ۰۲:۴۰ خودش برمیگشت. کسی بیدار نبود که ببیند و داشبورد آن را در میانگین گم میکرد. اصلاحش یک کلمه SQL بود؛ یافتهٔ اصلی همان سه هفته بود.
۳ دقیقه مطالعه

هشدار هیچوقت آنقدر بلند نبود که کسی را بیدار کند. یک اندپوینت — همان که اپ موبایل موقع باز شدن صدا میزند — هر شب از صدکِ ۹۹ برابر ۱۸۰ میلیثانیه به حدود نُه ثانیه میرفت و پیش از آنکه کسی در تهران صبحانه بخورد به حالت عادی برمیگشت. سه هفته این کار را کرد.
اشتباه اول
داشبورد داشت آن را در میانگین گم میکرد
پنل تأخیر ما میانگین متحرک یکساعته بود. سی دقیقه پاسخ نُهثانیهای در دل یک روزِ پاسخهای ۱۸۰ میلیثانیهای، میانگین روزانه را چند میلیثانیه جابهجا میکند؛ اما صدکِ ۹۹ را نُه ثانیه جابهجا میکند. صدک تمام این مدت در انبار متریکها بود؛ فقط پنل آن را رسم نمیکرد.
اولین تغییر، رفع اشکال نبود. جای هر میانگین روی آن تخته، صدکهای ۵۰ و ۹۵ و ۹۹ روی یک محور نشست تا وقتی دُم از میانه جدا میشود، بهشکل یک فرم دیده شود، نه عددی که کسی باید با حافظهاش مقایسه کند.
موضوع چه بود
کاری شبانه که قفلی را نگه داشته بود که به آن نیاز نداشت
ساعت ۰۲:۱۰ کاری شبانه یک نمای مادیشده را بازمیساخت؛ همان نمایی که پرسوجوی «باز شدن اپ» از آن میخواند. دستور را بدون CONCURRENTLY اجرا میکرد و REFRESH MATERIALIZED VIEW در آن حالت قفل ACCESS EXCLUSIVE میگیرد — و هر خواندنِ آن نما پشت این قفل صف میبندد. بازسازی حدود نیمساعت طول میکشید، چون نما از روزی که نوشته شده بود چهل برابر شده بود.
آن کار شبانه دو سال قدمت داشت. روزی که نوشته شد درست بود و از روزی که جدولِ پشتش بزرگ شد، بیسروصدا غلط شده بود.
-- پیش از این: قفل ACCESS EXCLUSIVE میگیرد و همهٔ خوانندهها پشتش صف میبندند
REFRESH MATERIALIZED VIEW app_launch_summary;
-- پس از این: خوانندهها همان تصویر قبلی را میگیرند تا تصویر تازه ساخته شود.
-- به یک ایندکس یکتا روی نما نیاز دارد؛ تمام هزینهٔ این اصلاح همین است.
REFRESH MATERIALIZED VIEW CONCURRENTLY app_launch_summary;
۹.۲s
صدک ۹۹ هنگام بازسازی
پیش از تغییر
۱۹۰ms
صدک ۹۹ هنگام بازسازی
پس از تغییر
۲۱
روزی که کسی متوجه نشد
یافتهٔ اصلی
اندازهگیری روی همان اندپوینت و همان پرسوجو، یک هفته پیش و پس از تغییر.
روی هر پنل تأخیر، صدک — هیچوقت میانگین
میانگین نمیتواند دُم را نشان بدهد. این سلیقه نیست؛ کارِ میانگین همین است.
هشدار روی صدک ۹۹ِ ساعت، نه صدک ۹۹ِ روز
پنجرهای که آنقدر پهن باشد که حادثه را صاف کند، پنجرهای است که هیچکس را خبر نمیکند.
هر کار زمانبندیشده، قفلی را که میگیرد در نام یا توضیحش بیاورد
این مستندسازی نیست؛ همان یک خطی است که نفر بعدی ساعت دو نیمهشب و بدون هیچ زمینهای میخواند.
خواندنیهای دیگر

- Vector Search
- Retrieval
بازیابی برداری در محیط عملیاتی: کِی یک پایگاهدادهٔ برداری هزینهاش را جبران میکند
یک پایگاهدادهٔ برداری یک تصمیم معماری است، نه یک ارتقای خودکار برای جستوجو. اگر ندانید دقیقاً چه چیزی از جستوجوی متنی معمولی نمیگیرید، احتمالاً به آن نیاز ندارید.
۸ دقیقه مطالعه
- API Design
- Type Safety
قراردادهای تایپشده بین بکاند و کلاینت: چرا اسکیمای مشترک باگهای یکپارچهسازی را کم میکند
«در Postman که کار میکرد» جملهای است که تقریباً هر تیمی حداقل یکبار گفته و بعدش فهمیده مشکل واقعی جای دیگری بوده. قرارداد تایپشده بین بکاند و کلاینت این کلاس کامل از باگها ر…
۹ دقیقه مطالعه
- Trust
- News Systems
امتیازدهی به اعتبار خبر: طراحی سامانهای که ادعای بیطرفی ندارد
هر برچسب اعتبار، یک تصمیم سردبیری است که در کد نوشته شده — نه یک اندازهگیری. اگر این را از اول نپذیرید، سامانهتان بیطرفیای را وعده میدهد که هرگز نمیتواند تحویل دهد.
۹ دقیقه مطالعه
چیزی برای ساختن دارید؟
بگویید روی چه کار میکنید. صادقانه میگوییم که تیم درستی برایش هستیم یا نه.
یا برای ما ایمیل بزنید به hello@larsima.com
