مقاله‌های رسمی

قضیه‌ی CAP: چرا هیچ دیتابیس توزیع‌شده‌ای نمی‌تونه همه‌چیز رو با هم داشته باشه

یه بار که داری بین چند تا دیتابیس توزیع‌شده (مثل Cassandra، MongoDB، یا CockroachDB) یکی رو انتخاب می‌کنی، دیر یا زود به یه جمله می‌رسی که همه جا تکرار می‌شه: «این دیتابیس CP هست» یا «اون یکی AP هست». اگه پشت این حرف‌ها ندونی چه مصالحه‌ای واقعاً داره اتفاق می‌افته، خیلی راحت ممکنه دیتابیسی رو انتخاب کنی که دقیقاً برعکس چیزیه که سیستمت بهش نیاز داره.

سه ضلع قضیه

قضیه‌ی CAP (که اریک برور اولین بار مطرحش کرد) می‌گه یه سیستم دیتابیس توزیع‌شده، وقتی network partition اتفاق می‌افته (یعنی ارتباط بین بخشی از node ها قطع می‌شه)، فقط می‌تونه یکی از این دو تا رو تضمین کنه، نه هر دو رو با هم:

Consistency: هر خواندنی، آخرین نوشته‌ی موفق رو برمی‌گردونه. یعنی همه‌ی node ها همیشه یه نسخه‌ی یکسان و به‌روز از داده رو نشون می‌دن.

Availability: هر درخواستی (چه خواندن، چه نوشتن) یه جواب دریافت می‌کنه، حتی اگه بعضی node ها از کار افتاده باشن. سیستم هیچ‌وقت با یه خطا جواب رد نمی‌ده.

ضلع سومِ قضیه، Partition tolerance است: توانایی سیستم برای ادامه‌ی کار حتی وقتی شبکه بین node ها قطع می‌شه. نکته‌ی مهم اینجاست که partition tolerance تو دنیای واقعی یه انتخاب نیست؛ شبکه دیر یا زود قطع می‌شه، پس هر سیستم توزیع‌شده‌ی واقعی باید partition tolerant باشه. این یعنی انتخاب واقعی همیشه بین C و A است، نه بین سه‌تا گزینه.

یعنی چی وقتی partition اتفاق می‌افته؟

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

اگه سیستم انتخاب کنه Consistency رو حفظ کنه (CP)، node یک باید درخواست رو رد کنه یا صبر کنه، چون نمی‌تونه مطمئن بشه node های دیگه هم همین مقدار رو دارن. کاربر یه خطا می‌گیره، ولی داده هیچ‌وقت inconsistent نمی‌شه.

اگه سیستم انتخاب کنه Availability رو حفظ کنه (AP)، node یک همون لحظه به کاربر جواب می‌ده و نوشتن رو قبول می‌کنه، حتی اگه ندونه node های دیگه چه مقداری دارن. بعداً وقتی partition برطرف شد، سیستم باید یه مکانیزم برای reconcile کردن این تناقض‌ها داشته باشه (مثلاً last-write-wins یا vector clocks).

چند تا مثال واقعی

MongoDB به‌صورت پیش‌فرض بیشتر به سمت CP گرایش داره؛ وقتی primary node در دسترس نباشه یا اکثریت replica ها قابل‌دسترس نباشن، نوشتن‌ها متوقف می‌شن تا consistency حفظ بشه.

Cassandra طراحی‌ش از پایه AP-محور بوده؛ همیشه به درخواست‌ها جواب می‌ده، حتی اگه بعضی replica ها هنوز به‌روز نشده باشن، و از مدل eventual consistency استفاده می‌کنه.

CockroachDB و Google Spanner سعی می‌کنن با استفاده از الگوریتم‌های consensus مثل Raft یا Paxos، در اکثر شرایط هر دو رو تا حد ممکن نزدیک هم نگه دارن، ولی باز هم زیر پوستشون، وقتی واقعاً partition جدی اتفاق بیفته، اولویت رو به consistency می‌دن.

چرا این مدل ساده‌شده هم کامل نیست

یه نقد رایج به CAP اینه که این مدل بیش‌ازحد ساده‌ست، چون partition ها همیشه یا کامل هستن یا اصلاً نیستن، در حالی که تو دنیای واقعی شبکه معمولاً به‌جای قطع کامل، فقط کند می‌شه یا packet loss داره. برای همین، یه فریم‌ورک تکمیلی به اسم PACELC مطرح شده که می‌گه: در حالت Partition، بین Availability و Consistency انتخاب کن (همون CAP)، ولی حتی وقتی partition نداری (Else)، بین Latency و Consistency هم باید یه مصالحه انجام بدی. یعنی حتی تو حالت عادی شبکه، دیتابیس‌هایی مثل Cassandra ترجیح می‌دن latency پایین‌تری بدن به قیمت consistency ضعیف‌تر، در حالی که چیزی مثل Spanner حاضره latency بیشتری رو تحمل کنه تا consistency قوی‌تری داشته باشه.

این یعنی چی برای انتخاب دیتابیس

وقتی داری معماری یه سیستم رو طراحی می‌کنی، سؤال درست این نیست که «کدوم دیتابیس بهتره؟»، بلکه اینه که «سیستمم چه چیزی رو نمی‌تونه تحمل کنه؟» برای یه سیستم بانکی که موجودی حساب رو مدیریت می‌کنه، نشون دادن یه مقدار قدیمی یا اشتباه فاجعه‌باره؛ پس CP منطقی‌تره، حتی اگه یعنی بعضی وقت‌ها کاربر با تأخیر مواجه بشه. ولی برای چیزی مثل تعداد لایک یه پست تو شبکه‌ی اجتماعی، اگه چند ثانیه یه عدد قدیمی‌تر نشون داده بشه هیچ فاجعه‌ای اتفاق نمی‌افته، ولی اگه کل سایت پایین بیاد چون یه node قطع شده، تجربه‌ی کاربری خیلی بدتری رقم می‌خوره. اینجا AP انتخاب درست‌تریه.

نکته‌ی آخر این‌که CAP فقط درباره‌ی رفتار سیستم زیر partition حرف می‌زنه، نه درباره‌ی performance عمومی یا مقیاس‌پذیری. یه دیتابیس می‌تونه CP باشه و همچنان خیلی سریع و مقیاس‌پذیر باشه؛ این دو مفهوم کاملاً مستقل از هم هستن و نباید با هم قاطی بشن.

