‏چطور Cursor مشکل مقیاس‌پذیری Git رو حل کرد

این‌روزها که ایجنت‌های AI خودکار کد می‌زنن، تعداد commit و PR و اجرای CI به‌شدت بالا رفته و زیرساخت Git بیشتر از قبل زیر فشاره؛ قطعی‌های اخیر گیت‌هاب هم همین مشکل رو نشون دادن. وقتی مقیاس کار به صدها میلیون ریپو می‌رسه، ساختار Git -که یه گراف جهت‌دار بدون حلقه (DAG) از commit‌هاست و هر شیء رو با هش SHA-1 پیدا می‌کنه- به مشکل می‌خوره: اگه سرور هش دقیق رو نداشته باشه، باید کل گراف رو قدم‌به‌قدم بگرده. ایجنت‌ها هم چون معمولاً کلی ریپوی کوچیک و یک‌بارمصرف می‌سازن، اوضاع رو بدتر کردن.

گیت‌هاب برای این مشکل روشی به اسم Spokes ابداع کرد: نگه‌داشتن حداقل ۳ کپی کاملاً هماهنگ از هر ریپو روی دیسک‌های NVMe سریع. این روش استاندارد صنعت شده، ولی یه ایراد اساسی داره: هرچی رپلیکای بیشتری بسازی، هماهنگ نگه‌داشتنشون بیشتر طول می‌کشه؛ و Git هم با «سازگاری نهایی» (eventual consistency) میونه‌ی خوبی نداره.

Vicent Martí، مهندس اصلی این پروژه، می‌گه Cursor برای سرویس Git خودش به اسم Origin سراغ ذخیره‌سازی آبجکتی (مثل S3) رفته. تو این معماری که با موتور Continuity کار می‌کنه، هر پوش اول به‌صورت رکوردهای تغییرناپذیر تو یه لاگ نوشتاری (WAL) روی S3 ذخیره می‌شه و هم‌زمان رو یه کپی محلی روی NVMe هم نوشته می‌شه؛ بقیه‌ی رپلیکاها هروقت لازم شد، تغییرات رو از همون‌جا می‌کشن پایین. چون فقط لازمه یه رپلیکای محلی رو با تراکنش هماهنگ کنی، سیستم می‌تونه به همون سرعتی که دیسک اجازه می‌ده پوش قبول کنه.

منبع حقیقت تو این مدل همیشه همون WAL روی S3 هست، نه یه دیسک خاص؛ یعنی هر ریپو رو می‌شه مثل یه کش گرم روی دیسک در نظر گرفت. الان یه نسخه‌ی بتا از Origin با پلن‌های پولی Cursor در دسترسه و باید دید وقتی وارد فاز production بشه، چقدر پایدار از آب درمیاد.

نکات کلیدی:

• Origin سرویس Git جدید Cursor‌ه که با موتور Continuity کار می‌کنه و الان تو مرحله‌ی بتاست.
• به‌جای روش Spokes گیت‌هاب (۳+ کپی هماهنگ روی NVMe)، Origin از S3 به‌عنوان منبع اصلی و WAL استفاده می‌کنه.
• هر پوش هم‌زمان تو S3 (به‌شکل WAL) و یه کپی محلی NVMe نوشته می‌شه؛ رپلیکاهای دیگه بعداً سینک می‌شن.
• Vicent Martí، طراح اصلی این معماری، قبلاً تو خود گیت‌هاب هم روی مشکل مشابهی کار کرده بود.