Message Queue چیه و چرا هر برنامه‌نویسی باید باهاش آشنا باشه

یه سناریوی خیلی رایج رو تصور کن: کاربر روی دکمه «ثبت‌نام» کلیک می‌کنه، سرور باید یوزر رو تو دیتابیس بسازه، یه ایمیل خوش‌آمدگویی بفرسته، یه گزارش برای تیم مارکتینگ بسازه و شاید یه پیامک هم بده. اگه همه‌ی این کارها رو تو همون request-response انجام بدی، کاربر باید چند ثانیه منتظر بمونه تا SMTP جواب بده، و اگه سرویس ایمیل یه لحظه کند بشه یا قطع بشه، کل ثبت‌نام fail می‌شه. این دقیقاً جایی است که message queue وارد بازی می‌شه.

ایده‌ی اصلی چیه

به زبان ساده، message queue یه واسطه است بین بخشی از سیستم که کار رو تولید می‌کنه (producer) و بخشی که اون کار رو انجام می‌ده (consumer). به‌جای اینکه producer مستقیم consumer رو صدا بزنه و منتظر جواب بمونه، یه پیام رو تو صف می‌ذاره و می‌ره سراغ کار بعدی. consumer هر وقت آماده بود، پیام رو از صف برمی‌داره و پردازش می‌کنه.

این جدایی زمانی (decoupling) دقیقاً همون چیزی است که مشکل بالا رو حل می‌کنه. سرور فقط یه پیام کوچیک می‌فرسته به صف با مضمون «این یوزر ثبت‌نام کرد، کارهای بعدیش رو انجام بده» و بلافاصله به کاربر جواب می‌ده. یه worker جدا، پشت صحنه، ایمیل و پیامک و گزارش رو مدیریت می‌کنه. اگه سرویس ایمیل قطع باشه، پیام تو صف می‌مونه تا وقتی که سرویس برگرده.

چرا فقط یه تابع async کافی نیست

اینجا سؤال منطقی پیش میاد: چرا از یه thread pool یا background job ساده تو خود اپلیکیشن استفاده نکنیم؟ جواب اینه که queue واقعی چند تا امتیاز اضافه می‌ده که یه goroutine یا thread ساده نداره:

پایداری (durability): اگه سرور کرش کنه، پیام‌هایی که تو حافظه‌ی یه thread pool بودن از بین می‌رن. ولی پیام‌هایی که تو RabbitMQ یا Kafka نوشته شدن، روی دیسک persist می‌شن و بعد از ریستارت هم سر جاشون هستن.

مقیاس‌پذیری مستقل: می‌تونی producer و consumer رو کاملاً جدا از هم scale کنی. اگه صف پر شد، فقط تعداد worker ها رو زیاد می‌کنی، بدون اینکه به API لایه دست بزنی.

retry و backoff: اکثر broker ها مکانیزم retry دارن. اگه consumer یه لحظه fail بشه (مثلاً دیتابیس موقتاً در دسترس نبود)، پیام دوباره به صف برمی‌گرده و بعد از چند ثانیه دوباره تلاش می‌شه، بدون اینکه خودت این منطق رو از صفر بنویسی.

چند تا الگوی رایج

Rate Limiting: چرا هر API باید یک سقف مصرف داشته باشه

فرض کن یک endpoint ساده داری که لیست محصولات رو برمیگردونه. یک روز متوجه میشی سرورت زیر فشار عجیبی رفته، درحالی‌که تعداد کاربر واقعی زیاد نشده. وقتی لاگ‌ها رو نگاه میکنی، میبینی یک IP تنها، چند هزار درخواست در ثانیه فرستاده — یا یک اسکریپت خرابه، یا یک نفر داره عمداً داده‌هات رو میخراشه (scrape میکنه)، یا حتی داره تلاش میکنه با حجم درخواست سرویس رو از کار بندازه. rate limiting دقیقاً همون لایه‌ایه که جلوی این سناریو رو میگیره: تعیین میکنه هر کلاینت (بر اساس IP، کاربر، یا API key) توی یک بازه‌ی زمانی مشخص، حداکثر چند درخواست میتونه بفرسته.

چرا واقعاً مهمه

اولین و واضح‌ترین دلیل، محافظت از منابع سرور در برابر سوءاستفاده یا حملات است. حملات denial-of-service (چه عمدی چه ناشی از یک باگ توی کلاینت که وارد یک حلقه‌ی بی‌نهایت از درخواست شده) میتونن یک سرویس سالم رو در عرض چند ثانیه از پا دربیارن. rate limiting یک سقف مشخص میذاره که جلوی این نوع فشار رو میگیره، قبل از این‌که به لایه‌های عمیق‌تر سیستم (مثل دیتابیس) برسه.

دومی، توزیع عادلانه‌ی منابع بین کاربرهاست. اگه یک API عمومی داری که چند هزار کلاینت مختلف ازش استفاده میکنن، بدون rate limiting هیچ تضمینی نیست که یک کلاینت پرمصرف، کل ظرفیت سرور رو برای بقیه اشغال نکنه. با یک سقف مشخص برای هر کلاینت، مطمئن میشی هیچ‌کس نمیتونه سهم بقیه رو بخوره.

سومی، کنترل هزینه است، مخصوصاً وقتی endpoint پشت سرش یک سرویس گرون‌قیمت باشه — مثلاً یک API که هر درخواستش یک فراخوانی به یک مدل هوش مصنوعی یا یک سرویس ثالث پولی میفرسته. بدون سقف، یک باگ ساده توی کد کلاینت (مثلاً یک حلقه‌ی retry بی‌پایان) میتونه صورت‌حساب رو در عرض چند ساعت نجومی کنه.

چهارمی، جلوگیری از brute-force. روی endpoint هایی مثل لاگین، rate limiting جلوی این رو میگیره که یک مهاجم بتونه با امتحان‌کردن هزاران رمز عبور در ثانیه، حساب کاربری رو بشکنه.

الگوریتم‌های رایج rate limiting

چند روش استاندارد برای پیاده‌سازی rate limiting وجود داره، و هرکدوم trade-off متفاوتی دارن.

Fixed Window

ساده‌ترین روش: یک بازه‌ی زمانی ثابت (مثلاً هر دقیقه) در نظر میگیری و میشماری چند درخواست توش اومده. اگه از سقف رد بشه، بقیه رد میشن تا شروع بازه‌ی بعدی.

cuid و cuid2: چرا نسخه‌ی دوم عملاً از صفر بازنویسی شد

وقتی میخوای برای رکوردهای دیتابیست یک شناسه‌ی یکتا بسازی، احتمالاً اول به auto increment فکر میکنی، بعد به UUID، و اگه دنبال چیزی سبک‌تر و url-friendly تر باشی، به cuid میرسی. ولی نکته‌ای که خیلی وقت‌ها گم میشه اینه که cuid و cuid2 دو چیز کاملاً متفاوتن — نه یک آپدیت جزئی، بلکه یک بازطراحی کامل با فرض‌های امنیتی متفاوت.

cuid اصلی چی بود

cuid (نسخه‌ی اول) حدود سال ۲۰۱۲ ساخته شد تا یک جایگزین برای auto-increment ID و UUID باشه که هم یکتا باشه، هم قابل مرتب‌سازی بر اساس زمان تولید (chronologically sortable)، و هم برای استفاده توی URL راحت‌تر از UUID باشه (چون کوتاه‌تره و کاراکترهای عجیب مثل خط‌تیره‌ی اجباری UUID رو نداره).

ساختار یک cuid از چند بخش تشکیل شده: یک پیشوند ثابت (c)، timestamp، یک شمارنده (counter)، اطلاعاتی از fingerprint ماشین و پردازش (که شامل چیزهایی مثل هاست‌نیم و شناسه‌ی پردازش میشد)، و یک بخش تصادفی. مثال یک cuid واقعی این شکلیه:

cljk3f2j40000qzrmn831i7rn

چرا cuid کنار گذاشته شد

مشکل اصلی cuid وقتی خودش رو نشون داد که مسائل امنیتی جدی‌تری مطرح شد. چون بخشی از cuid از fingerprint ماشین (host/process info) و timestamp قابل پیش‌بینی ساخته میشه، این یعنی تا حدی میشه از روی خود ID، اطلاعاتی درباره‌ی زیرساخت سرور یا ترتیب دقیق تولید رکوردها استنباط کرد. علاوه بر این، چون بخش زمانی cuid قابل پیش‌بینیه، در برخی سناریوها میشه با حدس زدن IDها، رکوردهای مجاور رو enumerate کرد — دقیقاً همون چیزی که یک شناسه‌ی یکتا نباید اجازه بده.

مشکل دیگه، performance بود: تولید fingerprint ماشین و بعضی محاسبات cuid اصلی روی برخی محیط‌ها (مخصوصاً serverless که هر بار یک instance جدید بالا میاد) کند و ناسازگار عمل میکرد.

cuid2 چطور این مشکلات رو حل کرد

cuid2 عملاً یک طراحی از نو بود، نه یک پچ روی نسخه‌ی قبلی. تفاوت‌های اصلیش این‌هاست:

اول، امنیت رمزنگاری. cuid2 به‌جای تکیه به fingerprint قابل‌پیش‌بینی ماشین، از یک تابع هش امن (SHA3) روی ترکیبی از entropy تصادفی، timestamp، counter، و یک مقدار fingerprint ضعیف‌تر و کم‌اهمیت‌تر استفاده میکنه. نتیجه‌ی نهایی یک رشته‌ست که از نظر آماری غیرقابل‌پیش‌بینیه — یعنی حتی اگه بدونی الگوریتم چطور کار میکنه، نمیتونی ID بعدی رو حدس بزنی یا از روی یک ID موجود، ID های مجاورش رو enumerate کنی.

Elasticsearch: قدرتمند، سنگین، و نه همیشه انتخاب درست

خیلی وقت‌ها یک پروژه فقط به یک جستجوی ساده نیاز داره — کاربر یک کلمه تایپ میکنه و باید سریع نتیجه ببینه. اولین گزینه‌ای که معمولاً به ذهن میاد Elasticsearch است، چون اسمش همه‌جا هست و مستنداتش زیاده. ولی قبل از این‌که سراغش بری، ارزش داره بدونی این ابزار برای چه مقیاسی ساخته شده، چقدر منابع میخواد، و کِی یک جایگزین سبک‌تر تصمیم بهتریه.

Elasticsearch واقعاً چیه

Elasticsearch یک موتور جستجو و آنالیز توزیع‌شده‌ست که روی Apache Lucene ساخته شده. کارش فقط «پیدا کردن یک رشته توی متن» نیست؛ یک سیستم کامله برای indexing متن با امتیازدهی relevance، فیلتر کردن روی فیلدهای ساختاریافته، اجرای aggregation های پیچیده (مثل «میانگین قیمت به تفکیک دسته‌بندی»)، و مقیاس‌پذیری روی چند نود همزمان. برای همینه که توی سیستم‌های لاگ‌مانیتورینگ (مثل استک ELK)، جستجوی محصولات فروشگاه‌های بزرگ، و تحلیل داده‌ی حجیم این‌قدر رایجه.

چرا سنگین حساب میشه

مشکل اصلی Elasticsearch این نیست که کند باشه؛ مشکل اینه که برای اجرا شدن، منابع قابل توجهی میخواد. چون روی JVM (جاوا) اجرا میشه، حداقل نیاز به چند صد مگابایت تا چند گیگابایت heap memory داره، حتی برای یک نود توسعه‌ای کوچیک. توصیه‌ی رسمی برای یک نود production معمولاً از ۲ تا ۴ گیگابایت رم شروع میشه و برای دیتاست‌های بزرگ‌تر به‌سرعت بالا میره. علاوه بر این، Elasticsearch برای کار درست نیازمند تنظیمات سیستم‌عاملیه (مثل افزایش vm.max_map_count روی لینوکس)، و راه‌اندازی یک کلاستر واقعی (با نودهای master و data جدا) خودش یک پروژه‌ی مجزاست، نه یک نصب پنج‌دقیقه‌ای.

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

Meilisearch و رقبای سبک‌تر

Meilisearch یک موتور جستجوی متن‌باز است که با Rust نوشته شده و از ابتدا برای سادگی و سرعت راه‌اندازی طراحی شده، نه برای مقیاس عظیم. تفاوتش با Elasticsearch از همون لحظه‌ی نصب معلومه: یک باینری تک‌فایلی که بدون JVM، بدون تنظیمات پیچیده، و با مصرف رم بسیار پایین‌تر (معمولاً چند ده مگابایت برای دیتاست‌های متوسط) اجرا میشه. جستجوش هم به‌صورت پیش‌فرض typo-tolerant است — یعنی حتی اگه کاربر کلمه رو غلط تایپ کنه، نتیجه‌ی درست رو پیدا میکنه — بدون این‌که نیاز به تنظیم دستی داشته باشه.

ریپلیکیشن دیتابیس: یک کپی زنده از داده ها، همیشه آماده

فرض کن سرور دیتابیس اصلی یک پروژه، به هر دلیلی — خرابی سخت‌افزار، آپدیت نادرست، قطعی برق دیتاسنتر — از دسترس خارج بشه. اگه فقط یک نسخه از داده‌ات جایی وجود داشته باشه، این یعنی کل سرویس تا وقتی اون سرور برنگرده، از کار می‌افته. ریپلیکیشن دقیقاً برای جلوگیری از همین سناریو ساخته شده: به‌جای نگه‌داشتن داده روی یک سرور تنها، یک یا چند کپی زنده و همیشه به‌روز از همون داده رو روی سرورهای دیگه نگه میداری.

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

چرا ریپلیکیشن میخوایم

دو دلیل اصلی برای ریپلیکیشن وجود داره، و هر کدوم مسئله‌ی متفاوتی رو حل میکنن.

اول، دسترس‌پذیری بالا (high availability). اگه سرور اصلی (که بهش primary یا master میگن) از کار بیفته، یکی از replica ها میتونه جاش رو بگیره و نقش primary جدید رو بازی کنه، بدون این‌که سرویس کامل قطع بشه. به این فرآیند failover میگن.

دوم، توزیع بار خواندن. توی خیلی از اپلیکیشن‌ها، تعداد خواندن (SELECT) خیلی بیشتر از نوشتن (INSERT/UPDATE) است. اگه همه‌ی این خواندن‌ها روی همون یک سرور primary انجام بشه، اون سرور زیر فشار میمونه. با ریپلیکیشن میتونی خواندن‌ها رو بین چند replica پخش کنی و فقط نوشتن‌ها رو روی primary نگه داری — الگویی که بهش read/write splitting میگن.

چطور داده از primary به replica میرسه

مکانیزم رایج این است که primary هر تغییری که روی داده‌اش اعمال میشه رو توی یک لاگ ترتیبی ثبت میکنه — توی PostgreSQL بهش WAL (Write-Ahead Log) میگن، توی MySQL بهش binlog. هر replica این لاگ رو از primary میخونه و همون تغییرات رو دقیقاً به همون ترتیب روی نسخه‌ی خودش اعمال میکنه. یعنی replica عملاً داره یک تاریخچه‌ی کامل از هر اتفاقی که روی primary افتاده رو دنبال میکنه و بازش تولید میکنه.

sync در مقابل async: معامله‌ای که باید آگاهانه انتخابش کنی

اینجا یکی از مهم‌ترین تصمیم‌های طراحی توی ریپلیکیشن پیش میاد: وقتی یک نوشتن روی primary اتفاق می‌افته، آیا باید صبر کنه تا replica هم همون نوشتن رو تأیید کنه، یا میتونه بدون منتظر موندن به کلاینت جواب «موفق» بده؟

شاردینگ دیتابیس: وقتی یک سرور دیگه جایی برای داده نداره

ایندکس و کش و replica خواندنی، همه تا یک جایی جواب میدن. اگه حجم داده‌ات آنقدر بزرگ بشه که حتی قوی‌ترین سرور دیتابیس هم دیگه جا نداشته باشه نگهش داره، یا نرخ نوشتن آنقدر بالا بره که یک سرور تنها نتونه جوابگو باشه، اون‌وقت با یک مسئله‌ی متفاوت روبه‌رو میشی. ایندکس کمکت میکنه سریع‌تر پیدا کنی، replica کمکت میکنه بار خواندن رو پخش کنی، ولی هیچ‌کدوم مشکل «داده آنقدر زیاده که روی یک ماشین جا نمیشه» رو حل نمیکنن. شاردینگ دقیقاً برای همین مسئله ساخته شده.

شاردینگ یعنی چی

شاردینگ یعنی داده‌ی یک جدول بزرگ رو به چند بخش (shard) تقسیم کنی و هر بخش رو روی یک سرور جدا نگه داری. برخلاف replication که هر سرور یک کپی کامل از کل داده رو داره، توی شاردینگ هر سرور فقط بخشی از داده رو داره. مثلاً اگه یک جدول کاربر با ۱۰۰ میلیون ردیف داری، میتونی کاربرهای با ID زوج رو روی یک سرور بذاری و کاربرهای با ID فرد رو روی سرور دیگه. حالا هر سرور فقط نصف داده رو مدیریت میکنه، و هم فضا و هم بار پردازشی بین دو ماشین تقسیم شده.

نکته‌ی مهم اینه که شاردینگ و replication دو مسئله‌ی متفاوت رو حل میکنن و معمولاً با هم ترکیب میشن: هر شارد خودش میتونه چند replica داشته باشه برای availability، و همزمان داده هم بین شاردهای مختلف تقسیم شده برای مقیاس‌پذیری.

چطور تصمیم بگیریم کدوم رکورد بره کدوم شارد

قلب هر سیستم شاردینگ، یک چیز به اسم shard key یا partition key است — ستونی که تعیین میکنه هر ردیف روی کدوم شارد قرار بگیره. چند استراتژی رایج برای این تصمیم وجود داره.

اولین و ساده‌ترین، range-based sharding است: بازه‌های مقدار رو بین شاردها تقسیم میکنی، مثلاً کاربرهایی با ID بین ۱ تا ۱ میلیون روی شارد اول، بین ۱ تا ۲ میلیون روی شارد دوم. مزیتش اینه که query هایی که روی یک بازه کار میکنن (مثل «همه‌ی سفارش‌های هفته‌ی گذشته») ممکنه فقط به یک شارد نیاز داشته باشن. مشکلش اینه که اگه داده به‌طور نامتوازن رشد کنه (مثلاً کاربرهای جدید همیشه ID بزرگ‌تر میگیرن)، شارد آخر همیشه شلوغ‌تر از بقیه میشه — به این پدیده hot shard میگن.

دومی hash-based sharding است: روی مقدار shard key یک تابع هش اجرا میکنی و نتیجه تعیین میکنه کدوم شارد. این روش توزیع خیلی یکنواخت‌تری میده و مشکل hot shard رو تا حد زیادی حل میکنه، ولی query هایی که روی بازه کار میکنن رو سخت‌تر میکنه، چون داده‌ی مرتبط ممکنه پخش بشه روی همه‌ی شاردها.

ایندکس دیتابیس: چرا یک کوئری ساده گاهی چند ثانیه طول میکشه

فرض کن یک جدول داری با یک میلیون ردیف، و میخوای کاربری با یک ایمیل مشخص رو پیدا کنی. بدون هیچ کمکی، دیتابیس مجبوره ردیف به ردیف کل جدول رو بگرده تا برسه به همونی که دنبالشی — به این کار میگن full table scan. روی یک میلیون ردیف، این یعنی دیتابیس تا آخرین لحظه هم نمیدونه جواب رو پیدا کرده یا نه، و باید همه‌چیز رو ببینه. حالا اگه همین جدول یک ایندکس روی ستون ایمیل داشته باشه، دیتابیس دیگه لازم نیست همه‌جا رو بگرده؛ مستقیم میره سراغ جایی که احتمال جواب هست. تفاوتش میتونه از چند ثانیه به چند میلی‌ثانیه برسه.

ایندکس چیه واقعاً

ساده‌ترین راه برای فهمیدن ایندکس، مقایسه‌اش با فهرست آخر یک کتابه. اگه بخوای بفهمی کلمه‌ی «recursion» توی کدوم صفحه‌ی کتاب اومده، دو راه داری: یا کتاب رو صفحه به صفحه بخونی تا پیداش کنی (همون full scan)، یا بری سراغ فهرست آخر کتاب که مرتب‌شده‌ست و سریع بگی صفحه‌ی ۲۴۳. ایندکس دیتابیس دقیقاً همین نقشو بازی میکنه: یک ساختار داده‌ی جدا و مرتب‌شده که به ازای هر مقدار توی یک ستون، میگه دقیقاً کجا (کدوم ردیف فیزیکی) باید بری دنبالش.

اکثر دیتابیس‌های رابطه‌ای مثل PostgreSQL و MySQL از یک ساختار داده به اسم B-tree برای ایندکس‌ها استفاده میکنن. B-tree یک درخت متوازنه که جستجو، درج، و حذف توش با پیچیدگی زمانی لگاریتمی انجام میشه — یعنی حتی روی یک جدول با میلیون‌ها ردیف، پیدا کردن یک مقدار فقط چند مرحله طول میکشه، نه میلیون‌ها مقایسه.

چرا رایگان نیست

اگه ایندکس این‌قدر خوبه، چرا همه‌ی ستون‌ها رو ایندکس نمیکنیم؟ چون هزینه داره، و این هزینه دو جا خودش رو نشون میده.

اول، فضا. هر ایندکس یک کپی جداگانه از داده‌ی اون ستون (به‌شکل ساختار درختی) نگه میداره. روی جدول‌های بزرگ، این میتونه چندین گیگابایت فضای اضافی مصرف کنه.

دوم و مهم‌تر، سرعت نوشتن. هر بار که یک ردیف جدید insert میکنی یا یک ردیف موجود رو update میکنی، دیتابیس باید همزمان با آپدیت کردن جدول اصلی، تمام ایندکس‌های مرتبط با اون ستون‌ها رو هم آپدیت کنه. اگه یک جدول پنج تا ایندکس داشته باشه، هر insert عملاً شش تا عملیات نوشتن رو تریگر میکنه، نه یکی. برای همین توصیه‌ی رایج اینه که فقط روی ستون‌هایی ایندکس بذاری که واقعاً توی WHERE، JOIN، یا ORDER BY زیاد ازشون استفاده میکنی — نه هر ستونی که «شاید یک روز» لازم بشه.

clustered در مقابل non-clustered

Cache: کش چیه؟ چرا کش کنیم؟ یک لایه با سرعت بسیار بیشتر

فرض کن یک صفحه داری که برای ساختنش باید بری سراغ دیتابیس، چند تا جدول رو join کنی، نتیجه رو پردازش کنی، و بعد HTML بسازی. این کار شاید ۲۰۰ میلی‌ثانیه طول بکشه. حالا اگه این صفحه رو هزار نفر در ثانیه ببینن، و محتواش هر بار عوض نشه، داری همون کار سنگین رو هزار بار در ثانیه تکرار میکنی، درحالی‌که جواب همیشه یکیه. کش دقیقاً همین اتلاف رو حل میکنه: جواب رو یک بار حساب میکنی، جایی نگهش میداری که دسترسی بهش خیلی سریع‌تره، و دفعه‌های بعد به‌جای محاسبه‌ی دوباره، همون جواب آماده رو برمیگردونی.

این ایده به‌قدری پایه‌ایه که توی تقریباً هر لایه‌ای از یک سیستم، از مرورگر گرفته تا CDN تا سرور تا دیتابیس، یک نسخه‌ی متفاوت از همین ترفند رو میبینی.

کش توی مرورگر و سمت کاربر

اولین لایه‌ای که هر کاربر باهاش برخورد میکنه، کش مرورگره. وقتی یک فایل CSS یا تصویر یا فونت رو دانلود میکنی، مرورگر بر اساس هدرهای HTTP مثل Cache-Control و ETag تصمیم میگیره که آیا لازمه دوباره از سرور بگیرتش یا همون نسخه‌ی محلی رو نشون بده. برای همین دفعه‌ی دوم که یک سایت رو باز میکنی، خیلی سریع‌تر لود میشه — چون مرورگر اصلاً درخواست جدیدی نمیفرسته، یا اگه بفرسته، سرور فقط میگه «چیزی عوض نشده» (کد وضعیت ۳۰۴) و دوباره کل فایل رو نمیفرسته.

کش توی CDN

لایه‌ی بعدی که خیلی وقت‌ها دیده نمیشه، CDN است — سرویس‌هایی مثل Cloudflare یا ArvanCloud که یک نسخه از فایل‌های استاتیک سایتت (تصویر، CSS، JS، و حتی گاهی HTML) رو روی سرورهای پخش‌شده در نقاط مختلف جغرافیایی نگه میدارن. وقتی کاربری از یک شهر دیگه به سایتت وصل میشه، به‌جای این‌که درخواستش تا سرور اصلی بره، نزدیک‌ترین edge server جواب رو از کشش برمیگردونه. این هم سرعت رو بالا میبره و هم فشار روی سرور اصلی رو کم میکنه.

کش سمت سرور (Application Cache)

توی خود اپلیکیشن، معمولاً از ابزارهایی مثل Redis یا Memcached استفاده میشه تا نتیجه‌ی محاسبات سنگین یا کوئری‌های تکراری رو نگه دارن. مثلاً اگه یک API داری که لیست محصولات پرفروش رو برمیگردونه، به‌جای این‌که هر بار این لیست رو از دیتابیس محاسبه کنی، یک بار حسابش میکنی و توی Redis با یک TTL (زمان انقضا) ذخیره‌اش میکنی:

تفاوت Layout و Template در Next.js: کی و چرا باید از template.tsx استفاده کنیم؟

اگر با App Router در Next.js کار کرده باشید، احتمالاً بیشتر وقت‌ها سراغ layout.tsx می‌روید. اما Next.js فایل دیگری به نام template.tsx هم در اختیار ما قرار داده که در ظاهر رفتاری بسیار مشابه دارد، ولی یک فرق ساختاری با Layout دارد.

در این مقاله بررسی می‌کنیم که template چیست، چه فرقی با layout دارد و چرا باید در استفاده از آن هوشمندانه عمل کنیم.

تفاوت کلیدی: حفظ State در برابر ساخت مجدد (Remount)

اصلی‌ترین تفاوت این دو کامپوننت، نحوه رفتار آن‌ها هنگام جابه‌جایی بین صفحات (Navigation) است:

فایل layout.tsx: هنگام جابه‌جایی بین routeهای هم‌سطح، ناپدید نمی‌شود، State خود را حفظ می‌کند و از اول رندر (Remount) نمی‌شود.
فایل template.tsx: با هر بار تغییر Route، کامپوننت template به‌طور کامل Unmount شده و یک نمونه (Instance) جدید از آن ساخته می‌شود. این یعنی تمامی Stateها و Effectهای درون آن ریست می‌شوند.

نکته: هرگاه یک template.tsx در یک پوشه داشته باشید، Next.js آن را دقیقاً به عنوان فرزندِ Layout و والدِ Page رندر می‌کند:

لود بالانسر: از یک سرور تنها تا چیزی که هیچ‌وقت down نمیشه

اکثر پروژه‌ها همین‌طور شروع میشن: یک سرور ساده روی یک VPS معمولی، کاربر کم، همه‌چیز روبه‌راه. مشکل معمولاً از جایی شروع میشه که یک اتفاق باعث میشه ترافیک چند برابر بشه — یک پست وایرال، یک کمپین تبلیغاتی، یا فقط رشد طبیعی کاربر — و همون یک سرور شروع میکنه به کند شدن و timeout دادن. راه‌حلی که خیلی‌ها اول امتحان میکنن اضافه‌کردن منابع به همون سرور است: رم بیشتر، CPU بیشتر. این کار یک‌مدت جواب میده، ولی زیاد طول نمیکشه که همون مشکل دوباره برگرده. نکته اینه که این مسیر یک سقف داره، و لود بالانسر دقیقاً همون‌جایی وارد میشه که این سقف رو کنار میزنه: به‌جای یک سرور بزرگ‌تر، چند سرور کوچک‌تر که ترافیک بینشون تقسیم بشه.

قبل از لود بالانسر: مقیاس عمودی

قبل از این‌که مفهوم load balancing جا بیفته، راه‌حل رایج برای مقابله با ترافیک بالا چیزی بود به اسم مقیاس عمودی یا vertical scaling: سرور موجود رو قوی‌تر میکردی. رم بیشتر، هسته‌ی پردازشی بیشتر، دیسک سریع‌تر. این روش یک مشکل بزرگ داره: یک سقف فیزیکی وجود داره. حتی اگه پول بی‌نهایت هم داشته باشی، یک سرور فیزیکی یا مجازی یک جایی به حداکثر ظرفیتش میرسه. علاوه بر این، این مدل یک نقطه‌ی شکست واحد داره؛ اگه همون یک سرور بخوابه، کل سرویس از دسترس خارج میشه.

بعد از لود بالانسر: مقیاس افقی

لود بالانسر اومد تا یک مسیر جایگزین باز کنه: مقیاس افقی یا horizontal scaling. به‌جای یک سرور قوی، چند سرور معمولی رو کنار هم میذاری و یک لایه‌ی جلویی به اسم load balancer درخواست‌های ورودی رو بینشون پخش میکنه. کاربر اصلاً نمیفهمه پشت صحنه چند سرور داره کار میکنه؛ فقط یک آدرس یا دامنه میبینه.

نتیجه‌ی این تغییر دو چیزه: اول، دیگه سقف فیزیکی وجود نداره — هر وقت ترافیک بالا رفت، یک سرور دیگه اضافه میکنی. دوم، دیگه نقطه‌ی شکست واحد نداری؛ اگه یکی از سرورها بخوابه، لود بالانسر خودش میفهمه و ترافیک رو به بقیه‌ی سرورها هدایت میکنه، بدون این‌که کاربر چیزی متوجه بشه.

لایه‌ی ۴ در مقابل لایه‌ی ۷

لود بالانسرها معمولاً روی دو سطح کار میکنن. لود بالانسر لایه‌ی ۴ (L4) روی سطح transport کار میکنه، یعنی فقط IP و پورت رو میبینه و بدون این‌که وارد محتوای درخواست بشه، ترافیک رو پخش میکنه. سریع‌تره چون کار کمتری انجام میده، ولی هوشمندی کمتری داره.

لود بالانسر لایه‌ی ۷ (L7) روی سطح application کار میکنه، یعنی میتونه محتوای درخواست HTTP رو ببینه — مسیر URL، هدرها، کوکی‌ها — و بر همون اساس تصمیم بگیره کدوم سرور جواب بده. مثلاً میتونی بگی درخواست‌هایی که مسیرشون با شروع میشه برن سراغ یک گروه از سرورها، و درخواست‌های برن سراغ یک گروه دیگه. این انعطاف هزینه داره: کمی کندتر از L4 است چون باید محتوای درخواست رو parse کنه.

راز پشت پرده یوتیوب: چگونه میلیاردها ساعت ویدیو را ذخیره و مدیریت می‌کند؟

تا به حال فکر کرده‌اید وقتی یک ویدیوی ۴K ده دقیقه‌ای را در یوتیوب آپلود می‌کنید، دقیقاً چه بلایی سر آن می‌آید؟ یوتیوب فقط یک وب‌سایت اشتراک ویدیو نیست؛ بلکه یکی از پیچیده‌ترین و عظیم‌ترین سیستم‌های مهندسی نرم‌افزار و سخت‌افزار در تاریخ بشر است.

هر دقیقه بیش از ۵۰۰ ساعت ویدیو در این پلتفرم آپلود می‌شود. اما چگونه این غول فناوری بدون از دست رفتن داده‌ها یا کندی شدید، این حجم عظیم را مدیریت می‌کند و همزمان ویدیو را با کیفیت‌های مختلف (از ۱۴۴p تا ۴K) به شما نمایش می‌دهد؟ در این مقاله، پشت پرده این جادوی مهندسی را به زبان ساده اما فنی بررسی می‌کنیم.

حجم داده‌ها: صحبت از ترابایت نیست، صحبت از اگزابایت است

برای درک مقیاس یوتیوب، باید با واحدهای اندازه‌گیری فراتر از گیگابایت و ترابایت آشنا شویم. یوتیوب داده‌های خود را در مقیاس «اگزابایت» (هر اگزابایت برابر با یک میلیارد گیگابایت) مدیریت می‌کند. ذخیره چنین حجمی روی هارد دیسک‌های معمولی در یک اتاق سرور غیرممکن است. راه‌حل، استفاده از معماری توزیع‌شده است.

راز اول: سیستم فایل توزیع‌شده (Google Colossus)

یوتیوب ویدیوهای شما را روی یک سرور خاص ذخیره نمی‌کند. گوگل از سیستم فایل توزیع‌شده اختصاصی خود به نام Colossus (جانشین سیستم معروف GFS) استفاده می‌کند.

شبکه توزیع محتوا (CDN) چیست؟ میتونم سرعت سایتم رو افزایش بدم؟

تا به حال دقت کرده‌اید چرا سایت‌هایی مثل نتفلیکس، یوتیوب یا حتی گوگل، از هر نقطه‌ای از دنیا با سرعتی نزدیک به هم بارگذاری می‌شوند؟ راز این سرعت، در یک سرور قدرتمند در یک گوشه دنیا پنهان نشده است. راز آن در هزاران سرور کوچک است که در سراسر جهان پخش شده‌اند و منتظرند تا محتوای مورد نیاز شما را از نزدیک‌ترین نقطه ممکن تحویل دهند.

این شبکه عظیم و هوشمند، CDN یا Content Delivery Network نام دارد. اگر صاحب یک سایت هستید، توسعه‌دهنده‌اید یا حتی فقط کنجکاوید بدانید اینترنت چگونه این‌قدر سریع کار می‌کند، این مقاله برای شما نوشته شده است. در ادامه، CDN را از پایه تا جزئیات فنی بررسی می‌کنیم.

CDN چیست؟ تعریف ساده و کاربردی

CDN مخفف عبارت Content Delivery Network به معنی «شبکه توزیع محتوا» است. به زبان ساده، CDN مجموعه‌ای از سرورهای پراکنده در نقاط مختلف جغرافیایی است که نسخه‌ای کش شده از محتوای یک سایت را در خود نگه می‌دارند.

وقتی کاربری از تهران سایت شما را باز می‌کند، به جای اینکه درخواستش به سرور اصلی سایت در آلمان برود، از نزدیک‌ترین سرور CDN (مثلاً سرور ابری در تهران یا استانبول) پاسخ می‌گیرد. این یعنی فاصله کمتر، تاخیر کمتر و سرعت بسیار بالاتر.

چرا به CDN نیاز داریم؟

برای درک اهمیت CDN، ابتدا باید با یک مفهوم کلیدی به نام Latency یا «تاخیر شبکه» آشنا شویم. وقتی کاربری در Sydney استرالیا می‌خواهد به سایتی دسترسی پیدا کند که سرور اصلی آن در نیویورک قرار دارد، داده‌ها باید هزاران کیلومتر را در کابل‌های زیردریایی طی کنند. این رفت و برگشت حتی با سرعت نور هم چند صد میلی‌ثانیه طول می‌کشد.

سیستم DNS چیست؟ راهنمای جامع و ساده از دفترچه تلفن اینترنت

تا به حال فکر کرده‌اید وقتی آدرسی مثل google.com را در مرورگر تایپ می‌کنید، دقیقاً چه اتفاقی در کسری از ثانیه رخ می‌دهد؟ کامپیوتر شما برای برقراری ارتباط با سرور گوگل، به یک آدرس عددی و طولانی به نام IP نیاز دارد. اما ما انسان‌ها حفظ کردن این اعداد را بلد نیستیم. اینجاست که یکی از شاهکارهای مهندسی اینترنت وارد عمل می‌شود.

سیستم DNS یا همان Domain Name System، نامرئی‌ترین اما حیاتی‌ترین بخش وب است. بدون آن، اینترنتی که امروز می‌شناسیم وجود نداشت. در این مقاله، می‌خواهیم این تکنولوژی را از ریشه بررسی کنیم. می‌بینیم قبل از DNS اوضاع چگونه بود، خود DNS چیست و چگونه کار می‌کند، و در نهایت بعد از پیدا شدن آدرس، چه مراحلی طی می‌شود.

قبل از DNS: دنیایی که در آن گم شده بودیم

برای درک بهتر اهمیت DNS، باید به روزهای اولیه اینترنت و شبکه ARPANET برگردیم. در آن زمان، برای پیدا کردن یک کامپیوتر در شبکه، باید آدرس IP آن را حفظ می‌کردید.

وقتی تعداد کامپیوترها کم بود، این کار شدنی بود. اما با بزرگ‌تر شدن شبکه، نیاز به یک راه حل احساس شد. راه حل اولیه فایلی به نام HOSTS.TXT بود. این فایل یک لیست متنی ساده بود که نام کامپیوترها و آدرس IP آن‌ها را در خود داشت. هر روز، یک سرور مرکزی این فایل را آپدیت می‌کرد و همه شبکه‌ها باید آن را دانلود می‌کردند.

این روش خیلی زود به بن‌بست خورد. با رشد نمایی اینترنت، حجم این فایل آنقدر زیاد شد که دانلود آن ساعت‌ها طول می‌کشید. همچنین ترافیک شبکه به شدت بالا رفت و ناهماهنگی در نسخه‌های مختلف فایل باعث شد کاربران به آدرس‌های اشتباه هدایت شوند. اینترنت به یک سیستم مقیاس‌پذیر و هوشمند نیاز داشت.

دیپلوی روی سرور ایران بدون اینترنت بین‌الملل یا نت ملی

یه سناریو که هر توسعه‌دهنده‌ی ایرانی باهاش آشناست: سرور گرفتی، همه چیز رو آپلود کردی، npm install می‌زنی — و بعد پنج دقیقه نشستی نگاه می‌کنی که cursor چشمک می‌زنه و چیزی دانلود نمی‌شه. یا بدتر: همه چیز کار می‌کنه، بعد یه روز نت قطع می‌شه و نمی‌تونی حتی یه dependency ساده آپدیت کنی.

قطع اینترنت بین‌الملل یه اتفاق خوب نیست و نباید عادی‌اش کنیم. ولی واقعیت اینه که این اتفاق می‌افته — گاهی جند هفته، گاهی بیشتر — و اگه سرورت وابسته به سرورهای خارجی باشه، یه قطعی ساده می‌تونه کل deploy و maintenance رو فلج کنه. این مقاله برای اونه که اگه یه روز اتفاق افتاد، آماده باشی.

مشکل اینجاست که اکثر ابزارها، package managerها، و حتی خود لینوکس به‌صورت پیش‌فرض از سرورهای خارج دانلود می‌کنن. اگه قبل از دیپلوی این‌ها رو تنظیم نکنی، اولین باری که نت ملی جدا می‌شه — یا از همون اول اگه سرورت به اینترنت بین‌الملل وصل نیست — همه چیز می‌شکنه.

اینجا یه checklist عملی از چیزهایی که باید انجام بشه می‌آورم، بر اساس تجربه‌ی مستقیم.

۱. میرور خود توزیع لینوکس

اولین و مهم‌ترین کار اینه که میرور اصلی سیستم عاملت رو عوض کنی. وقتی apt update یا pacman -Syu می‌زنی، باید از یه آدرس ایرانی دانلود کنه.

برای اوبونتو، فایل /etc/apt/sources.list رو ویرایش کن و آدرس‌های archive.ubuntu.com رو با میرور ایرانی جایگزین کن. برای آرچ، /etc/pacman.d/mirrorlist رو ویرایش کن.

لیست میرورهای قابل اعتماد ایرانی رو می‌تونی توی devneeds.ir پیدا کنی. ArvanCloud معمولاً مطمئن‌ترین انتخابه از نظر uptime و پوشش پکیج‌ها.

# بعد از تغییر میرور اوبونتو
sudo apt update && sudo apt upgrade

۲. میرور Docker

Docker هم به‌صورت پیش‌فرض از docker.io و pull می‌کنه. این رو باید توی فایل عوض کنی:

چرا باید اصول برنامه‌نویسی رو یاد بگیری وقتی AI همه چیز رو می‌نویسه؟

یه سوال جدی هست که بیشتر و بیشتر آدم‌ها می‌پرسن — خصوصاً کسایی که تازه شروع کردن: الان که Claude Code یه component کامل React رو توی ده ثانیه می‌نویسه، الان که GPT یه API endpoint رو با تمام error handling‌اش تحویل می‌ده، واقعاً باید بشینم data structure یاد بگیرم؟ باید algorithm بفهمم؟ باید بدونم HTTP دقیقاً چطور کار می‌کنه؟

جواب صادقانه: بله. ولی نه به همون دلیلی که فکر می‌کنی.

مدل کد می‌نویسه، تو تصمیم می‌گیری

یه چیزی که توی استفاده از AI coding tools خیلی زود مشخص می‌شه اینه که کیفیت خروجی مستقیماً به کیفیت input تو وابسته‌ست. اگه ندونی چی می‌خوای، مدل هم نمی‌دونه. اگه ندونی معماری درست چیه، خروجی مدل ممکنه technically بی‌نقص باشه ولی برای پروژه‌ات کاملاً اشتباه.

یه مثال ساده: از Claude Code می‌خوای یه caching layer بسازه. اگه ندونی فرق Redis و یه in-memory cache ساده چیه، نمی‌دونی کِی از کدوم بخوای. اگه ندونی race condition یعنی چی، نمی‌فهمی که خروجی مدل این مشکل رو داره یا نه. اگه ندونی TTL چطور کار می‌کنه، نمی‌تونی بگی آیا مدل اون رو درست تنظیم کرده یا نه.

مدل کد می‌نویسه. تو تصمیم می‌گیری این کد چیه و چرا.

review کردن بدون فهمیدن ممکن نیست

یه اشتباه رایج اینه که فکر می‌کنیم «می‌خونیم» کد AI رو. ولی خوندن بدون درک، review نیست — یه نگاه انداختنه که حس خوبی می‌ده ولی هیچ چیزی رو تضمین نمی‌کنه.

وقتی AI یه function می‌نویسه که O(n²) complexity داره و تو نمی‌دونی این یعنی چی، می‌گی «خوبه، merge می‌کنم» — و شاید واقعاً هم خوب باشه. ولی وقتی data ات از ده هزار record به یه میلیون رکورد می‌رسه، اون function سرور رو می‌خوابونه. این اتفاق نه به‌خاطر اینه که مدل اشتباه کرد — مدل چیزی نوشت که برای context ای که داشت معقول بود. اشتباه اینجا بود که کسی که review کرد نفهمید مشکل کجاست.

debugging جایی‌ه که اصول واقعاً مهم می‌شن

هر چیزی که AI می‌نویسه، در یه لحظه‌ای اشتباه می‌کنه — یا مدل اشتباه می‌کنه، یا کد توی production با شرایطی مواجه می‌شه که مدل پیش‌بینی نکرده بود. اون لحظه، تنها کسی که می‌تونه مشکل رو پیدا کنه و درستش کنه توئی.

debugging یه مهارتیه که بدون فهمیدن اصول ممکن نیست. نمی‌تونی race condition پیدا کنی اگه ندونی thread یعنی چی. نمی‌تونی memory leak رو trace کنی اگه lifecycle object ها رو نفهمی. نمی‌تونی بفهمی چرا request تایم‌اوت می‌شه اگه ندونی TCP handshake چطور کار می‌کنه.

ویژگی	cuid	cuid2
الگوریتم	fingerprint + timestamp + counter	SHA3 هش روی entropy تصادفی
قابل پیش‌بینی بودن	نسبتاً بله (ریسک امنیتی)	خیر
طول	ثابت	متغیر (پیش‌فرض ۲۴، قابل تنظیم ۴ تا ۳۲)
شروع رشته	حرف `c` ثابت	همیشه یک حرف تصادفی
عملکرد در serverless	ضعیف‌تر	بهینه‌شده
نگهداری پروژه	متوقف شده	فعال